Ateam MCP

Compare the current Builder definition against what's deployed in ADAS Core. Shows which skills are undeployed, orphaned, or have changed fields. (Advanced.)

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 to…

Read a connector's AUTHORED source — the code the Builder holds as the source of record (its authored store, or GitHub). Returns a file manifest, or one file's content with path:'<file>'. Use this BEFORE patching or rewriting a connector, so you make surgical fixes instead of blind full rewrites. Every answer carries `provenance` (authored_fs | github) so you know which store you are reading. This does NOT return what Core is currently RUNNING. Those are different questions and used to share one answer: a connector could be deployed and healthy while no authored copy of it existed anywhere, a…

Read the DEPLOYED copy of a connector — the files ADAS Core is actually running. This is a runtime projection of the last successful deploy, NOT the source of record: it can differ from the authored source, and it may exist for a connector the Builder cannot reproduce at all. Answers carry authored_source_of_record:false so that is never in doubt. Use it to diagnose ("what is actually running?"), to compare against ateam_get_connector_source, or to inspect a connector whose authored source is missing before deciding whether to adopt it with ateam_recover_connector_source. Do NOT copy bytes ou…

Get complete working examples that pass validation. Study these before building your own.

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.)

Read what EARLIER runs on this solution learned — the CURRENT lessons, newest first, bounded, each with its `id`. 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). Every answer carries `correction_rule`: how a lesson that proved wrong is corrected. A superseded lesson is counted in `superseded_count`, never listed in `lessons`; include_superseded:true ret…

Get execution metrics — timing, tool stats, bottlenecks, signals, and recommendations. (Advanced.)

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.

Description is built at runtime.

Read solution state — definition, skills, health, status, or export. Use this to inspect deployed solutions. status and health also answer `running`: the commit last deployed, the ref asked, who deployed it and when, and whether the solution was deployed to again since (known:false and the reason when no deploy was recorded).

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. Needs no sign-in. Every answer carries `served_by`: the environment whose API answered (prod or dev, or the API base itself for any other host), the API this session talks to, so two environments' docs are never read as one. When designing a persona that orchestrates …

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 t…

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.

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 re…

Description is built at runtime.

View commit history for a solution's GitHub repo. Shows recent commits with messages, SHAs, timestamps, and links. Default reads `dev`, the working branch your writes land on (the Builder picks it when no ref is passed). Pass `ref: 'main'` to see what has been promoted to production. The response's `branch` says which one you got.

Edit a file in the solution's GitHub repo and commit — ONE file per call. 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) 3. DELETE A STRAY: `delete: true` — removes a stray connector file, of either kind: one at the repo root, OUTSIDE connectors/<connector-id>/ (a root server.js, package.json or ui-dist/…), or a copy NESTED under a connector's own prefix (connectors/<connector-id>/connectors/<connector-id>/…). Co…

SHIP DEV TO PROD. Moves `main` forward to the exact version tried on `dev` (no merge commit) and auto-tags the new main HEAD as prod-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 (moves main to the tested dev version) → 3) ateam_build_and_run (deploys main). Pass dry_run:true to see what's about to ship without merging. main only ever moves to a commit dev already has, so a promote does not conflict. An older repo where main holds a commit dev never received is bro…

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. It REPLACES the Builder's copy of each file with the repo's (`dev`). Where the Builder holds a change that never reached GitHub (a save held off `dev`, one whose push failed, a file changed on both sides), that change would exist nowhere afterwards, so the pull is REFUSED (409 UNPUSHED_BUILDER_CHANGE, naming the files) before anything is uploaded or deployed — unless you pass…

Push the solution to its GitHub repo. When it runs, what it writes, and what it keeps as the branch holds it: ateam_get_spec({ topic: "overview", search: "github/push" }).

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 `dev`, the working branch your writes land on (the Builder picks it when no ref is passed, and creates it if the repo has none yet). Pass `ref: 'main'` to read the promoted/production state. The response's `branch` says which one you got. ⚠️ 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…

Description is built at runtime.

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.

BRING `dev` UP TO DATE WITH `main` — merges main into dev. The mirror of ateam_github_promote. REPAIR TOOL FOR AN OLD REPO — not a step of building or shipping. main now only moves to a commit dev already has, so dev does not fall behind it and a promote does not return 409. Use this only when ateam_github_diff shows status:'diverged' on a repo that split before that rule. Workflow: 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 an…

Write a NEW file to the solution's GitHub repo — one file per call. A file that ALREADY EXISTS is changed with ateam_github_patch search/replace (send only the lines that change), never rewritten whole here: streaming a whole file costs minutes. Use it for new connector files. Write each file individually under connectors/<connector-id>/ (server.js, package.json, ui-dist/… assets), then call ateam_github_promote() to ship to prod (dev→main), then ateam_build_and_run() to deploy. Core deploys connectors/<connector-id>/ only, so a connector file written anywhere else (a root server.js, package.j…

