Skip to main content
Glama

ateam-mcp

by io.github.ariekogan

ateam_upload_connector

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNoGitHub 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 pass ref:'main' explicitly.
filesNoFiles to upload — each needs 'path' plus ONE of content (inline string) or content_base64 (escape-safe base64; preferred for multi-file connectors). By default merges with the GitHub state at `ref`. Set replace:true to wipe the connector dir and write only these files.
forceNoRECOVERY: respawn the connector + re-inject its CURRENT env even when the source is UNCHANGED. Normally an unchanged-source upload no-ops (unchanged:true) and leaves the process running. But a connector spawned before a shared-secret rotation keeps the STALE secret — it still lists tools (looks healthy) yet 401s on every per-actor call, with no recovery short of a fake source edit. Use `ateam_upload_connector(solution_id, connector_id, github:true, force:true)` to pull the current source and force a fresh respawn (which picks up the current secret). Default: false.
githubNoIf true, pull connector files from GitHub repo at `ref`. Default: false. Combine with files:[] to use GitHub as the base and overlay your files.
replaceNoOpt 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:true will break the connector.
solution_idYesThe solution ID
connector_idYesThe connector ID to upload (e.g. 'personal-assistant-ui-mcp')

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full safety burden and discharges it thoroughly: it discloses restart behavior, merge semantics, the 'Refuses if no GitHub base exists (no silent nuke)' safety guard, the destructive 'Wipes connector dir' effect of replace:true, the unchanged-source no-op in force, and even explains the two pre-fix bugs it was designed around. Nothing about side effects is left for the agent to discover at runtime.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section earns its place: front-loaded purpose, then merge semantics, then compact bulleted modes with bolded option labels, then practical base64 guidance, then a short traps section. The structure makes the length navigable; only the historical bug narratives could arguably be trimmed, but they serve as behavioral documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool with 7 params, 4 modes, a destructive option, and zero annotations, the description is remarkably complete: it covers merge behavior, refusal safety, wipe behavior, recovery via force, base64 escaping, and ref defaulting. The only minor gaps are that no output/response shape is described (no output schema exists to carry that burden) and no permission/auth prerequisites are mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds genuine value on top of the schema by explaining compositional semantics the per-parameter descriptions don't convey: how github:true and files:[] interact (base + overlay), the force/recovery scenario tied to stale shared secrets, and the recommendation to prefer content_base64 for multi-file connectors. This cross-parameter guidance exceeds what the individual property descriptions provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence 'Upload connector code to Core and restart — WITHOUT redeploying skills' names a specific verb, resource, and the key scope exclusion that distinguishes it from sibling redeploy/sync tools. The clarifying contrast ('WITHOUT redeploying skills') immediately tells an agent this is not ateam_redeploy or a GitHub write tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The four enumerated modes spell out exactly which parameter combinations to use for which outcome (github-only, github+overlay, merge, full replace). It explicitly names the anti-pattern alternative ('do NOT hand-roll curl against the raw endpoint') and declares itself the 'CANONICAL agent path', giving the agent a clear decision rule that also routes around sibling GitHub tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ateam-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, with detailed descriptions that differentiate similar functions like chain polling vs. chain inspection. However, there is slight overlap between ateam_design_advisor, ateam_get_spec, and ateam_spec_search, which all serve design guidance, potentially causing confusion if descriptions are not read carefully.

Naming Consistency4/5

The naming mostly follows a consistent verb_noun pattern with the 'ateam_' prefix (e.g., ateam_get_solution, ateam_create_connector, ateam_test_skill). Minor deviations include ateam_patch (missing object) and ateam_redeploy (verb only), but overall the pattern is predictable and clear.

Tool Count3/5

With 47 tools, the count is high and exceeds the typical 15-tool threshold for a well-scoped set. However, the tools cover a broad and complex platform (auth, deployment, testing, GitHub integration, scaffolding), and each tool appears to have a distinct role, making the count borderline acceptable rather than excessive.

Completeness4/5

The tool set covers the full lifecycle of building, deploying, testing, and managing A-Team solutions, including design, GitHub integration, and verification. Minor gaps exist, such as no explicit tool for deleting individual files (though patching can overwrite) and no standalone skill listing, but these are not critical dead ends for an agent.

Resources