Skip to main content
Glama

ateam-mcp

by io.github.ariekogan

ateam_log_progress

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepYesSTABLE slug a later run can MATCH rather than enumerate: 'connector:<id>', 'skill:<id>', 'widget:<name>', 'seed:<what>'. Keep it identical across runs — a renamed step reads as a new one.
detailNoOne line of what exists — e.g. '10 tools, 8 seeded appointments'.
statusYesbuilt = artefact exists · deployed = platform accepted it · verified = you called it and got real data back
solution_idYesThe solution ID
verified_byNoREQUIRED when status is 'verified': the literal call that proved it and what came back, e.g. 'ateam_test_connector(clinic-data-mcp, appointments.list_all) → 23 rows'. Storing the evidence beside the claim is what makes the journal auditable instead of self-reported.

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries full behavioral disclosure. It reveals no-update-path semantics ('latest wins'), the meaning of silence after regression, and the distinction between a deployment response and genuine verification — including a concrete failure example with a connector showing 9 tools but 401 storage calls.

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 lengthy but well-structured with short labeled sections and front-loaded core purpose. Every major paragraph earns its place through runtime evidence or actionable rules, though a tighter edit could reduce redundancy in the WHY section.

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

Completeness5/5

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

For a write-only journaling tool with five parameters and no output schema, the description is complete: it explains when to call, why it matters, how each status differs, what evidence is required for verified, and the replacement semantics. No essential operational detail is missing.

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?

Input schema coverage is 100%, so the baseline is 3. The description adds meaningful beyond-schema semantics: it explains the three statuses with examples, mandates verified_by for verified, defines the stable-slug requirement for step, and provides a verified_by format example. This meaningfully enriches the schema without repeating it.

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 description opens with a precise verb and resource: 'Record that a build STEP is done, so a later run does not redo it.' It clearly distinguishes the tool from its read-side sibling ateam_get_progress, making the operation's scope immediately unambiguous.

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?

Usage is explicitly prescribed: 'Write it AS IT HAPPENS, never at the end', with a concrete reason grounded in how continuation runs fail. The description also instructs when to re-log (advancing statuses) and when to regress, leaving no ambiguity about timeliness or replacement behavior.

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