Read what is STORED for this workspace (conversations, jobs, messages, memories, configuration) when debugging needs the data, not just the logs. You get the data, never the database: read-only, this workspace only, credentials removed ([redacted]), every read logged with who asked. Workspace admins and owners only; off until a platform admin enables it (SysAdmin, Data Inspection): DATA_INSPECT_DISABLED. Methods: 'collections' (what can be read, with counts; start here), 'find' (collection, filter, projection, sort, limit<=100, skip), 'count' (collection, filter), 'aggregate' (collection, pip…

List all solutions deployed in the Skill Builder.

Record ONE lesson this run learned, so the NEXT run — which starts empty — does not relearn it. Log it the moment a tool misleads you AND you find a way through. You cannot edit or delete earlier lessons; supersede them: `supersedes` takes the `id` of the lesson to replace, from ateam_get_lessons, whose `correction_rule` says when and how. An unknown id is refused (404); a lesson already superseded is refused (409) naming the current one. The server stamps the id and the time. PROVENANCE: `job_id` and `actor` are usually null (an agent calling this tool sends no x-adas-job-id / x-adas-actor-…

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_p…

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.stateme…

ADOPT the deployed copy of a connector as its AUTHORED source. The only sanctioned Core→Builder direction, and deliberately explicit: it is never part of a deploy. Use it when a connector is running in Core but has no authored source (ateam_get_connector_source returns AUTHORED_SOURCE_MISSING) — the running bytes may be the only surviving copy of real work. The recovered files are STAMPED as recovered_from_core with a timestamp, so a reconstruction is never later mistaken for code someone wrote. Refuses with AUTHORED_SOURCE_EXISTS if authored source is already present; pass force:true only af…

Description is built at runtime.

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).

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).

Send a message to the Solution Bot — an AI assistant that understands your deployed solution and can help with modifications. (Advanced.)

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); an example a hit names or points to (examples/<type>, /spec/examples/<type>) is read via ateam_get_examples(type), which ateam_get_spec does not serve. 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. Needs NO sign-in, …

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.

Sync ALL tenants: ateam_github_push for each solution (what it writes, and what it keeps: ateam_get_spec({ topic: "overview", search: "github/push" })), then pull GitHub → Core MongoDB. Requires master key authentication. Returns a summary table with results for each tenant/solution.

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. The abort uses the actor the test's start ran as, whatever actor_id says: Core stops a job that actor may access and refuses any other with 403 JOB_ACCESS_DENIED, so an anonymous abort stops only anonymous runs. Who a test runs as: ateam_get_spec({ topic: "skill", search: "actor_id" }) → testing_and_runtime.conversation_testing.key_concepts.actor_id. (Advanced.)

Call ONE tool on a running connector DIRECTLY and get its raw result — no skill, no guardrails, no user turn. It proves a tool's plumbing (arguments in, result out). It can NOT prove a step that waits for a person — a confirmation, an approval, a value only the user knows: test those with ateam_conversation (ateam_get_spec('skill') → agent_guide.key_concepts.testing_and_runtime.human_step_testing). Never call a write tool with ateam_test_connector on a record your test did not create. Who a test runs as: ateam_get_spec({ topic: "skill", search: "actor_id" }) → testing_and_runtime.conversation_…

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 and ateam_conversation (a test turn answered in the tool result; who it runs as: their actor_id), 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). …

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.

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 a…

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.

Simulate a voice call with text, not audio. A person's key reaches the skill (skill job included); with no person on the key, or a phone caller, Core refuses the skill call today (C6): test it with ateam_conversation. Each turn returns response, verification, entities; ran_as repeats its actor_id. Who a test runs as: ateam_get_spec({ topic: "skill", search: "actor_id" }) → testing_and_runtime.conversation_testing.key_concepts.actor_id.

Update a deployed solution or skill incrementally using PATCH. (Advanced — prefer ateam_patch which updates + redeploys + tests in one step.)

Upload connector code to Core and restart it. Then the skills that import this connector's tools are redeployed when they need it — a redeploy of the WHOLE skill as the Builder holds it, so its other connectors' tools and any saved edit not yet deployed go live too. The reply's skill_tools says, per skill and per connector, what changed in what Core runs; stages.skills is its verdict. A tools[] you wrote yourself is never changed. The rule: ateam_get_spec('skill') → agent_guide.key_concepts.how_a_skill_gets_its_tools.when_the_connector_changes. Modes: • github:true — deploy connectors/<id>/…

Upload source files for a connector's MCP server. Use this INSTEAD of mcp_store in ateam_build_and_run when the source code is too large to inline. Upload files first, then build_and_run without mcp_store. (Advanced.)

Validate a skill definition through the 5-stage A-Team validation pipeline. Returns errors and suggestions to fix. (Advanced — ateam_build_and_run validates automatically.)

Validate a governed AI Team solution — cross-skill contracts, grant economy, handoffs, and LLM quality scoring. (Advanced — ateam_build_and_run validates automatically.)

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. ok:false with gaps is the answer; a result that also carries `error` means a check could not run (key refused, Builder down) — that is a failed call, not a verdict. Reliable from any connection (routes through the Builder, not a direct Core ca…

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, consistent, drifts: [{path, kind}] }: • consistent: true + drifts: [] if everything matches • consistent: false + drifts listing files that differ — kind ∈ fs_missing | content_differs | gh_missing | gh_read_error | repo_unreachable `ok` says the probe RAN; `consistent` is the answer. Drift is consistent:false, not a failed call. The comparison strips ephemeral fields (timestamps, runtime/deploy-state, resolved-on-load flags), so only REAL c…

PROVE a connector ui_plugin actually renders WITH DATA — the required evidence that a user-visible UI fix is done. A plugin fetches its data over postMessage from its parent window, so opening its iframe alone shows the empty state and 'confirms' the very bug you're checking. This opens the plugin in the REAL host surface in headless Chromium, records every MCP tool call it makes, and returns { ok, verdict, visible_text, calls, failures }. It distinguishes 'invented tool name' / 'right tool, no data' / 'plugin never asked'. FAIL-CLOSED: a browser-mcp outage returns ok:false verdict:'inconclusi…

Description is built at runtime.

Description is built at runtime.

Description is built at runtime.

Description is built at runtime.

Description is built at runtime.

Render + write (or refresh) CLAUDE.md in the solution's GitHub repo. Auto-generates the onboarding header from the deployed solution/skill/connector definitions and preserves any solution-specific notes below the sentinel line. Normally called automatically on every ateam_build_and_run so CLAUDE.md stays in sync — use this tool directly to backfill existing solutions or to force a refresh.