# io.github.ariekogan/ateam-mcp (remote · mcp.ateam-ai.com)

Build, validate, and deploy multi-agent AI solutions from any AI environment.

- Trust score: 52/100 (low)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mcp.ateam-ai.com`: 52/100 (this document), [markdown](https://verifymcp.io/servers/ariekogan-ateam-mcp/mcp.md), [page](https://verifymcp.io/servers/ariekogan-ateam-mcp/mcp)
- npm · `@ateam-ai/mcp`: 69/100, [markdown](https://verifymcp.io/servers/ariekogan-ateam-mcp/ateam-ai-mcp.md), [page](https://verifymcp.io/servers/ariekogan-ateam-mcp/ateam-ai-mcp)

## Channel facts

- Endpoint: `https://mcp.ateam-ai.com/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.1.2`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 46/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 47 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS check failed: the endpoint is reachable over plaintext HTTP.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 24/100
  - AI-judged instruction clarity (poor).
  - Context-footprint check failed: tool/resource definitions use about 10657 tokens (~226/item across 47 items; 47 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http ariekogan-ateam-mcp https://mcp.ateam-ai.com/mcp
```

### Codex

```toml
[mcp_servers.ariekogan-ateam-mcp]
url = "https://mcp.ateam-ai.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ariekogan-ateam-mcp": {
      "type": "remote",
      "url": "https://mcp.ateam-ai.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add ariekogan-ateam-mcp --url https://mcp.ateam-ai.com/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  ariekogan-ateam-mcp:
    url: "https://mcp.ateam-ai.com/mcp"
```

### Other

```json
{
  "mcpServers": {
    "ariekogan-ateam-mcp": {
      "type": "http",
      "url": "https://mcp.ateam-ai.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 52, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 51, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 50, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 49, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 48, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 47)

First indexed and scored.

## MCP tools (47)

### `ateam_bootstrap` (~73 tokens)

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_auth` (~235 tokens)

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.

Input parameters:

- `api_key` (string): Your A-Team API key (e.g., adas_xxxxx)
- `master_key` (string): Master key for cross-tenant operations. Authenticates across ALL tenants without per-tenant API keys. Requires tenant parameter.
- `tenant` (string): Tenant name (e.g., dev, main). Optional with api_key if format is adas_<tenant>_<hex>. REQUIRED with master_key.
- `url` (string): Optional API URL override (e.g., https://dev-api.ateam-ai.com). Use this to target a different environment without restarting the MCP server.

### `ateam_get_spec` (~604 tokens)

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.

Input parameters:

- `search` (string): Optional: filter the spec to only sections containing this search term. Works with any topic. Example: search='bootstrap' returns only fields/sections mentioning 'bootstrap'.
- `section` (string): Optional: get just one section of the skill spec (only works with topic='skill'). Sections: 'engine' = model/reasoning/planner optimization/bootstrap tools, 'tools' = tool definitions/meta tools, 'in…
- `topic` (string, required): What to fetch: 'overview' = API overview + endpoints, 'skill' = full skill spec, 'solution' = full solution spec, 'enums' = all enum values, 'connector-multi-user' = multi-user connector guide, 'pyth…

### `ateam_get_workflows` (~60 tokens)

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_get_examples` (~159 tokens)

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

Input parameters:

- `type` (string, required): Example type: 'skill' = Order Support Agent, 'connector' = stdio MCP connector, 'connector-ui' = UI-capable connector, 'solution' = full 3-skill e-commerce solution, 'script-cache-skill' = fat-tool s…

### `ateam_design_advisor` (~236 tokens)

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.

Input parameters:

- `design_state` (object): Optional. The design so far (skills, connectors, capabilities already wired) so the advisor can point at what's still missing. Pass {} at the start.
- `goal` (string, required): What you're trying to build, in your own words (e.g. 'a coach that tracks each user's meals from photos and shows a dashboard').

### `ateam_spec_search` (~147 tokens)

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.

Input parameters:

- `query` (string, required): Natural-language question, e.g. 'how do I send a proactive daily reminder?' or 'per-user persistence'.
- `top_k` (number): How many chunks to return (default 8, max 25).

### `ateam_build_and_run` (~528 tokens)

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.

Input parameters:

- `connectors` (array): Optional: connector metadata (id, name, transport). Entry points auto-detected from mcp_store.
- `github` (boolean): Optional: if true, pull connector source code from main. AUTO-DETECTED: if you omit both mcp_store and github, the system checks if a repo exists and pulls from main automatically.
- `mcp_store` (object): Optional: connector source code files. Key = connector id, value = array of {path, content}.
- `skills` (array): Optional after first deploy: skill definitions. If omitted, auto-pulled from main (skills/{id}/skill.json).
- `solution` (object): Full solution definition. Required on first deploy. After first deploy, just pass solution_id instead — everything is auto-pulled from GitHub main.
- `solution_id` (string): The solution ID. Use this INSTEAD of passing the full solution object — the solution definition is auto-pulled from main. Required if solution object is omitted.
- `test_message` (string): Optional: send a test message after deployment to verify the skill works. Returns the full execution result.
- `test_skill_id` (string): Optional: which skill to test (defaults to the first skill).

### `ateam_test_skill` (~467 tokens)

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

Input parameters:

- `actor_id` (string): Optional actor ID for conversation continuity. Pass the actor_id from a previous test response to continue the conversation. Omit to auto-generate a test actor (test_<timestamp>_<random>, auto-expire…
- `chain_timeout_ms` (number): Optional. Max total ms to wait when wait_for:'chain'. Default 300000 (5 min). Long-running chains (skill-factory, large bundle builds) may need higher. Clamped to [10000, 900000].
- `message` (string, required): The test message to send to the skill
- `skill_id` (string, required): The skill ID to test (original or internal ID)
- `solution_id` (string, required): The solution ID
- `wait` (boolean): Legacy: if false, return job_id immediately for polling. If true or omitted, behaves like wait_for:'root'. Prefer wait_for going forward.
- `wait_for` (string): What to wait for before returning. 'root' (default) = root job done; 'chain' = every chain job terminal (use for multi-skill flows); 'never' = return job_id immediately (poll via ateam_test_status).…

### `ateam_test_notification` (~439 tokens)

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.

Input parameters:

- `actor_id` (string, required): Target actor ID in your tenant (e.g. 'usr_arie_admin_0001'). Must exist; Core rejects if not found in your tenant.
- `content` (string, required): Notification text. Will be sent to all of the actor's enabled channels, prefixed with [TEST] for the recipient.
- `metadata` (object): Optional metadata merged into message.metadata. Useful for correlation IDs.
- `solution_id` (string, required): The solution ID (required for tenant scoping + audit context).
- `source` (string): Audit label for message.source. Default 'ateam-test'.
- `urgency` (string): Notification urgency. Default 'normal'.

### `ateam_conversation` (~307 tokens)

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.

Input parameters:

- `actor_id` (string): Optional: actor ID from a previous response to continue the conversation. Omit for a new conversation.
- `message` (string, required): The message to send (e.g., 'send email to X' or 'I confirm')
- `solution_id` (string, required): The solution ID

### `ateam_test_pipeline` (~94 tokens)

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.

Input parameters:

- `message` (string, required): The test message to classify and plan for
- `skill_id` (string, required): The skill ID to test
- `solution_id` (string, required): The solution ID

### `ateam_test_voice` (~197 tokens)

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.

Input parameters:

- `messages` (array, required): Array of user messages to send sequentially (simulates a multi-turn phone conversation)
- `phone_number` (string): Optional: simulated caller phone number (e.g., '+14155551234'). If the number is in the solution's known phones list, the caller is auto-verified.
- `skill_slug` (string): Optional: target a specific skill by slug instead of using voice routing.
- `solution_id` (string, required): The solution ID
- `timeout_ms` (number): Optional: max wait time per skill execution in milliseconds (default: 60000).

### `ateam_patch` (~1064 tokens)

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

Input parameters:

- `dry_run` (boolean): If true, apply the patch in memory and return the diff (arrays_merged, arrays_replaced, dropped_ids, added_ids, would_write_bytes) WITHOUT writing to GitHub or redeploying. Preview a change before co…
- `include_definition` (boolean): If true, return the FULL patched definition. Default false — the result returns a compact patched_summary instead, because the full definition can exceed the ~50KB output limit and truncate the rest…
- `skill_id` (string): Required when target is 'skill'. The skill ID to patch.
- `solution_id` (string, required): The solution ID
- `source` (string): Where the solution/skill definition lives. 'github' (DEFAULT) — read from and write to the tenant's GitHub repo (GitHub is master; the normal path). 'local' — read from and write to the Builder FS st…
- `target` (string, required): What to update: 'solution' for solution definition, 'skill' for skill definition fields (problem, role, intents, tools, policy, engine, scenarios, etc.)
- `test_message` (string): Optional: re-test the skill after patching. Requires skill_id.
- `updates` (object, required): The update payload. Use dot notation for nested scalars (e.g. 'problem.statement': 'new value'). For arrays, use _push/_delete/_update suffixes (e.g. 'tools_push', 'tools_delete'). You can update ANY…

### `ateam_get_solution` (~327 tokens)

Read solution state — definition, skills, health, status, or export. Use this to inspect deployed solutions.

Input parameters:

- `limit` (number): Optional byte-paging: max bytes of the serialized result to return in this page (pair with 'offset'). Omit both for the whole result (may truncate at the output cap).
- `offset` (number): Optional byte-paging: start returning the serialized result from this byte offset. Use with 'limit' to page a result larger than the ~50KB output cap; the response's _paging.next_offset gives the nex…
- `section` (string): Optional (with skill_id): return ONLY this section of the skill instead of the whole definition — avoids the ~50KB output truncation on big skills. Dotted paths work (e.g. 'role', 'tools', 'intents.s…
- `skill_id` (string): Optional: read a specific skill by ID (original or internal)
- `solution_id` (string, required): The solution ID
- `view` (string, required): What to read: 'definition' = full solution def, 'skills' = list skills, 'health' = live health check, 'status' = deploy status, 'export' = exportable bundle, 'validate' = re-validate from stored stat…

### `ateam_list_solutions` (~20 tokens)

List all solutions deployed in the Skill Builder.

### `ateam_delete_solution` (~177 tokens)

⚠️ 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.

Input parameters:

- `confirm` (boolean, required): REQUIRED. Must be exactly true. A missing/false value refuses the call with a recovery hint.
- `confirm_solution_id` (string, required): REQUIRED. Must exactly equal `solution_id`. This defeats typos and hallucinated ids — you can't wipe a solution you couldn't spell.
- `solution_id` (string, required): The solution ID to delete

### `ateam_delete_skill` (~165 tokens)

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

Input parameters:

- `confirm` (boolean, required): REQUIRED. Must be exactly true. A missing/false value refuses the call with a recovery hint.
- `skill_id` (string, required): The skill ID to remove (e.g. 'linkedin-agent')
- `solution_id` (string, required): The solution ID (e.g. 'personal-adas')

### `ateam_delete_connector` (~188 tokens)

⚠️ 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. GitHub source is preserved — a follow-up `ateam_build_and_run(github:true)` can resurrect. REQUIRES `confirm:true`.

Input parameters:

- `confirm` (boolean, required): REQUIRED. Must be exactly true. A missing/false value refuses the call with a recovery hint.
- `connector_id` (string, required): The connector ID to remove (e.g. 'device-mock-mcp')
- `solution_id` (string, required): The solution ID (e.g. 'smart-home-assistant')

### `ateam_show_skill_minimal` (~97 tokens)

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

Input parameters:

- `skill_id` (string, required): The skill ID
- `solution_id` (string, required): The solution ID

### `ateam_show_solution_minimal` (~88 tokens)

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

Input parameters:

- `solution_id` (string, required): The solution ID

### `ateam_create_connector` (~189 tokens)

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.

Input parameters:

- `connector_id` (string, required): Connector ID (lowercase-with-dashes, no spaces). Becomes the directory name.
- `name` (string): Human-readable name for the connector (e.g. 'Hue Lights'). Defaults to connector_id.
- `solution_id` (string, required): The solution ID
- `ui_capable` (boolean): If true, include ui.listPlugins/ui.getPlugin handler stubs. Default: false.

### `ateam_create_plugin` (~439 tokens)

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.

Input parameters:

- `connector_id` (string, required): Existing connector to add the plugin into (e.g. 'personal-assistant-ui-mcp')
- `kind` (string): Render mode. 'adaptive' (default) produces both iframe + RN scaffolds.
- `plugin_name` (string, required): Plugin name (lowercase-with-dashes). E.g. 'memories-panel'. Becomes the dir name.
- `solution_id` (string, required): The solution ID

### `ateam_upload_connector` (~517 tokens)

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.

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.

Input parameters:

- `connector_id` (string, required): The connector ID to upload (e.g. 'personal-assistant-ui-mcp')
- `files` (array): Files to upload. By default merges with the GitHub state at `ref`. Set replace:true to wipe the connector dir and write only these files.
- `github` (boolean): If true, pull connector files from GitHub repo at `ref`. Default: false. Combine with files:[] to use GitHub as the base and overlay your files.
- `ref` (string): GitHub branch to read from for the BASE state. Default: 'dev' (matches ateam_github_patch). Pass 'main' to read from production. Pre-2026-06-05 callers that relied on the silent-main default must pas…
- `replace` (boolean): Opt into FULL REPLACE: wipe the connector dir and write only the provided `files`. Default: false (= merge with GitHub state at `ref`). Use with intent — sending an incomplete file set with replace:t…
- `solution_id` (string, required): The solution ID

### `ateam_test_status` (~198 tokens)

Poll the progress of an async skill test. Returns iteration count, tool call steps, status (running/completed/failed), 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.

Input parameters:

- `include_chain` (boolean): If true, includes response.chain — the full chain tree rooted at this job_id (chainJobs[] with parentJobId/relation/depth, executionSteps[] with tool-nesting). Costs one extra Core call. Default fals…
- `job_id` (string, required): The job ID returned by ateam_test_skill
- `skill_id` (string, required): The skill ID
- `solution_id` (string, required): The solution ID

### `ateam_get_chain` (~369 tokens)

Inspect the full chain tree for any job — rooted at the given job_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.chain.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.chain.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.

Input parameters:

- `job_id` (string, required): The root job ID of the chain to inspect (or any job inside the chain — Core walks up to the root).
- `skill_slug` (string): Optional. The skill slug for the job — speeds up the lookup when the job isn't in memory and must be loaded from storage. Omit if you don't have it; lookup still works but does an extra round-trip.

### `ateam_chain_status` (~226 tokens)

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.

Input parameters:

- `chain_id` (string, required): The chain id returned by ateam_conversation (the conversation's identity). Any job id in the chain also works — Core resolves the chain aggregate.

### `ateam_get_widget_catalog` (~393 tokens)

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.

Input parameters:

- `format` (string): Optional. 'full' (default) returns each widget with its paste-ready how_to_use block (solution.json snippet, opener_call, persona_phrasing, binding_notes). 'summary' returns just id/name/origin/descr…
- `include_unused` (boolean): Optional. If true, includes widgets that are available but not currently referenced by any skill or ui_plugins entry. Default false (only widgets actually wired into the solution).
- `origin` (string): Optional. Filter by widget origin. 'all' (default) returns everything. 'platform' = platform-bundled only. 'solution' = solution-bundled only. 'skill' = skill-declared only.
- `solution_id` (string): Optional. The solution to query. Defaults to the tenant's current solution.

### `ateam_test_abort` (~64 tokens)

Abort a running skill test. Stops the job execution at the next iteration boundary. (Advanced.)

Input parameters:

- `job_id` (string, required): The job ID to abort
- `skill_id` (string, required): The skill ID
- `solution_id` (string, required): The solution ID

### `ateam_test_connector` (~137 tokens)

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.

Input parameters:

- `args` (object): Optional: arguments to pass to the tool
- `connector_id` (string, required): The connector ID (e.g., 'home-assistant-mcp', 'google-home-mcp')
- `solution_id` (string, required): The solution ID
- `tool` (string, required): The tool name to call (e.g., 'triggers.list', 'entities.list', 'google.devices')

### `ateam_get_connector_source` (~183 tokens)

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.

Input parameters:

- `connector_id` (string, required): The connector ID to read (e.g. 'home-assistant-mcp')
- `path` (string): Optional. Read ONE file (e.g. 'server.js', 'ui-dist/panel/index.html'). Omit to get a file manifest (paths + sizes, no content) — a whole connector's source exceeds the ~50KB output limit and truncat…
- `solution_id` (string, required): The solution ID (e.g. 'smart-home-assistant')

### `ateam_verify` (~107 tokens)

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

Input parameters:

- `solution_id` (string, required): The solution ID to verify.

### `ateam_github_push` (~105 tokens)

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.

Input parameters:

- `message` (string): Optional commit message (default: 'Deploy <solution_id>')
- `solution_id` (string, required): The solution ID (e.g. 'smart-home-assistant')

### `ateam_github_pull` (~76 tokens)

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.

Input parameters:

- `solution_id` (string, required): The solution ID to pull and deploy from GitHub

### `ateam_github_status` (~53 tokens)

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.

Input parameters:

- `solution_id` (string, required): The solution ID

### `ateam_github_read` (~155 tokens)

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.

Input parameters:

- `path` (string, required): File path in the repo (e.g. 'connectors/home-assistant-mcp/server.js', 'solution.json', 'skills/order-support/skill.json')
- `ref` (string): Branch, tag, or commit SHA to read from. Default: 'main' (prod). Use 'dev' to read in-progress work.
- `solution_id` (string, required): The solution ID

### `ateam_github_patch` (~310 tokens)

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.

Input parameters:

- `content` (string): The full file content to write (mode 1 — full file replacement)
- `message` (string): Optional commit message (default: 'Update <path>')
- `path` (string, required): File path to create/update (e.g. 'connectors/home-assistant-mcp/server.js')
- `ref` (string): Target branch. Default: 'dev' (safe — won't touch prod). Use 'main' only for emergency hotfixes.
- `replace` (string): Text to replace the search string with (mode 2 — required with search)
- `search` (string): Exact text to find in the file (mode 2 — search/replace). Must match exactly including whitespace.
- `solution_id` (string, required): The solution ID

### `ateam_github_write` (~188 tokens)

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.

Input parameters:

- `content` (string, required): The full file content
- `message` (string): Optional commit message (default: 'Write <path>')
- `path` (string, required): File path to write (e.g. 'connectors/my-mcp/server.js', 'connectors/my-mcp/package.json')
- `ref` (string): Target branch. Default: 'dev'.
- `solution_id` (string, required): The solution ID

### `ateam_github_log` (~103 tokens)

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.

Input parameters:

- `limit` (number): Max commits to return (default: 10)
- `ref` (string): Branch to read commits from. Default: 'main'.
- `solution_id` (string, required): The solution ID

### `ateam_github_diff` (~172 tokens)

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)
  • Inspect arbitrary branch/tag/commit comparisons (override base/head)

Input parameters:

- `base` (string): Base branch/tag/sha (the target — what you're comparing TO). Default: 'main'.
- `head` (string): Head branch/tag/sha (the source — what you're comparing FROM). Default: 'dev'.
- `solution_id` (string, required): The solution ID

### `ateam_verify_consistency` (~173 tokens)

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.

Input parameters:

- `solution_id` (string, required): The solution ID to verify

### `ateam_github_promote` (~241 tokens)

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 merge conflict the call returns 409 — resolve manually on GitHub (open a PR or use the web UI), then retry.

Input parameters:

- `dry_run` (boolean): If true: show the diff (commits + files about to ship) without merging. Default: false.
- `label` (string): Optional: human-readable label for the auto-tag (e.g., 'v2 stable', 'before refactor')
- `skip_tag` (boolean): If true: merge without creating an auto-tag. Default: false (auto-tag enabled).
- `solution_id` (string, required): The solution ID

### `ateam_github_rollback` (~175 tokens)

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

Input parameters:

- `solution_id` (string, required): The solution ID
- `target` (string, required): Tag (e.g., 'safe-2026-05-19-001') or commit SHA to revert main to. Use ateam_github_list_versions to find safe-* tags.

### `ateam_github_list_versions` (~57 tokens)

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.

Input parameters:

- `solution_id` (string, required): The solution ID

### `ateam_redeploy` (~141 tokens)

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

Input parameters:

- `skill_id` (string): Optional: redeploy a single skill only. Omit to redeploy ALL skills in the solution.
- `solution_id` (string, required): The solution ID to redeploy

### `ateam_status_all` (~45 tokens)

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` (~97 tokens)

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.

Input parameters:

- `pull_only` (boolean): Only pull from GitHub to Core (skip push). Default: false (full sync).
- `push_only` (boolean): Only push to GitHub (skip pull to Core). Default: false (full sync).

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/ariekogan-ateam-mcp/mcp#diagnostics

## Score history

- 2026-08-03: 52
- 2026-08-02: 52
- 2026-08-01: 51
- 2026-07-31: 51
- 2026-07-30: 50
- 2026-07-29: 49
- 2026-07-28: 48
- 2026-07-27: 48
- 2026-07-26: 47

## Links

- Remote endpoint: https://mcp.ateam-ai.com/mcp
- Repository: https://github.com/ariekogan/ateam-mcp
- Changelog RSS feed: https://verifymcp.io/servers/ariekogan-ateam-mcp/mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/ariekogan-ateam-mcp/mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/ariekogan-ateam-mcp/mcp