ateam-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.52
Disambiguation5/5
Each tool targets a distinct purpose. Authentication, onboarding, CRUD for connectors/skills/solutions, various GitHub operations (patch, promote, push, pull, rollback), and multiple testing modes (skill, connector, notification, voice, pipeline) are all clearly separated. No two tools perform the same function, and descriptions are detailed enough to differentiate similar operations like ateam_build_and_run vs ateam_redeploy.
Naming Consistency4/5
All tools share the ateam_ prefix and most follow a verb_noun pattern (e.g., ateam_create_connector, ateam_test_skill). However, a few tools use noun-only names (ateam_conversation, ateam_get_examples) or compound verbs (ateam_build_and_run), breaking the pattern slightly. Overall, the naming is largely consistent and predictable.
Tool Count3/5
With 41 tools, the server exceeds the typical range of 3-15 tools for a well-scoped server. However, the domain is broad, covering authentication, CRUD, GitHub integration, testing, and admin operations, which justifies many tools. Some consolidation might be possible, but the count is borderline heavy.
Completeness5/5
The tool surface covers the full lifecycle of solution development: onboarding, authentication, creating/deleting/reading components, comprehensive GitHub operations (diff, log, patch, promote, push, pull, rollback, status), multiple testing modalities (skill, connector, notification, voice, pipeline, abort, status), and admin tools (sync_all, status_all). No obvious gaps are evident.
Average 4.3/5 across 41 of 41 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 7 community issues answered or closed in the last 6 months
- 133 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states the action without disclosing that the operation is read-only, or any authentication, rate limits, or pagination behavior. Listing inherently suggests non-destructive behavior, but explicit disclosure is missing.
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 a single concise sentence that front-loads the core purpose. However, it could be considered under-specified, but for its brevity it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should provide hints about the return format (e.g., list of names or IDs). It does not, leaving the agent uncertain about the response. Given the tool's simplicity, it is marginally adequate but incomplete.
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?
The tool has zero parameters and schema coverage is 100%. With no parameters, the baseline score is 4, and the description does not need to add parameter details, though it could hint at implicit filtering.
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 uses a specific verb ('List') and identifies the resource ('all solutions deployed in the Skill Builder'). It clearly distinguishes from sibling tools like ateam_get_solution (single solution) and ateam_show_solution_minimal (minimal view) by indicating scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ateam_get_solution or ateam_show_solution_minimal. The description does not indicate prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It indicates a read operation but does not mention authentication needs, side effects, idempotency, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the action, effectively summarizing the tool's purpose without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the overall purpose and view options but lacks details on output format, error conditions, or permission requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 no additional meaning beyond the schema; it merely restates the purpose.
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 clearly states a specific verb ('Read') and resource ('solution state — definition, skills, health, status, or export'), distinguishing it from sibling tools that perform writes or list all solutions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'Use this to inspect deployed solutions,' providing positive context, but lacks explicit guidance on when not to use it or alternatives for listing or modifying solutions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses two-phase sync and authentication, but omits critical behavioral details like potential data overwrites, performance impact (many tenants), error handling, or reversibility. For a potentially destructive bulk operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences front-load purpose and authentication, followed by output type. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-tenant sync tool with no output schema or annotations, the description is incomplete. It does not explain summary table contents, prerequisites (e.g., GitHub repository existence), conflict resolution, or error behavior. Adequate for basic understanding but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The description adds context about the sync flow (push then pull) and mentions the push_only/pull_only options, but does not significantly enhance parameter understanding beyond what schema already provides.
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?
Description explicitly states the tool syncing all tenants with a two-phase process: push Builder FS to GitHub then pull GitHub to Core MongoDB. It clearly distinguishes from sibling tools like ateam_github_push and ateam_github_pull which operate on individual tenants/repos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions authentication requirement but does not explicitly specify when to use this tool versus alternatives like per-tenant push/pull. The 'ALL tenants' context implies bulk usage, but no when-not-to or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states abort happens at the next iteration boundary, giving some detail on execution. However, it does not disclose side effects (e.g., state of the test), reversibility, or safety considerations for repeated calls. For an 'advanced' action, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a parenthetical. Every word earns its place, front-loading the core action. No redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required params, no output schema) and lack of annotations, the description is adequate but could be more complete. It omits error conditions (e.g., aborting a non-existent or finished job) and consequences, which would help the agent use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with minimal descriptions for each parameter (e.g., 'The solution ID'). The tool description adds no additional meaning beyond the schema. Since the parameters are straightforward and the schema already conveys their purpose, a baseline score of 3 is appropriate.
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 clearly states the action ('Abort a running skill test') and the resource. It adds detail about when the abort occurs ('at the next iteration boundary') and marks it as advanced. This distinguishes it from siblings like ateam_test_skill (run) and ateam_test_status (status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for stopping a running test but does not explicitly state when to use it versus alternatives or when not to use it. It lacks prerequisites (e.g., need a job ID from a running test) or exclusion criteria. The '(Advanced.)' tag hints at caution but provides no specific guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It only states 'get complete working examples' but provides no details on side effects, authentication needs, rate limits, or read-only nature. This is a significant gap for an operation that likely retrieves data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no redundant words, and front-loads the essential action. Every sentence contributes meaning.
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?
Given the tool has only one parameter and no output schema, the description sufficiently covers the purpose. It might benefit from indicating what the examples look like, but the use case (studying) is clear enough for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed enum descriptions in the schema. The description adds no additional parameter meaning beyond what the schema provides, meeting the baseline for high coverage.
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 clearly specifies the verb 'get' and the resource 'complete working examples that pass validation', with a clear purpose of studying before building. It effectively distinguishes from sibling tools as no other tool fetches examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Study these before building your own'), providing a clear context of use. However, it does not mention when not to use or list alternative tools, though the sibling set has no obvious alternative for this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses auto-creating the repo and atomic commits, but does not mention permissions, rate limits, conflict handling, or reversibility. Adequate but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, then usage guidance. Every word adds value. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description does not mention return values (e.g., commit hash, success message). It also omits prerequisites like authentication or git configuration, and error conditions. For a mutation tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds no new parameter details beyond the schema. The text reiterates the commit message default, which is already in the schema. The context about auto-creating repo and atomic commits is helpful but not specific to parameters.
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 clearly states the tool pushes the deployed solution to GitHub, auto-creates repo on first use, and commits the full bundle atomically. It uses a specific verb (push) and resource (solution to GitHub), distinguishing it from siblings like ateam_github_pull or ateam_github_rollback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using after ateam_build_and_run to version the solution or anytime to snapshot, giving clear context for when to use. However, it does not explicitly state when not to use or provide alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions Core restart and two input modes, but omits destructive potential, auth requirements, rate limits, and error conditions common to mutation tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no redundancy. Every word adds value. Front-loaded with key purpose and constraint.
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?
No output schema. Covers purpose, modes, and sibling differentiation. Could clarify exclusivity of github and files, and add result expectations. Still fairly complete for a 4-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds context about github vs files modes and example connector ID, but does not significantly extend schema information. Baseline 3 is appropriate.
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?
Description specifies uploading connector code to Core and restarting without redeploying skills, clearly distinguishing from sibling ateam_build_and_run. Includes examples (server.js, UI assets, plugins) and alternative input modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with ateam_build_and_run for connector-only changes, guiding when to use. Lacks explicit when-not-to-use scenarios, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It implies a read operation ('Show') and notes the reduced data volume (~10× smaller). However, it omits details on error conditions, authentication needs, or response format – acceptable for a simple read tool but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver purpose, composition, size comparison, and usage guidance. Every word earns its place. No unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should hint at return structure. It lists included components but not how they're presented (format, nesting). Given the tool's simplicity, it's adequate but not complete – missing output format and potential error responses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but param descriptions are minimal ('The solution ID', 'The skill ID'). The tool description adds no further semantics beyond naming the parameters. Baseline 3 is appropriate as schema does the basic job, but no added value from description.
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 clearly states the verb 'Show' and resource 'minimal authoring view of a skill', listing specific components (persona, connectors, etc.). It contrasts with sibling ateam_get_solution, establishing distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Use this when you only need the irreducible author content (Phase 9 of the strip)' and provides a size comparison with ateam_get_solution. It could add explicit when-not-to-use scenarios, but the directive is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the effects: stops connector, deletes from A-Team Core, removes references in solution definition and skill definitions, cleans up mcp-store files. This gives good insight into the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with bullet-like list of actions, no fluff. Efficiently conveys all necessary information.
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 delete operation with no output schema, the description fully explains what happens. Could mention if operation is idempotent or error conditions, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds examples but no extra semantics beyond what the schema already provides.
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?
Clearly states 'Remove a connector from a deployed solution' with specific actions (stops, deletes, removes references, cleans up). Distinct from sibling tools like ateam_create_connector and ateam_delete_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for removing connectors, but no explicit when-to-use or when-not-to-use compared to alternatives. Lacks prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. Mentions internal steps (reads specific files, deploys) but does not disclose side effects like overwriting existing deployment, auth requirements, or potential duration. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key action, no redundant words. Efficient and well-structured.
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?
Covers purpose, internal steps, and use cases. Missing details on return behavior or prerequisites, but adequate for a simple single-param tool with rich sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (solution_id) with schema description already clear. Description adds process context but no new semantics about the parameter itself. Schema coverage is 100%, baseline 3 is appropriate.
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?
Clearly states 'Deploy a solution FROM its GitHub repo' with specific actions (reads .ateam/export.json, feeds into deploy pipeline). Distinguishes from siblings like push/patch/rollback by focusing on deploying from GitHub.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to restore a previous version or deploy from GitHub as the source of truth.' Provides use context. Does not list exclusions, but sibling list implies alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden of behavioral disclosure. It indicates a read-only check of GitHub status, but does not disclose potential errors, prerequisites, or behavior when no repo exists. A score of 3 is appropriate as it is not misleading but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and usage. Every sentence adds value with no wasted words.
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?
Given no output schema, the description hints at the output (repo existence, URL, latest commit) but does not specify format or structure. However, for a simple status check, this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter (solution_id). The description adds context about the tool's purpose but does not elaborate on parameter semantics beyond what the schema already provides.
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 uses a specific verb 'Check' and resource 'solution's GitHub repo, URL, and latest commit', clearly distinguishing it from sibling GitHub tools like read, diff, log. It also states the use case: verify GitHub integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to verify GitHub integration is working for a solution', providing clear context. It does not explicitly mention when not to use or list alternatives, but the context implies it for status checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the tool scaffolds plugins and auto-discovers at next deploy, but does not disclose potential side effects, authentication needs, or rate limits. It adds some behavioral context but could be more comprehensive.
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 concise with four sentences, front-loaded with purpose. It avoids fluff, though the reference to 'Phase 5 of the strip' may be unclear to new users.
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?
Given no output schema and no annotations, the description covers the essential aspects: what it does, parameter usage, and post-action behavior (auto-discovery). It is adequate for a scaffolding tool, though return values are not 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?
Although schema coverage is 100%, the description adds value by explaining the kind enum values, giving an example for connector_id, and noting plugin_name becomes the directory name. This goes beyond the schema definitions.
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 clearly states the tool scaffolds a UI plugin inside an existing connector, specifying types (iframe, rn, adaptive) and the benefit of eliminating boilerplate. It distinguishes from siblings like ateam_create_connector by focusing on plugin creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides guidance on when to use each kind value (iframe for web, rn for mobile, adaptive for both) and implies the prerequisite of an existing connector. However, it does not explicitly mention when not to use this tool or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the action as calling a tool and getting results, implying it is non-destructive but does not explicitly state side effects, permissions, or output format. Could be more specific about being a test only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by usage context. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, description does not explain what the result looks like or how errors are reported. It mentions prerequisite but lacks details on return format, pagination (if any), or error handling. For a test tool, knowing the response structure would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. Description adds value with examples for 'tool' parameter and notes 'args' is optional, but does not significantly enhance understanding beyond the schema.
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?
Description clearly states the action: 'Call a tool on a running connector and get the result.' It provides examples like 'triggers.list', 'entities.list', and 'google.command', making the resource specific. It distinguishes from sibling tools like ateam_bootstrap or ateam_conversation by focusing on testing individual connector tools.
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?
Explicit guidance: 'Use this to test individual connector tools without deploying to a client.' Also states prerequisite: 'The connector must be connected and running.' This clearly tells when and how to use the tool, differentiating it from other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses default wait up to 60s and async option with job_id. Lacks details on timeout, errors, or idempotency, but core behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return format. Mentions 'full execution result' and 'job_id', but lacks detail on what the full result contains. Could be more complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. Description adds value for the `wait` parameter by explaining sync/async behavior, but does not add semantic info for other parameters beyond what schema already provides.
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?
Clearly states the action ('send a test message'), the resource ('deployed skill'), and the output ('full execution result'). Distinguishes from siblings like ateam_test_status (polling) and ateam_test_abort.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use sync vs async mode and directs to ateam_test_status for polling. Does not explicitly mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses destructive behavior: removes the solution from both Skill Builder and A-Team Core. With no annotations provided, this description adequately informs about the irreversible nature and scope of deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste. Front-loaded with purpose, then adds caution and use case. Every sentence earns its place.
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 delete tool, description covers purpose, usage guidance, and behavioral effects. Lacks mention of return value, but no output schema exists. Adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'solution_id' with clear schema description. High schema coverage (100%) means description adds no extra meaning beyond what's already in the schema. Baseline score of 3 is appropriate.
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?
Description clearly states it deletes a deployed solution and all its skills from A-Team, specifying the resource and action. It distinguishes from sibling tools like ateam_delete_skill by noting it removes the entire solution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises caution and states it is useful for cleaning up test solutions or starting fresh. Provides clear context for when to use, though it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Discloses it reads file content, default branch is main (prod), and ref option for dev. Does not mention return format beyond 'file content', auth, or rate limits, but adequate for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. Front-loaded with purpose. Every sentence adds value.
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?
No output schema, but description explains return value as file content. Covers default branch and dev usage. For a simple read tool, it is fairly complete.
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%, but description adds concrete examples for path and clarifies default behavior for ref. These details help beyond schema.
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?
Description clearly states verb 'Read' and resource 'file from solution's GitHub repo'. It distinguishes from siblings like ateam_github_write and ateam_github_diff by focusing on read-only access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'read connector source code, skill definitions, or any versioned file'. Mentions default branch and dev option. Lacks explicit when-not-to-use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It clearly states that the tool does not execute tools and returns specific information (intent classification, first action, timing). This is good transparency for a test tool, though it could mention any side effects (likely none).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first covers the purpose and behavior, the second gives usage guidance. It is front-loaded and every sentence adds value without unnecessary detail.
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?
Given the tool's complexity (testing a multi-step pipeline), the description covers the core purpose, inputs (schema handles the rest), and outputs (returns classification, action, timing). With no output schema, the description adequately explains return values. It lacks mentions of authentication or prerequisites, but these may be assumed or handled globally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters with descriptions. The description adds no additional parameter information beyond what is in the schema. Baseline score of 3 is appropriate.
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 clearly states the tool's purpose: testing the decision pipeline without executing tools. It specifies the outputs (intent classification, first planned action, timing) and distinguishes it from execution tools by emphasizing the non-execution aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this to debug why a skill classifies intent incorrectly or plans the wrong action.' It does not mention when not to use it or alternative tools among the siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes a read-only listing operation but does not explicitly state it is safe or mention any authentication requirements or rate limits. The behavioral disclosure is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the action and output, the second provides usage guidance. No wasted words, front-loaded with essential information.
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?
Given the lack of an output schema, the description specifies the output fields (tag name, date, counter, commit SHA). The tool has only one parameter and the description covers its purpose and usage context completely.
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?
The only parameter solution_id has a schema description 'The solution ID.' The tool description adds context by explaining that the parameter identifies which solution to list checkpoints for and what output fields are returned (tag name, date, counter, commit SHA), adding value beyond the schema.
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 clearly states the tool lists available checkpoints (safe-* tags) for a solution, specifying the output fields (tag name, date, counter, commit SHA). This distinguishes it from sibling tools like ateam_github_rollback or ateam_github_diff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use before rollback to see available safe points,' providing clear usage context. It does not mention when not to use it or alternatives, but for this simple tool it is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the write behavior (creates/replaces, one file per call, defaults to dev branch). However, it does not disclose details about authentication, what happens on overwrite, or commit behavior beyond the message parameter. The description is adequate but lacks some behavioral specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three efficient sentences plus a one-line note, with no wasted words. Key information is front-loaded, and the structure flows logically from action to usage to pipeline guidance.
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?
Given the tool's simplicity and full parameter coverage, the description is complete. It explains the tool's role in the deployment pipeline, references related tools (ateam_github_promote, ateam_build_and_run), and provides all necessary context for an AI agent to use it correctly.
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?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining the path pattern ('connectors/my-mcp/server.js') and reinforcing that content is full file content. It also clarifies the commit message default and branch default, providing context beyond the schema fields.
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 clearly states the action ('Write a file'), the resource ('solution's GitHub repo'), and the purpose ('create new connector files or replace existing ones'). It distinguishes itself from siblings by specifying it's the primary way to write connector code after first deploy and mentions the subsequent pipeline steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides when to use this tool ('after first deploy', 'write connector code') and the context of use (one file per call, defaults to dev branch). It also guides on what to do after writing (promote, build and run). It doesn't explicitly state when not to use, but the context implies it's for writing connector files specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses key behaviors: auto-routing to the right skill, multi-turn context maintenance via actor_id, and the wait/timeout mechanism. However, it does not cover potential side effects, auth requirements, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, efficiently front-loading the core purpose, then key feature (auto-route), and finally multi-turn detail. Every sentence adds value without redundancy.
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?
Given the parameter count and schema coverage, the description adequately explains usage patterns. It lacks details on return value format, which might be important for an agent, but no output schema exists to compensate. Still, it covers essential behavioral aspects.
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?
With 100% schema coverage, baseline is 3. The description adds value beyond the schema by explaining actor_id for conversation continuation, wait default, and timeout defaults/max detail, which are not fully evident from the schema descriptions alone.
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 clearly states the tool sends a message to a deployed solution and gets a result. It distinguishes from siblings by highlighting auto-routing without skill_id, making it unique among tools like ateam_test_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use: for sending messages to deployed solutions and multi-turn conversations. It explains how to continue a conversation via actor_id but does not explicitly state when not to use it or list alternatives, though the sibling list implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that scaffolding creates files, reduces boilerplate, and that files are uploaded to Core via the same path as ateam_upload_connector. It explains the effect of setting ui_capable=true. While it doesn't explicitly state that it modifies remote state or require prerequisites (e.g., solution existence), it provides sufficient behavioral context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three sentences that front-load the main purpose, then explain the benefit and optional capability. Every sentence adds unique value with no wasted words.
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?
Given the tool's moderate complexity (4 parameters, no output schema), the description covers core behavior, parameter semantics, and post-scaffolding outcome. It does not explain return values or error scenarios, but it is sufficient for an agent to understand the tool's operation.
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?
The schema covers all four parameters (100% coverage), but the description adds meaning: connector_id 'becomes the directory name', name 'defaults to connector_id', ui_capable 'include ui.listPlugins/ui.getPlugin handler stubs'. This enhances the schema descriptions without redundancy.
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 clearly identifies the tool's action ('Scaffold a new MCP connector') and the specific resources created (server.js, package.json, README). It distinguishes itself from sibling tools like ateam_create_plugin and ateam_upload_connector by referencing them in the context of plugin stubs and file upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (scaffolding new connectors), what it eliminates (50% boilerplate), and the developer's follow-up task ('fill in the tool implementations'). It also provides conditional guidance for ui_capable. However, it does not explicitly state when not to use it or compare to other tools beyond the mentioned siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It states a read operation ('Read') and describes the return (all files stored in mcp_store). While it doesn't detail error handling or permissions, the behavior is straightforward and non-destructive, so transparency is good but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first sets purpose and return, second gives usage guidance. Both sentences are valuable and concise, with no extraneous information. It is front-loaded with the core action.
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 simple read tool with two parameters and no output schema, the description covers the purpose, return content, and usage context. It could mention that it returns file contents or list of file names, but it gives examples ('server.js, package.json, etc.'). It is fairly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (solution_id and connector_id) with clear examples. The description does not add any additional semantics or usage details for the parameters beyond what the schema provides. With 100% schema coverage, baseline is 3.
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 clearly states the action ('Read') and the resource ('source code files of a deployed MCP connector'). It distinguishes from sibling tools by specifying that it reads current code before patching or rewriting, which differentiates it from write-oriented siblings like ateeam_patch and ateeam_create_connector.
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 description explicitly advises when to use this tool: '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.' This provides clear context and an exclusion (not for writing or modifying).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that using 'section' gives a much smaller output, but lacks details on side effects, auth requirements, or data freshness. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded, and no fluff. Every sentence earns its place, efficiently conveying purpose and usage.
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?
Given 3 parameters with enums and no output schema, description covers when, why, and how to use filters. Could mention output size but not critical. Very complete for a read-only spec retrieval tool.
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% and description adds context beyond schema, e.g., 'Start here after bootstrap' and explains how to use parameters to filter results. Adds marginal value over schema.
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?
Clearly states it gets the A-Team specification with specific contents (schemas, rules, guides). Distinguishes from sibling tools by mentioning alternatives like 'section' and 'search' for subset retrieval.
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?
Explicitly tells when to use ('Start here after bootstrap') and provides clear guidance on alternatives: using 'section' for a smaller subset and 'search' for targeted retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior, detailing that it 'returns phases, what to ask, what to build, exit criteria, and tips for each stage'. It implies a read-only operation with no destructive side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently state the purpose, when to use, and what is returned. No extraneous information.
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?
The description thoroughly explains the output fields (phases, questions, builds, criteria, tips) without an output schema, making the tool's behavior clear and complete for its scope.
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?
The tool has zero parameters, so schema coverage is trivial (100%). The description adds meaningful context about the returned data structure, going beyond what an empty schema conveys.
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 clearly states the tool retrieves 'builder workflows — step-by-step state machines', which is a specific resource distinct from sibling tools that handle individual solutions, specs, or connectors. The verb 'Get' and resource 'workflows' are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool to 'guide users through the entire build process conversationally', providing a clear context for use. However, it does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool reads commit history and supports a branch parameter, implying a read-only operation. It does not clarify permissions, rate limits, or side effects, but the verb 'View' strongly suggests non-destructive behavior. Good but not fully explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action. Every sentence conveys essential information without redundancy. Efficient and clear.
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?
Given no output schema, the description lists the return fields (messages, SHAs, timestamps, links) which is helpful. It covers purpose and parameter usage well. It could mention pagination or that it returns a list of commits, but overall is fairly complete for a simple log tool.
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% with parameter descriptions. The description adds value by explaining the default branch ('main' for prod) and how to use 'ref' to see dev work, which is not obvious from the schema alone. It also mentions limit implicitly but could elaborate.
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?
Clearly states 'View commit history' for a solution's GitHub repo, specifying the verb and resource. Lists what the tool shows (messages, SHAs, timestamps, links) and distinguishes itself from sibling tools like ateam_github_diff or ateam_github_patch by focusing on history/log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (view commit history) and provides a specific usage tip (pass ref:'dev' for in-progress work). However, does not explicitly state when not to use or mention alternatives, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Details pipeline steps (session, caller verification, prompt, skill dispatch, response) and return fields (bot response, verification, tool calls, entities). Mentions simulation via text, avoiding misconception of actual audio. Could note side effects? Probably none.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second expands on pipeline and output, third gives usage recommendation. No fluff, every sentence adds value. Front-loaded with key action.
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?
Given 5 parameters and no output schema, description covers pipeline steps, return data, and parameter effects. Lacks details on error handling or output format, but mentions key return items. Adequate for testing tool.
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%, but description adds value: clarifies messages simulates multi-turn, phone_number with example and auto-verification logic, timeout_ms default. This enriches understanding beyond schema definitions.
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?
Clearly states 'simulate a voice conversation with a deployed solution', specifies it runs full voice pipeline using text. Differentiates from sibling tools like ateam_conversation, ateam_test_pipeline, etc. by focusing on voice simulation end-to-end.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to test voice-enabled solutions end-to-end without making a phone call.' Implicitly suggests when to use (testing) vs. making real calls. Could more clearly contrast with text conversation testing or other test tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral effects: kills MCP process, unregisters from skill registry, deletes from Mongo, removes from solution arrays, deletes files from Builder FS. This fully informs the agent of the destructive nature and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: clear purpose, detailed effects, and closing usage guidance. No redundant words, and every sentence adds value.
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?
Given the number of sibling tools and the complexity of the operation, the description is complete. It explains what, how, and when to use, without needing an output schema for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no extra meaning beyond what the schema provides, meeting the baseline for high coverage.
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 clearly states 'Delete a single skill from a deployed solution,' specifying the verb and resource. It distinguishes from sibling delete tools like ateam_delete_connector and ateam_delete_solution by clarifying it targets a single skill within a solution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly provides usage context with 'Use this to drop a skill without tearing down the whole solution,' indicating when this tool is appropriate. However, it does not explicitly mention alternatives or cases where it should not be used, relative to other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits such as automatic redeployment, optional re-testing, and the ability to create default scaffolds for new skills. No annotations are present, so the description carries the full burden, and it meets the need by covering mutation side effects and supported operations.
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 well-structured with sections (supported operations, examples) and is front-loaded with the core purpose. While lengthy due to exhaustive examples, every part earns its place. It is concise given the complexity of the tool.
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?
Given the tool's complexity and lack of output schema, the description covers usage, parameters, special patterns, and behavioral notes (redeploy, test, creation). It leaves no obvious gaps for an agent to understand how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3, but the description adds significant value by explaining dot notation, array operations (_push/_delete/_update), special fields like _force_redeploy, and providing detailed examples. This greatly enhances understanding beyond the raw schema.
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 clearly states the tool's purpose: 'Surgically update ANY field in a skill or solution definition, redeploy, and optionally re-test — all in one step.' This provides a specific verb, resource, and scope, distinguishing it from sibling tools like ateam_get_solution (read-only) or ateam_delete_skill (destructive).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use target='skill' vs target='solution', and includes numerous examples covering common update patterns. It also clarifies that the tool can create new skills if they don't exist. However, it does not explicitly state when not to use this tool (e.g., for simple reads).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It fully discloses what is included (name, description, style, routing_mode, identity_mode, skill ids, connector ids) and what is skipped (deployed metadata, handoffs, grants, ui_plugins, validation results). This provides complete behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose. Every word adds value, no fluff. Efficient and clear.
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 simple tool with one parameter and no output schema, the description is complete: it explains what the tool returns and what it skips, covering all necessary context for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add parameter-specific meaning beyond the schema's 'The solution ID', which is adequate but not enhanced.
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?
Description clearly states the tool shows the minimal authoring view of a solution, listing exactly which fields are included and excluded. It distinguishes itself from sibling tools by emphasizing minimal vs verbose, and explicitly mentions the stripped fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description says 'Use this for fast inspection without the verbose fields', providing clear context for when to use. However, it does not explicitly contrast with sibling tools like ateam_get_solution or ateam_show_skill_minimal, though the minimal vs verbose distinction is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes authentication requirement and return format (summary table). As a read-only operation with no annotations, this provides sufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences covering purpose, auth, and output—every sentence adds value without redundancy.
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?
Complete for a zero-parameter tool: covers scope, auth, and return type. No output schema needed given the description.
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?
No parameters exist, so schema coverage is 100%. Baseline 4 applies; description adds no extra param info since none needed.
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?
Clearly states the tool shows GitHub sync status for ALL tenants and solutions, distinguishing from specific status tools like ateam_github_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires master key authentication, providing clear context. Implicitly differentiates from sibling tools by emphasizing 'ALL', but no direct when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that this is a polling operation, returns specific data, and is marked as 'Advanced'. It doesn't detail error handling or rate limits, but for a polling tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first defines purpose and output, second gives usage guidance. No wasted words.
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?
Despite no output schema, description enumerates return fields well. Parameters are fully covered by schema. Usage guidance is included. Complete for a simple polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds no extra parameter semantics beyond what schema already provides, so baseline score.
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 clearly states it polls progress of an async skill test, listing return values (iteration count, steps, status, result). It distinguishes from sibling ateam_test_skill by positioning itself as the async polling counterpart.
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?
Explicitly tells when to use (polling async test) and when not (use ateam_test_skill with wait=true for synchronous), providing a direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It transparently states that it compares head vs base, returns ahead_by, and shows commits and files. It does not mention destructive behavior, which is appropriate. Could be improved by explicitly stating it's read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The opening sentence provides the label and defaults; then bullet points explain when to use. Every sentence adds value with no redundancy.
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?
Given the tool's moderate complexity and lack of output schema, the description covers purpose, parameters, and usage scenarios adequately. It mentions that it shows commits and files, which is sufficient for understanding the output. Minor improvement could be adding output format details.
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 baseline is 3. The description adds meaning by explaining defaults for base and head, and clarifying the direction of comparison (base is target, head is source). This goes beyond the schema.
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 clearly states it's a pre-flight check before promote, comparing dev vs main by default, and shows commits and files. It distinguishes itself from sibling tools like ateam_github_promote.
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 description explicitly provides three use cases: review changes before promoting, check if dev is ahead of main, and inspect arbitrary comparisons. It implicitly indicates when not to use (the actual promote is for ateam_github_promote).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It clearly states it is a write operation that commits changes, describes two modes with their effects, and warns about the default branch (dev). The description could mention potential overwrite risks or undo capabilities, but overall is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections. It front-loads the purpose and mode distinction, uses efficient language without redundancy.
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?
Given the tool's complexity (7 params, two modes, no output schema), the description covers usage context, prerequisites (read file first), branch strategy, and emergency handling. It lacks details on commit behavior (e.g., response format) but is sufficiently complete for an effective AI agent.
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%, baseline 3. The description adds significant value by explaining the two modes (how content, search, replace interact) and providing default context for ref. This goes beyond the schema's basic type descriptions.
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 clearly states it edits a file in the GitHub repo and commits, distinguishing two modes (full file replacement vs search/replace). This sets it apart from siblings like ateam_github_read (read-only) and ateam_github_write (presumably a different write operation).
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?
Provides explicit guidance: use full file for new/small files, search/replace for large files (>5KB), always read the file first, and defaults to dev branch. It also advises using ateam_github_promote for normal dev→main and only ref:'main' for emergencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully discloses additive behavior, no history destruction, new commit creation, and the ability to roll back the rollback.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with a one-line purpose followed by bullet points on behavior and workflow. Every sentence adds value with no redundancy.
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?
Covers behavior, workflow, and parameter guidance well. Lacks description of return value (e.g., commit ID or status), but overall complete given no output schema.
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%, baseline 3. The description adds value by explaining 'target' as a tag or SHA and referencing list_versions, but 'solution_id' remains basic.
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 clearly states 'Roll prod (main branch) back to a previous state' with a specific verb-resource pair. It distinguishes from sibling tools by emphasizing the additive, history-preserving nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear workflow (list_versions → rollback → build_and_run) and explains when to use (revert to safe tags). Lacks explicit when-not or alternative tools, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It explains that env vars are not sufficient, that global endpoints work without auth, and the distinction between api_key and master_key with tenant requirements. It lacks details on error handling or response format, but covers essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: first states purpose, second adds usage nuance, third addresses exceptions. No wasted words.
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 an auth tool, the description covers purpose, prerequisites, parameter usage, and special cases. It is complete given the complexity and absence of output schema.
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%, but the description adds value by explaining the context for parameter usage: must call explicitly despite env vars, master_key for cross-tenant, tenant requirement with master_key. This clarifies meaning beyond the schema.
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 clearly states 'Authenticate with A-Team' and specifies it is required before any tenant-aware operation. It distinguishes from sibling tools by noting which operations (global endpoints) do not require auth, providing strong purpose clarity.
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 description explicitly states when to use (before tenant-aware operations) and when not to use (global endpoints). It also addresses the nuance that environment variables alone are insufficient and that master_key is an alternative for cross-tenant operations, offering comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It warns this is a 'HEAVY OPERATION', details the steps (regenerates MCP servers, pushes to Core, restarts connectors, verifies discovery), and gives time estimate of 30-120s.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured paragraph that front-loads the core purpose, then provides warnings, process details, timing, and usage guidance. Every sentence adds necessary information without redundancy.
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?
Given the tool's complexity and absence of output schema, the description covers all necessary aspects: purpose, behavior, side effects, timing, and appropriate use cases. The verification step is also mentioned, making it complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond what the schema already provides for both parameters. The schema clearly explains solution_id and skill_id, and the description only repeats that info.
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 clearly states the tool's action ('Re-deploy skills WITHOUT changing any definitions') and explains the detailed process. It distinguishes itself from sibling tool ateam_patch, which updates and redeploys in one step.
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?
Explicitly states when to use: 'Use after connector restarts, Core hiccups, or stale state' and when not to: 'For incremental changes, prefer ateam_patch'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Though no annotations are provided, the description fully details behavior: read-only, returns ok and drifts array, explains drift causes (network blip, container restart) and that boot sync heals it later. This provides comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for return values, front-loaded with the core purpose, and every sentence adds value. No unnecessary content.
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?
Given no output schema, the description adequately explains the return format (ok: true/false, drifts list) and provides context about drift causes and relationship to other tools. Completeness is high for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (solution_id). The description does not add extra semantic meaning beyond the schema, so a baseline of 3 is appropriate.
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 clearly states the tool checks consistency between Builder filesystem and GitHub for a solution, distinguishing it from sibling tools like ateam_github_diff or ateam_github_status. It specifies it is a read-only probe that does not trigger a deploy.
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?
Explicit guidance on when to use: 'Run after a series of ateam_github_patch calls to confirm the Builder backend is consistent with GitHub before you ateam_build_and_run.' Also notes it is read-only and does not trigger deploy, clarifying when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns explanations and instructions, implying it is a read-only information tool. It does not explicitly confirm no side effects, but the description content strongly suggests non-mutating behavior. A score of 4 reflects minor omission of explicit safety guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only essential information: mandatory nature, trigger conditions, return value, and a clear directive. Every sentence adds value without redundancy.
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?
Given the zero-parameter input schema and absence of output schema, the description is complete. It tells the agent when to call, what to expect, and how to behave. No additional information is required for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is fully described. No additional parameter documentation is needed. The description perfectly handles this case.
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 clearly states that ateam_bootstrap is the required onboarding entrypoint, specifies the exact scenarios when it must be called (user greets, asks for help, first connection, etc.), and explains what it returns (platform explanation, examples, behavior instructions). This differentiates it from all sibling tools, which focus on specific actions like auth, building, or testing.
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 description provides explicit usage guidance: it is mandatory for onboarding scenarios and explicitly warns not to improvise an introduction. It lists multiple trigger conditions (greeting, question about capabilities, etc.), making it clear when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the heaviest operation duration (60-180s), validation, deployment to Core, health checks, optional warm test, auto-push to GitHub, and authentication requirement. No contradictions.
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?
Description is somewhat long but well-structured with emojis, bullet points, and clear sections. Front-loaded with key purpose and warnings. Some repetition could be trimmed, but every sentence adds value.
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?
Covers all aspects: workflow, parameter usage (first deploy vs subsequent), auto-detection, alternatives (ateam_patch), prerequisites (authentication), and outcome (deployment + GitHub push). No output schema, but return behavior is implied through test_message. Complete for a complex deployment tool.
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 baseline is 3. Description adds significant value: explains auto-detection of repo, first deploy vs subsequent behavior, and clarifies that parameters like solution, skills, connectors, and mcp_store are optional after first deploy. This contextual information enhances understanding beyond the schema.
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 clearly states the purpose: 'DEPLOY THE CURRENT MAIN BRANCH TO A-TEAM CORE.' It distinguishes from siblings like ateam_github_patch, ateam_github_promote, and ateam_patch, specifying that this is for deploying the main branch after promotion.
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?
Provides a detailed DEV/PROD workflow (steps 1-4) and explicit guidance: 'This tool ALWAYS deploys the `main` branch' and 'To deploy in-progress dev work, first promote it.' Also advises preferring ateam_patch for small changes, making when-to-use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It comprehensively discloses behavior: real notification, auth forwarding, tenant pinning, safety features ([TEST] prefix, rate limit 10/min, auditing), and limitations (reply_handler not supported).
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 moderately long but well-structured with sections (purpose, comparison, use cases, auth, safety). It front-loads the key purpose and differentiators. While efficient, some detail (e.g., the reply_handler explanation) could be condensed.
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?
Given the tool has 6 parameters, no output schema, and no annotations, the description covers all crucial aspects: purpose, when to use, safety, behavioral details, and parameter context. It explains the response includes per-channel ok/failed, which is sufficient for an end-to-end testing tool.
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 baseline is 3. The description adds value beyond the schema by explaining that content is prefixed with [TEST], actor_id is scoped to tenant, and metadata is for correlation IDs. This extra context improves parameter understanding.
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 clearly states the tool's specific purpose: 'Fire a REAL notification at an existing actor in a deployed solution — for end-to-end testing'. It uses specific verbs and resources and distinguishes itself from siblings by explicitly comparing to ateam_test_skill and ateam_conversation.
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 description provides explicit guidance on when to use the tool (channel fan-out smoke testing, delivery-result verification) and when not to (for routing/engagement tests, use ateam_test_skill). It also includes context about auth and tenant scoping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses merging behavior, auto-tag format (safe-YYYY-MM-DD-NNN), dry_run behavior (shows diff without merging), and conflict response (409). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and tag format. Workflow order is given. Details on dry_run and merge conflict are concise. No redundant sentences.
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?
No output schema, but description explains return behavior (diff on dry_run, 409 on conflict). Covers auto-tag naming, workflow, and conflict resolution. Complete for a promote/merge tool.
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% with descriptions for each parameter. The description adds behavioral context beyond schema: dry_run returns diff, skip_tag skips tagging, and merge conflict returns 409. However, schema already provides basic descriptions, so not a 5.
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 clearly states 'SHIP DEV TO PROD. Merges the `dev` branch into `main` and auto-tags...', using a specific verb and resource. It distinguishes this tool from siblings like ateam_github_patch (writes to dev) and ateam_build_and_run (deploys main) by outlining the workflow order.
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?
Explicitly states when to use: 'Use after testing your dev work, when you're ready to deploy changes to production.' Provides a workflow with sibling tools and mentions dry_run to preview. Also notes merge conflict handling and manual resolution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ateam-mcp MCP server](https://glama.ai/mcp/servers/ariekogan/ateam-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ariekogan/ateam-mcp)

Score Badge

Copy to your README.md:

[![ateam-mcp MCP server](https://glama.ai/mcp/servers/ariekogan/ateam-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ariekogan/ateam-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ariekogan/ateam-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server