Connection check
verified live · 27h ago
ateam-mcp
Build, validate, and deploy multi-agent AI solutions from any AI environment.
Tools
57
GitHub stars
1
Installs / wk
1.1k
Licence
—
Transport
streamable-http, stdio
Last checked
27h ago
Tools & capabilities
57 toolsRead from the running server on 27h ago.
ateam_auth
urltenantapi_keymaster_key
Authenticate with A-Team. Required before any tenant-aware operation (reading solutions, deploying, testing, etc.). The user can get their API key at https://mcp.ateam-ai.com/get-a… Authenticate with A-Team. Required before any tenant-aware operation (reading solutions, deploying, testing, etc.). The user can get their API key at https://mcp.ateam-ai.com/get-api-key. Only global endpoints (spec, examples, validate) work without auth. IMPORTANT: Even if environment variables (ADAS_API_KEY) are configured, you MUST call ateam_auth explicitly — env vars alone are not sufficient. For cross-tenant admin operations, use master_key instead of api_key.
ateam_bootstrap
REQUIRED onboarding entrypoint for A-Team MCP. MUST be called when user greets, says hi, asks what this is, asks for help, explores capabilities, or when MCP is first connected. Re… REQUIRED onboarding entrypoint for A-Team MCP. MUST be called when user greets, says hi, asks what this is, asks for help, explores capabilities, or when MCP is first connected. Returns platform explanation, example solutions, and assistant behavior instructions. Do NOT improvise an introduction — call this tool instead.
ateam_build_and_run
githubskillssolutionmcp_storeconnectorssolution_id
+2
DEPLOY THE CURRENT MAIN BRANCH TO A-TEAM CORE. ⚠️ HEAVIEST OPERATION (60-180s): validates solution+skills → deploys all connectors+skills to Core (regenerates MCP servers) → health… DEPLOY THE CURRENT MAIN BRANCH TO A-TEAM CORE. ⚠️ HEAVIEST OPERATION (60-180s): validates solution+skills → deploys all connectors+skills to Core (regenerates MCP servers) → health-checks → optionally runs a warm test → auto-pushes to GitHub. 🌳 DEV/PROD WORKFLOW: 1. Edit files → ateam_github_patch (writes to `dev` branch by default) 2. (Optional) Preview what's about to ship → ateam_github_diff 3. Ship dev → main → ateam_github_promote (merges + auto-tags `prod-YYYY-MM-DD-NNN`) 4. Deploy main to Core → ateam_build_and_run This tool ALWAYS deploys the `main` branch — there is no `ref` parameter. To deploy in-progress dev work, first promote it. AUTO-DETECTS GitHub repo: if you omit mcp_store and a repo exists, connector code is pulled from main automatically. First deploy requires mcp_store. After that, edit via ateam_github_patch + promote, then build_and_run. For small changes prefer ateam_patch (faster, incremental). Requires authentication.
ateam_chain_status
job_idactor_idchain_id*
SLIM chain status — the chip-quick poll. Given a chain_id (from ateam_conversation), returns the WHOLE-CHAIN aggregate status cheaply: chain_status + chain_done (true only when the… SLIM chain status — the chip-quick poll. Given a chain_id (from ateam_conversation), returns the WHOLE-CHAIN aggregate status cheaply: chain_status + chain_done (true only when the ENTIRE chain — root job + every handoff + askAnySkill subcall — is terminal), plus pending_question, result, and a short progress line. This is what you poll on a loop after ateam_conversation — NOT ateam_get_chain (that returns the full tree; too heavy for periodic polling). A single job can finish while the chain is still running, so poll chain_done, not a job's status. Loop: call every ~2s until chain_done === true (or pending_question is set — the assistant is waiting on the user). Then read `result` / fetch the full tree once via ateam_get_chain if you need per-job detail.
ateam_connector_logs
limitsinceerrors_onlysolution_id*connector_id*
Read what a connector process actually PRINTED to stderr. This is the only place a connector's internal failure is visible: a tool that catches its own error still returns ok:true,… Read what a connector process actually PRINTED to stderr. This is the only place a connector's internal failure is visible: a tool that catches its own error still returns ok:true, and the widget then renders an empty state that looks like real data. Real case (2026-08-11): a dashboard connector's ledger.getData got 401 Authentication required from Core, swallowed it, returned an empty ledger, and displayed 0.00 everywhere — while the upload said ok, the tool said ok:true, and the surface probe said surface_ok. The word 'Authentication' appeared ONLY here. USE IT whenever a tool succeeds but the data is empty, wrong, or zero — that combination is the signature of a swallowed error, and 'the call returned ok' is not evidence it worked. Pass the returned `cursor` back as `since` to read only what is new since your last look, so you can bracket an action and see exactly what it printed. Only stdio (solution) connectors stream stderr through Core; a platform/HTTP connector answers ok:false with a reason.
ateam_conversation
message*actor_idsolution_id*
Send a chat message to a deployed solution. No skill_id needed — the system auto-routes to the right skill. ALWAYS ASYNC: returns a chain_id immediately — the assistant's reply is… Send a chat message to a deployed solution. No skill_id needed — the system auto-routes to the right skill. ALWAYS ASYNC: returns a chain_id immediately — the assistant's reply is NOT in this response (a conversation can run for minutes across handoffs + subcalls, so a synchronous wait would hit the 100s edge timeout → 524). POLL BY CHAIN, NEVER BY JOB: an individual job can terminate while the chain is still running, so poll ateam_chain_status(chain_id) on a loop (~2s) and stop when chain_done === true (or pending_question is set — the assistant is waiting on the user). That is the cheap chip-quick poll (Core's whole-chain computeChainStatus — the same thing the standard chat uses). Use ateam_get_chain(chain_id) only ONCE at the end if you want the full tree / per-job detail — it's too heavy to loop on. Multi-turn: pass the actor_id from a previous response back in to continue the same thread (e.g. reply to a confirmation prompt). Each call starts a new chain; the same actor_id maintains conversation context.
ateam_create_connector
nameui_capablesolution_id*connector_id*
Scaffold a new MCP connector with server.js + package.json + README. Eliminates ~50% of identical boilerplate (MCP server setup, tool registration, stdio transport). You then fill… Scaffold a new MCP connector with server.js + package.json + README. Eliminates ~50% of identical boilerplate (MCP server setup, tool registration, stdio transport). You then fill in the tool implementations. Set ui_capable=true to include ui.listPlugins / ui.getPlugin stubs (plugin source files added separately via ateam_create_plugin). After scaffolding, the files are uploaded to Core via the same path as ateam_upload_connector.
ateam_create_plugin
kindplugin_name*solution_id*connector_id*
Scaffold a UI plugin (iframe HTML, React Native TSX, or both) inside an existing connector. Eliminates ~50% of identical plugin boilerplate (imports, theme/bridge hooks, postMessag… Scaffold a UI plugin (iframe HTML, React Native TSX, or both) inside an existing connector. Eliminates ~50% of identical plugin boilerplate (imports, theme/bridge hooks, postMessage protocol, default export shape). You then fill in the component body. Use kind='iframe' for web-only, 'rn' for mobile-only, 'adaptive' for both. Also writes ui-dist/<plugin>/manifest.json with the required render block. ⚠️ RENDERING IS NOT AUTOMATIC. At deploy, Phase 5 discovers plugins by calling each connector's ui.listPlugins + ui.getPlugin — a plugin only appears (and renders) if the connector ADVERTISES it there with a render.{mode, iframeUrl?, reactNative?} block. Dropping the scaffold files alone does NOT register it. If the connector generates its plugin list from ui-dist/<plugin>/manifest.json, the emitted manifest is picked up automatically; if the connector has a HARDCODED list (e.g. personal-assistant-ui-mcp: UI_PLUGINS[] + PLUGIN_MANIFESTS{} in server.js), you MUST add this plugin there (copy the render block from the manifest.json). Verify after deploy with ateam_get_solution(solution_id, 'connectors_health') or ateam_get_widget_catalog. Then declare it at solution ui_plugins[] so a skill can open it via sys.focusUiPlugin (see ateam_get_spec topic:'widgets'). The scaffold MERGES into the existing connector (server.js + other files preserved) — works on GitHub-backed AND repo-less tenants; merge base is the GitHub repo when connected, else the deployed connector source.
ateam_delete_connector
confirm*solution_id*connector_id*
⚠️ CASCADING — any skill whose engine.bootstrap_tools or tools[] name a tool from this connector will FAIL its next execution. Stops and deletes the connector from A-Team Core; dro… ⚠️ CASCADING — any skill whose engine.bootstrap_tools or tools[] name a tool from this connector will FAIL its next execution. Stops and deletes the connector from A-Team Core; drops references from the solution definition (grants, platform_connectors, ui_plugins ids starting `mcp:<connector-id>:*`) and skill definitions (connectors array); cleans up mcp-store files. ALSO REMOVES THE SOURCE: `connectors/<id>/` is deleted from the repo (main AND dev) in the same call, so the delete is DURABLE. This CHANGED on 2026-08-23 — it used to preserve the source and name `ateam_build_and_run(github:true)` as a way to resurrect. That made a delete undo itself on a later publish, and only in some states, since connectors[] is synthesized from mcp_store keys ONLY when it is empty. If you want the code kept, copy it out (ateam_get_connector_source) BEFORE deleting. If the repo removal fails the response says so under `github` — Core is clean but the source is still there. REQUIRES `confirm:true`.
ateam_delete_skill
confirm*skill_id*solution_id*
⚠️ IRREVERSIBLE in Core + Builder FS — kills the running MCP process, unregisters from skill registry, deletes the Mongo record, drops from solution.skills[] and solution.linked_sk… ⚠️ IRREVERSIBLE in Core + Builder FS — kills the running MCP process, unregisters from skill registry, deletes the Mongo record, drops from solution.skills[] and solution.linked_skills, and removes the skill's files from Builder FS. REQUIRES `confirm:true`. RECOVERY: the skill still lives in GitHub — `ateam_github_pull` rebuilds the whole solution (no per-skill restore path).
ateam_delete_solution
confirm*solution_id*confirm_solution_id*
⚠️ IRREVERSIBLE — kills Mongo state, running MCP processes, and Builder FS for the whole solution and every skill. REQUIRES `confirm:true` AND `confirm_solution_id` echoing the sol… ⚠️ IRREVERSIBLE — kills Mongo state, running MCP processes, and Builder FS for the whole solution and every skill. REQUIRES `confirm:true` AND `confirm_solution_id` echoing the solution id you're destroying (defeats typos and hallucinated ids). RECOVERY: the GitHub repo is untouched; `ateam_github_pull` rebuilds the solution from `main`. Prefer that over re-deploying from memory.
ateam_design_advisor
goal*design_state
CONSULT THIS DURING DESIGN — before and while you design a skill/solution. Describe what you're building; it returns POINTERS to the platform capabilities that fit (per-actor stora… CONSULT THIS DURING DESIGN — before and while you design a skill/solution. Describe what you're building; it returns POINTERS to the platform capabilities that fit (per-actor storage, widgets, triggers, sub-agents, mobile data, run-scripts, multi-skill, GitHub, …), each with the /spec topic to read next (via ateam_get_spec) and the tool to wire it. Also returns 'missing' hints (capabilities your goal implies but the design hasn't wired) and lifecycle hints (e.g. connect GitHub when the project will iterate). ADVISORY ONLY — you decide and own the design. Stateless: pass the current design_state each call; consult it as often as you like as the design evolves.
ateam_get_chain
job_idactor_idchain_idskill_slug
Inspect the full chain tree — the whole run rooted at chain_id, walking down through every handoff and askAnySkill subcall. Use when a chain has already run and you want to analyz… Inspect the full chain tree — the whole run rooted at chain_id, walking down through every handoff and askAnySkill subcall. Use when a chain has already run and you want to analyze the structure: which skill called which, how deep the call tree went, which tool inside which job invoked which sub-tool. The two main shapes: • response.data.chainJobs[] — one entry per job in the chain. Fields: jobId, skill, status, iteration, depth (0 = root, +1 per askAnySkill subcall hop), relation ('root' | 'subcall' | 'handoff'), parentJobId, parentSkill, goal. • response.data.executionSteps[] — every tool call across all chain jobs, tagged with _skill, _jobId, _depth (= job depth), _relation, _parentSkill, _parentJobId, _toolDepth (tool-in-tool nesting via opId/parentOpId). Differs from ateam_test_status by purpose: status is for live polling of a job you just kicked off; get_chain is for post-hoc tree analysis (debugging multi-skill flows, regression testing, comparing two runs). Auth: forwards your authed api_key. Tenant scoped by the key itself. Actor scoping: you can only inspect chains rooted at jobs your actor has access to.
ateam_get_connector_source
pathsolution_id*connector_id*
Read the source code files of a deployed MCP connector. Returns all files (server.js, package.json, etc.) stored in the mcp_store for this connector. Use this BEFORE patching or re… Read the source code files of a deployed MCP connector. Returns all files (server.js, package.json, etc.) stored in the mcp_store for this connector. Use this BEFORE patching or rewriting a connector — always read the current code first so you can make surgical fixes instead of blind full rewrites.
ateam_get_examples
type*
Get complete working examples that pass validation. Study these before building your own. Get complete working examples that pass validation. Study these before building your own.
ateam_get_execution_logs
limitjob_idactor_idchain_idskill_idsolution_id*
Get execution logs for a solution — recent jobs with step traces, tool calls, errors, and timing. Essential for debugging what actually happened during skill execution. (Advanced.) Get execution logs for a solution — recent jobs with step traces, tool calls, errors, and timing. Essential for debugging what actually happened during skill execution. (Advanced.)
ateam_get_lessons
limitsolution_id*
Read what EARLIER runs on this solution learned — newest first, bounded. Call this during orientation, BEFORE planning: it is the only thing that carries context across runs, and i… Read what EARLIER runs on this solution learned — newest first, bounded. Call this during orientation, BEFORE planning: it is the only thing that carries context across runs, and it is cheap. Each entry says which tool misled a previous run, the verbatim error, what was tried instead, and whether that worked. An empty list is a real answer (nothing learned yet).
ateam_get_metrics
job_idactor_idchain_idskill_idsolution_id*
Get execution metrics — timing, tool stats, bottlenecks, signals, and recommendations. (Advanced.) Get execution metrics — timing, tool stats, bottlenecks, signals, and recommendations. (Advanced.)
ateam_get_progress
limitsolution_id*
What this build has already ACHIEVED — read it FIRST when continuing a run, before any orientation call. Returns the CURRENT status per step (latest entry wins) plus recent history… What this build has already ACHIEVED — read it FIRST when continuing a run, before any orientation call. Returns the CURRENT status per step (latest entry wins) plus recent history. Then build only the steps that are ABSENT or not yet `verified`. ABSENT IS NOT "NOTHING WAS DONE" — the journal may predate a step, or a run may have died before writing. It is a fast path, not a new source of truth: check before rebuilding something expensive. Complements ateam_get_lessons, which records what BROKE. This records what WORKS.
ateam_get_solution
view*limitoffsetsectionskill_idsolution_id*
Read solution state — definition, skills, health, status, or export. Use this to inspect deployed solutions. Read solution state — definition, skills, health, status, or export. Use this to inspect deployed solutions.
ateam_get_spec
topic*searchsection
Get the A-Team specification — schemas, validation rules, system tools, agent guides, and templates. Start here after bootstrap to understand how to build skills and solutions. Use… Get the A-Team specification — schemas, validation rules, system tools, agent guides, and templates. Start here after bootstrap to understand how to build skills and solutions. Use 'section' to get just one part of the skill spec (much smaller than the full spec). Use 'search' to find specific fields or concepts across the spec. When designing a persona that orchestrates logic via run_python_script (the Python-as-orchestrator pattern), also fetch topic='python_helpers' — that returns the adas.* helper namespace reference. Skills designed without knowing about adas.* produce 5-10x larger / brittler scripts. When wiring widgets (UI plugins) into a solution, fetch topic='widgets' — that returns the widget spec (catalog model, how_to_use blocks, opener_call shape, persona phrasing rules, binding semantics) so you can declare `ui_plugins` correctly. For the live catalog of widgets actually available in a deployed tenant, use ateam_get_widget_catalog instead.
ateam_get_widget_catalog
formatoriginsolution_idinclude_unused
Get the live catalog of widgets (UI plugins) available in this tenant's solution. Returns platform-bundled + solution-bundled + skill-declared widgets, each with a paste-ready how_… Get the live catalog of widgets (UI plugins) available in this tenant's solution. Returns platform-bundled + solution-bundled + skill-declared widgets, each with a paste-ready how_to_use block (solution.json snippet + opener_call + persona_phrasing + binding_notes). Use this when wiring widgets into a skill or solution — the how_to_use block is designed to be copied verbatim into the solution.json ui_plugins[] entry and into the persona's opener phrasing, so you don't have to hand-roll either. The catalog reflects what is actually deployed in the tenant right now, not the abstract spec (for the spec itself, use ateam_get_spec topic='widgets'). Origins: • 'platform' = widgets bundled with the platform (always available). • 'solution' = widgets bundled with this tenant's solution. • 'skill' = widgets declared by a specific skill in the solution. Auth: forwards your authed api_key to Core (no master-secret involvement). Tenant scope is pinned by the key itself.
ateam_get_workflows
Get the builder workflows — step-by-step state machines for building skills and solutions. Use this to guide users through the entire build process conversationally. Returns phases… Get the builder workflows — step-by-step state machines for building skills and solutions. Use this to guide users through the entire build process conversationally. Returns phases, what to ask, what to build, exit criteria, and tips for each stage.
ateam_github_diff
baseheadsolution_id*
PRE-FLIGHT BEFORE PROMOTE. Compares `dev` (head) vs `main` (base) by default — shows exactly which commits and files are about to ship if you call ateam_github_promote() next. Use… PRE-FLIGHT BEFORE PROMOTE. Compares `dev` (head) vs `main` (base) by default — shows exactly which commits and files are about to ship if you call ateam_github_promote() next. Use this when you want to: • Review changes before promoting to prod • See if dev is ahead of main at all (returns ahead_by: 0 if nothing to promote) • **Diagnose a failed promote** — check `behind_by` and `status`. `status: 'diverged'` (behind_by > 0) means main holds commits dev never received, which is what makes ateam_github_promote return 409 Merge conflict. ALWAYS call this after a promote failure, before reporting anything to the user. • Inspect arbitrary branch/tag/commit comparisons (override base/head) Note: `files[]` lists what DIFFERS, not what conflicts. For solution.json and skills/*/skill.json the difference is often deploy-generated data (regenerated connector tools, timestamps) rather than authored change — see ateam_github_read's `_ateam_representation`.
ateam_github_list_versions
solution_id*
List all available checkpoints (safe-* tags) for a solution. Shows tag name, date, counter, and commit SHA. Use before rollback to see available safe points. List all available checkpoints (safe-* tags) for a solution. Shows tag name, date, counter, and commit SHA. Use before rollback to see available safe points.
ateam_github_log
reflimitsolution_id*
View commit history for a solution's GitHub repo. Shows recent commits with messages, SHAs, timestamps, and links. Default reads from `main` (prod). Pass `ref: 'dev'` to see in-pro… View commit history for a solution's GitHub repo. Shows recent commits with messages, SHAs, timestamps, and links. Default reads from `main` (prod). Pass `ref: 'dev'` to see in-progress work.
ateam_github_patch
refpath*branchsearchcontentmessage
+2
Edit a file in the solution's GitHub repo and commit. Two modes: 1. FULL FILE: provide `content` — replaces entire file (good for new files or small files) 2. SEARCH/REPLACE: provi… Edit a file in the solution's GitHub repo and commit. Two modes: 1. FULL FILE: provide `content` — replaces entire file (good for new files or small files) 2. SEARCH/REPLACE: provide `search` + `replace` — surgical edit without sending full file (preferred for large files like server.js) Always use search/replace for large files (>5KB). Always read the file first with ateam_github_read to get the exact text to search for. DEFAULTS TO `dev` BRANCH — writes don't touch prod. Use ateam_github_promote to ship dev→main when ready. Pass ref:'main' only for emergency hotfixes.
ateam_github_promote
labeldry_runskip_tagsolution_id*
SHIP DEV TO PROD. Merges the `dev` branch into `main` and auto-tags the new main HEAD as safe-YYYY-MM-DD-NNN. Use after testing your dev work, when you're ready to deploy changes t… SHIP DEV TO PROD. Merges the `dev` branch into `main` and auto-tags the new main HEAD as safe-YYYY-MM-DD-NNN. Use after testing your dev work, when you're ready to deploy changes to production. Workflow: 1) ateam_github_patch (writes to dev) → 2) ateam_github_promote (merges dev→main) → 3) ateam_build_and_run (deploys main). Pass dry_run:true to see what's about to ship without merging. ON 409 MERGE CONFLICT: main holds commits dev never received. Call ateam_github_sync_from_main(solution_id) to merge main into dev, then promote again. Only if THAT also returns 409 did both sides edit the same lines — that one needs a human (open a PR on GitHub).
ateam_github_pull
solution_id*
Deploy a solution FROM its GitHub repo. Reads .ateam/export.json + connector source from the repo and feeds it into the deploy pipeline. Use this to restore a previous version or d… Deploy a solution FROM its GitHub repo. Reads .ateam/export.json + connector source from the repo and feeds it into the deploy pipeline. Use this to restore a previous version or deploy from GitHub as the source of truth.
ateam_github_push
messagesolution_id*
Push the current deployed solution to GitHub. Auto-creates the repo on first use. Commits the full bundle (solution + skills + connector source) atomically. Use after ateam_build_a… Push the current deployed solution to GitHub. Auto-creates the repo on first use. Commits the full bundle (solution + skills + connector source) atomically. Use after ateam_build_and_run to version your solution, or anytime you want to snapshot the current state.
ateam_github_read
refpath*branchsolution_id*
Read any file from a solution's GitHub repo. Returns the file content. Use this to read connector source code, skill definitions, or any versioned file. Default reads from `main` (… Read any file from a solution's GitHub repo. Returns the file content. Use this to read connector source code, skill definitions, or any versioned file. Default reads from `main` (deployed/prod state). Pass `ref: 'dev'` to read in-progress work. ⚠️ NOT RUNTIME STATE. For `solution.json` and `skills/<id>/skill.json` this returns a git MIRROR, not what is deployed. Connector-imported tools are regenerated at deploy time, so a repo copy's `tools[]` can differ from production (on one solution `dev` showed 29 tools while production ran 66). Reads of those paths carry an `_ateam_representation` field saying what you are holding. To answer "what can this skill actually do?", call ateam_get_solution(solution_id, skill_id, section:'tools') — never this tool.
ateam_github_reconcile
dry_runsolution_id*
JOIN a diverged dev and main. Use when ateam_github_promote returns PROMOTE_NEEDS_HUMAN or PROMOTE_PRECONDITION_FAILED — i.e. the automatic main→dev back-merge could not resolve it… JOIN a diverged dev and main. Use when ateam_github_promote returns PROMOTE_NEEDS_HUMAN or PROMOTE_PRECONDITION_FAILED — i.e. the automatic main→dev back-merge could not resolve itself. TRY sync_from_main FIRST; this tool calls it internally (a plain merge keeps both sides with no judgement call) and only escalates when git genuinely conflicts. On conflict it writes a TWO-PARENT merge commit so the histories actually join. That matters: copying one branch's tree onto the other makes the contents match while leaving NO merge base, so the very next promote conflicts again — equal content is not a reconciled history. Conflicting files are resolved per file, NEWEST WINS, and every decision is reported. Recency is a heuristic, not intent: read the decisions. On a real tenant main held the newer solution.json while dev held the newer widget, so a blanket choice would have reverted one of them. WHO NEEDS THIS: any tenant whose deploys predate the dev-routing fix carries main-only commits the platform itself wrote, and hits this on its first promote afterwards. Pass dry_run:true to see the decisions before writing anything.
ateam_github_rollback
target*solution_id*
Roll prod (`main` branch) back to a previous state. ADDITIVE — does NOT destroy history. Creates a new commit on top of main whose tree matches the target's tree. The history of e… Roll prod (`main` branch) back to a previous state. ADDITIVE — does NOT destroy history. Creates a new commit on top of main whose tree matches the target's tree. The history of everything between target and current main is preserved (you can roll back the rollback). Workflow: 1) ateam_github_list_versions (find a safe-* tag) → 2) ateam_github_rollback(target: 'safe-...') → 3) ateam_build_and_run (deploys the reverted state).
ateam_github_status
solution_id*
Check if a solution has a GitHub repo, its URL, and the latest commit. Use this to verify GitHub integration is working for a solution. Check if a solution has a GitHub repo, its URL, and the latest commit. Use this to verify GitHub integration is working for a solution.
ateam_github_sync_from_main
dry_runsolution_id*
BRING `dev` UP TO DATE WITH `main` — merges main into dev. The mirror of ateam_github_promote. USE THIS WHEN PROMOTE RETURNS 409. promote only ships dev→main, so the moment anythi… BRING `dev` UP TO DATE WITH `main` — merges main into dev. The mirror of ateam_github_promote. USE THIS WHEN PROMOTE RETURNS 409. promote only ships dev→main, so the moment anything lands on main directly — a hotfix, a manual edit, an ateam_github_rollback, or a write that mis-targeted the branch — dev falls behind and can never be promoted again. Without this tool that divergence is unfixable from A-Team: the only exits are the GitHub web UI or a raw API call. Workflow on a 409: 1) ateam_github_diff (confirm status:'diverged') → 2) ateam_github_sync_from_main → 3) ateam_github_promote. Pass dry_run:true FIRST to see exactly which commits and files would come into dev without changing anything. This is a real merge, not a force: if main and dev edited the SAME lines it returns 409 too, and that one genuinely needs a human (open a PR).
ateam_github_write
refpath*content*messagesolution_id*
Write a file to the solution's GitHub repo. Use this to create new connector files or replace existing ones — one file per call. This is the PRIMARY way to write connector code aft… Write a file to the solution's GitHub repo. Use this to create new connector files or replace existing ones — one file per call. This is the PRIMARY way to write connector code after first deploy. Write each file individually (server.js, package.json, UI assets), then call ateam_github_promote() to ship to prod (dev→main), then ateam_build_and_run() to deploy. DEFAULTS TO `dev` BRANCH.
ateam_list_solutions
List all solutions deployed in the Skill Builder. List all solutions deployed in the Skill Builder.
ateam_log_lesson
kindtool*error*workedworkaroundsolution_id*
Record ONE lesson this run learned, so the NEXT run does not relearn it. A building agent starts every run empty — it does not know which tool misled the last run or the workaround… Record ONE lesson this run learned, so the NEXT run does not relearn it. A building agent starts every run empty — it does not know which tool misled the last run or the workaround that got past it. Log a lesson the moment a tool misleads you AND you find a way through. APPEND-ONLY. You cannot edit or delete earlier lessons, and you do not supply the timestamp — the server stamps it, so it cannot be forged. PROVENANCE CAVEAT, stated because the earlier wording over-promised: `job_id` and `actor` are recorded ONLY when the caller supplies x-adas-job-id / x-adas-actor-id. An agent calling this tool does not, so those fields are usually null — a lesson cannot currently be traced back to the run that produced it, and the file cannot tell 'three runs hit this' from 'one run hit it three times'. Do not put a job id in `error` to compensate; keep that field verbatim. LOG ONLY WHAT YOU OBSERVED. Quote the error VERBATIM; never paraphrase it and never write a theory about platform internals. A wrong lesson is worse than no lesson, because the next run cannot check it and will act on it. Use kind='misleading_success' when a call REPORTED success while the thing you wanted did not happen — that class is the most expensive to rediscover and it is invisible to a failures-only log.
ateam_log_progress
step*detailstatus*solution_id*verified_by
Record that a build STEP is done, so a later run does not redo it. Write it AS IT HAPPENS, never at the end — the runs that most need a journal are the ones the clock kills. WHY:… Record that a build STEP is done, so a later run does not redo it. Write it AS IT HAPPENS, never at the end — the runs that most need a journal are the ones the clock kills. WHY: a continuation cannot otherwise tell what the previous run achieved, so it re-runs the whole orientation (bootstrap, get_workflows, list_solutions, get_solution, get_spec, get_examples, github_read) to re-derive from documents what was already established — and re-inflates its prompt into the region where provider latency collapses. Measured across 13 runs: stalls track PROMPT SIZE (~60k), not turn count. ateam_get_progress is ONE call instead of nine. status — three values, and the third is the point: built — the artefact exists (files written, committed) deployed — the platform accepted it verified — YOU CALLED IT AND GOT REAL DATA BACK `verified` REQUIRES verified_by, and a deploy response is not verification. `connected` and `tools > 0` are tools/list facts: a clinic connector showed 9 tools while every storage call returned 401. A journal that stops at `deployed` records that build as finished. Re-log the same step as it advances (built → deployed → verified) — latest wins, no update path. If a step REGRESSES, re-log it at the lower status: silence must not read as "still fine".
ateam_patch
sourcetarget*dry_runupdates*skill_idsolution_id*
+2
Surgically update ANY field in a skill or solution definition, redeploy, and optionally re-test — all in one step. ⚠️ MERGE-BY-DEFAULT (v0.4.0) — Arrays are protected from silent… Surgically update ANY field in a skill or solution definition, redeploy, and optionally re-test — all in one step. ⚠️ MERGE-BY-DEFAULT (v0.4.0) — Arrays are protected from silent replace. Bare array writes on solution.linked_skills / ui_plugins / platform_connectors / handoffs / grants / triggers (etc.) and skill.tools / connectors / handoffs / scenarios are REFUSED to prevent sibling loss. Add or remove items with the _push / _delete / _update suffixes; opt into a full-array replace only when you really mean it. OPERATIONS (safe by construction): 1. Scalar (dot notation): { "problem.statement": "new value", "role.persona": "You are..." } 2. Deep nested: { "intents.thresholds.accept": 0.9, "policy.escalation.enabled": true } 3. Array APPEND: { "tools_push": [{ name: "new_tool", description: "..." }] } 4. Array REMOVE: { "tools_delete": ["tool_name"] } 5. Array MODIFY-ONE: { "tools_update": [{ name: "existing_tool", description: "updated" }] } 6. Full-array REPLACE (opt-in): { "linked_skills": [...], "linked_skills_replace": true } — or { _replace: true, ... } to opt every array in this call. SOLUTION-LEVEL EXAMPLES (target='solution'): - ADD a skill to the solution: updates: { "linked_skills_push": ["my-new-skill"] } ← NOT { linked_skills: ["my-new-skill"] } (that would REFUSE — it drops your other skills) - REMOVE a skill: updates: { "linked_skills_delete": ["old-skill"] } - ADD a UI plugin: updates: { "ui_plugins_push": [{ id: "mcp:conn:panel", ... }] } - ADD a handoff: updates: { "handoffs_push": [{ id: "h1", ... }] } SKILL-LEVEL EXAMPLES (target='skill' + skill_id): - Change persona: updates: { "role.persona": "You are a friendly assistant" } - Append to persona: updates: { "persona_append": "\n\nALWAYS respond in 2 sentences." } - Add a guardrail: updates: { "policy.guardrails.never_push": ["Never share passwords"] } - Add a tool: updates: { "tools_push": [{ name: "conn.tool", description: "...", inputs: [...], output: {...} }] } - Change intent: updates: { "intents.supported_update": [{ id: "i1", description: "new desc" }] } - CREATE a new skill: target='skill', skill_id='my-new-skill', updates: { "problem.statement": "...", "role.persona": "..." } — auto-scaffolded and added to solution topology. PREVIEW BEFORE WRITING: pass dry_run:true to see the diff (arrays_merged, arrays_replaced, dropped_ids, added_ids) without applying. Use this before any destructive-looking edit. VERDICT (skill target): the response carries a NON-BLOCKING `validation` block { skill_id, valid, ready_to_export, error_count, incomplete_sections[], unresolved_refs } — the patch always saves even if the def is now invalid, so CHECK valid: false and fix incomplete_sections before relying on it (build_and_run will refuse to deploy an invalid skill). error_count can include auto-import connector-tool artifacts, so act on incomplete_sections first.
ateam_redeploy
skill_idsolution_id*
Re-deploy skills WITHOUT changing any definitions. ⚠️ HEAVY OPERATION: regenerates MCP servers (Python code) for every skill, pushes each to A-Team Core, restarts connectors, and v… Re-deploy skills WITHOUT changing any definitions. ⚠️ HEAVY OPERATION: regenerates MCP servers (Python code) for every skill, pushes each to A-Team Core, restarts connectors, and verifies tool discovery. Takes 30-120s depending on skill count. Use after connector restarts, Core hiccups, or stale state. For incremental changes, prefer ateam_patch (which updates + redeploys in one step).
ateam_show_skill_minimal
skill_id*solution_id*
Show the minimal authoring view of a skill — persona + connectors + handoff_when + style + policy guardrails only. ~10× smaller than ateam_get_solution(view:'skills') for the same… Show the minimal authoring view of a skill — persona + connectors + handoff_when + style + policy guardrails only. ~10× smaller than ateam_get_solution(view:'skills') for the same skill. Use this when you only need the irreducible author content (Phase 9 of the strip).
ateam_show_solution_minimal
solution_id*
Show the minimal authoring view of a solution — name + description + style + routing_mode + identity_mode + skill ids + connector ids only. Skips deployed metadata, handoffs (auto-… Show the minimal authoring view of a solution — name + description + style + routing_mode + identity_mode + skill ids + connector ids only. Skips deployed metadata, handoffs (auto-generated), grants, ui_plugins, validation results. Use this for fast inspection without the verbose fields (Phase 9 of the strip).
ateam_spec_search
query*top_k
Semantic search over the FULL ateam platform /spec documentation — the deep fallback behind ateam_design_advisor. Ask a natural-language 'how do I…' question and get the most relev… Semantic search over the FULL ateam platform /spec documentation — the deep fallback behind ateam_design_advisor. Ask a natural-language 'how do I…' question and get the most relevant doc chunks (with their topic + heading), then read the full topic via ateam_get_spec(topic). Use this when the advisor's pointer isn't enough, or for details/examples on anything — including topics outside the curated capability list. Read-only.
ateam_status_all
Show GitHub sync status for ALL tenants and solutions in one call. Requires master key authentication. Returns a summary table of every tenant's solutions with their GitHub sync st… Show GitHub sync status for ALL tenants and solutions in one call. Requires master key authentication. Returns a summary table of every tenant's solutions with their GitHub sync state.
ateam_sync_all
pull_onlypush_only
Sync ALL tenants: push Builder FS → GitHub, then pull GitHub → Core MongoDB. Requires master key authentication. Returns a summary table with results for each tenant/solution. Sync ALL tenants: push Builder FS → GitHub, then pull GitHub → Core MongoDB. Requires master key authentication. Returns a summary table with results for each tenant/solution.
ateam_test_abort
job_idactor_idchain_idskill_idsolution_id*
Abort a running test. Pass chain_id to abort the WHOLE run — every job in the chain — and get back which ones stopped. Aborting by job_id stops that job only, leaving handoffs runn… Abort a running test. Pass chain_id to abort the WHOLE run — every job in the chain — and get back which ones stopped. Aborting by job_id stops that job only, leaving handoffs running. Stops at the next iteration boundary. (Advanced.)
ateam_test_connector
argstool*solution_id*connector_id*
Call a tool on a running connector and get the result. Use this to test individual connector tools (e.g., triggers.list, entities.list, google.command) without deploying to a clien… Call a tool on a running connector and get the result. Use this to test individual connector tools (e.g., triggers.list, entities.list, google.command) without deploying to a client. The connector must be connected and running.
ateam_test_notification
sourcecontent*urgencyactor_id*metadatasolution_id*
Fire a REAL notification at an existing actor in a deployed solution — for end-to-end testing of the system-initiated notification path (telegram/push/app channels). Unlike ateam_… Fire a REAL notification at an existing actor in a deployed solution — for end-to-end testing of the system-initiated notification path (telegram/push/app channels). Unlike ateam_test_skill (synthetic test actor with no channels) and ateam_conversation (user-initiated thread), this calls the /api/internal/notify-user path that PCM and other sibling services use — so the actor's real enabled channels actually receive the message. Use for: • Channel fan-out smoke (does telegram/push/app actually receive it?) • Delivery-result verification (per-channel ok/failed in the response). Auth: forwards your authed api_key to Core (no master-secret involvement). Tenant is pinned by the key itself — cross-tenant targeting is structurally impossible. ⚠️ SAFETY: • The text is prefixed with [TEST] in the actual notification — visible to the user, anti-phishing. • Rate-limited: 10 calls/min per session. • Every call is audited (caller, tenant, actor, content hash) regardless of outcome. • actor_id is scoped to your tenant — cross-tenant targeting is rejected by Core's per-tenant Mongo isolation. • reply_handler is NOT supported via api-key auth (Core ignores it). Routing the user's next reply to an arbitrary skill is a privilege-escalation surface. For routing/engagement tests, use ateam_test_skill.
ateam_test_pipeline
message*skill_id*solution_id*
Test the decision pipeline (intent detection → planning) for a skill WITHOUT executing tools. Returns intent classification, first planned action, and timing. Use this to debug why… Test the decision pipeline (intent detection → planning) for a skill WITHOUT executing tools. Returns intent classification, first planned action, and timing. Use this to debug why a skill classifies intent incorrectly or plans the wrong action.
ateam_test_skill
waitmessage*actor_idskill_id*wait_forsolution_id*
+1
Send a test message to a deployed skill and get the execution result. Wait modes (wait_for): • 'root' (default, back-compat) — wait until the message's root job completes, retur… Send a test message to a deployed skill and get the execution result. Wait modes (wait_for): • 'root' (default, back-compat) — wait until the message's root job completes, return single-job result. Fast, ignores any sub-skills the root delegated to via askAnySkill. • 'chain' — wait until EVERY job in the chain (root + handoffs + askAnySkill subcalls, recursively) reaches a terminal state, then return the full chain tree. Use when testing multi-skill flows (orchestrator → workers, builders → sub-builders, etc.). The response.chain field carries chainJobs[] with parentJobId/relation/depth and executionSteps[] with tool-nesting (opId/parentOpId/_toolDepth). Legacy: wait:false is equivalent to wait_for:'never' — returns job_id immediately for polling via ateam_test_status. wait:true is the same as the default wait_for:'root'.
ateam_test_status
job_idactor_idchain_idskill_idsolution_id*include_chain
Poll the progress of an async test. Pass chain_id for the WHOLE run (recommended — the root job finishing does NOT mean the run finished; a handoff may still be going). Pass job_id… Poll the progress of an async test. Pass chain_id for the WHOLE run (recommended — the root job finishing does NOT mean the run finished; a handoff may still be going). Pass job_id to poll one job alone: iteration count, tool call steps, status, and result when done. Set include_chain:true to ALSO include the full chain tree (every job in the chain, rooted at this job_id, with parent/child linkage). Use when this job dispatched askAnySkill subcalls and you want a single snapshot of the whole multi-skill state instead of polling each child job_id separately.
ateam_test_voice
messages*skill_slugtimeout_mssolution_id*phone_number
Simulate a voice conversation with a deployed solution. Runs the full voice pipeline (session → caller verification → prompt → skill dispatch → response) using text instead of audi… Simulate a voice conversation with a deployed solution. Runs the full voice pipeline (session → caller verification → prompt → skill dispatch → response) using text instead of audio. Returns each turn with bot response, verification status, tool calls, and entities. Use this to test voice-enabled solutions end-to-end without making a phone call.
ateam_upload_connector
reffilesforcegithubreplacesolution_id*
+1
Upload connector code to Core and restart — WITHOUT redeploying skills. MERGES with the GitHub state at `ref` by default (default ref: 'dev'). Sending a partial file set ONLY over… Upload connector code to Core and restart — WITHOUT redeploying skills. MERGES with the GitHub state at `ref` by default (default ref: 'dev'). Sending a partial file set ONLY overlays those files — the rest of the connector is preserved from GitHub. To fully replace the connector dir (historical behavior), pass replace:true. Modes: • github:true (no files) — deploy the GitHub state at `ref` as-is. • github:true + files:[] — GitHub state at `ref` as BASE, your files overlay on top (incoming wins). • files:[] (no github) — default MERGE with GitHub state at `ref`. Refuses if no GitHub base exists (no silent nuke). • files:[] + replace:true — full replace. Wipes connector dir + writes only the provided files. Use deliberately. Multi-file connectors (server.js + dashboard HTML + RN bundle + package/manifest): pass each file with content_base64 (a single-line, escape-safe base64 string) instead of content — so you don't hand-escape ~90KB of HTML/JS/JSON inside one tool call. This is the CANONICAL agent path for a full connector; do NOT hand-roll `curl` against the raw endpoint (that skips connector registration / PAT provisioning). Common traps this design prevents: • Pre-fix bug (2026-06-06): sending just ui-dist HTML wiped server.js + node_modules — connector broke until a full re-upload. Now: those files merge with the GitHub base. • Pre-fix bug: github:true silently read from `main` even when patches were on `dev`. Now: defaults to dev; pass ref:'main' to opt into the legacy path.
ateam_verify
solution_id*
ONE call that returns the REAL runtime end-state of a solution — connectors connected + tools discovered, every declared widget actually rendering, skills deployed — with the EXACT… ONE call that returns the REAL runtime end-state of a solution — connectors connected + tools discovered, every declared widget actually rendering, skills deployed — with the EXACT failing gaps. Use this instead of guess-and-check after a deploy/patch: it tells you the truth (what's actually live) and names precisely what's broken, not a generic warning. Reliable from any connection (routes through the Builder, not a direct Core call).
ateam_verify_consistency
solution_id*
Check that the Builder filesystem state and GitHub state are in sync for a solution. Read-only probe — does NOT trigger a deploy. Returns: • ok: true + drifts: [] if everything… Check that the Builder filesystem state and GitHub state are in sync for a solution. Read-only probe — does NOT trigger a deploy. Returns: • ok: true + drifts: [] if everything matches • ok: false + drifts: [{path, kind}] listing files that differ (kinds: fs_missing, gh_missing, content_differs) Drift can creep in when GitHub writes happen but Builder FS doesn't get the mirror update (network blip, container restart mid-write). Boot sync heals most of it on next backend restart; this tool surfaces drift earlier. Run after a series of ateam_github_patch calls to confirm the Builder backend is consistent with GitHub before you ateam_build_and_run.
ateam_verify_surface
expectactor_idplugin_id*solution_id*