aacworkflow-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools follow a clear CRUD pattern per resource (squad, agent, issue, project, label, skill, autopilot). A few potential overlaps exist (create_agent vs create_agent_from_template, list_members vs list_squad_members) but descriptions clarify them.
Naming Consistency4/5
The vast majority use verb_noun snake_case (create_squad, delete_issue). Minor exceptions like whoami and dashboard_* prefix are acceptable, and the pattern is predictable.
Tool Count1/5
69 tools is far beyond the typical range and even the relaxed threshold of 25+. While the server covers many domains, the sheer size makes it unwieldy for an agent to navigate and would benefit from modularization.
Completeness4/5
The toolset provides full CRUD for most resources and adds workflows (assign, rerun, comment, subscribe, attach). Missing administrative operations like create/delete workspace or runtime are likely out of scope, so coverage is strong.
Average 2.9/5 across 69 of 69 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 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.
Add a glama.json file to provide metadata about your server.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, and the description provides no behavioral disclosure. It does not state whether the operation is read-only, how data is scoped or aggregated, or what side effects (if any) exist. The one-line noun phrase adds no actionable 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but brevity here stems from under-specification rather than efficient conciseness. It is a fragment that omits essential operational meaning and provides no structured information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description carries full responsibility for explaining tool behavior. It fails to define what 'runtime totals' includes, how the data is computed, what the response format is, or how workspace scoping works. The description is insufficient for an agent to use the tool confidently.
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 fully documents the only parameter workspace_id with 100% coverage, so the baseline is 3. The description adds no further meaning to the parameter, but the schema already explains the semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Agent run-time totals' is a noun phrase that essentially restates the tool name. It lacks a verb specifying the operation (e.g., get, list, fetch) and does not indicate whether this is a read, query, or summary action. It also fails to distinguish this tool from sibling dashboard and runtime tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 dashboard_usage_daily, dashboard_usage_by_agent, or get_runtime_usage. The description offers no context for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates the action and gives no insight into patch semantics, required permissions, error handling, or 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concisely informative. It is a single clause with no structure or extra context, which is insufficient for a tool with a complex patch parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the patch-based complexity, no output schema, and no annotations, the description is severely incomplete. It fails to cover return values, error outcomes, or the update process itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 33% description coverage, and the description adds no parameter details. The 'patch' and 'id' parameters are critically undocumented, leaving the free-form patch object without any semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an autopilot' is essentially a tautology of the tool name. It adds no detail about what fields or behaviors can be updated and does not distinguish it from sibling tools like update_squad or update_agent.
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 usage guidance is provided. The description does not indicate when to use this tool versus create_autopilot, trigger_autopilot, or other update tools, nor any prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects, permissions, reversibility, or any other behavioral traits. 'Update a skill.' reveals nothing about what happens during the update, whether it is idempotent, what the response looks like, or if certain fields are required. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is severely under-specified rather than concisely informative. It fails to provide essential context, and the brevity is not a positive trait because it omits critical information about parameters and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested object parameter (patch) and no output schema, yet the description gives zero guidance on how to use it. There are no annotations to provide safety or mutation context. Overall, the description is completely inadequate for a tool with this complexity and no structured safety net.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only 33% of parameters with descriptions (only workspace_id has a description). The description does not compensate by explaining the 'id' or 'patch' parameters, nor does it clarify the structure of the dynamic patch object. The agent has no additional meaning beyond the bare schema types, making it impossible to construct a valid request correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a skill.' directly restates the tool name without adding any new information about scope or specific behavior. It is essentially a tautology of the tool name, providing no detail about what 'update' entails or what distinguishes this from other update tools.
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?
The description gives no guidance on when to use this tool versus alternatives such as create_skill, delete_skill, or import_skill. There is no context about prerequisites, typical use cases, or exclusions, leaving the agent without any decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description 'Create a squad.' discloses no behavioral traits such as permissions, side effects, idempotency, or error conditions. The agent has no information about what happens on creation or any constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified rather than concise. It provides no useful information beyond the tool name, and the brevity hinders comprehension rather than helping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a CRUD creation tool with 4 parameters, no annotations, and no output schema. The description 'Create a squad.' is inadequate to fully convey tool behavior, required inputs, or expected outcomes, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (two of four parameters have descriptions). The tool description adds no meaning beyond the input schema, and it fails to clarify the purpose or constraints of the 'name' and 'description' parameters. The description does not compensate for the lack of full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a squad.' is a direct restatement of the tool name, providing no additional context or detail. It is tautological rather than informative, offering no clarification of what a squad is or any distinguishing features beyond the verb 'create'.
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 usage guidance is provided. The description does not mention when to use create_squad versus update_squad, list_squads, or other sibling tools, nor any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits. It does not indicate whether this is a read-only query, whether it returns aggregated metrics, or any pagination or filtering behavior. The burden falls entirely on the description, which fails to address it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At four words, the description is extremely short, but this is under-specification rather than conciseness. It lacks structural framing or context that would help the agent understand the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description is the only source of behavioral information. It fails to explain what 'usage' means, what data is returned, or how to interpret the output, making it completely inadequate for an agent to correctly select and invoke the 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?
The schema description fully documents the single optional parameter workspace_id, so the baseline is 3. The tool description adds no additional semantic value about how the parameter affects the results, but it is not required given the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Usage by agent.' simply restates the tool name without specifying an action verb or clarifying what 'usage' means. It does not distinguish this from sibling tools like dashboard_usage_daily or dashboard_agent_runtime, which also relate to usage metrics.
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?
There is no guidance on when to use this tool versus alternatives. The description provides no context about the intended use case, filter scope, or relationship to other dashboard tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that this is a mutation, partial update behavior, permissions, side effects, or default workspace handling. The word 'Update' implies mutation but offers no safety or side-effect info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient, but it is under-specified. It is not overly verbose, but it lacks structural detail that would help an agent understand the tool's capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (free-form patch object, no output schema, no annotations), the one-line description is severely deficient. It provides no information about return values, update semantics, required fields, or any behavioral context, making it nearly useless for an agent to predict outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no explanation for the parameters. The input schema itself only documents workspace_id; the required 'patch' object is free-form with no description, and 'id' lacks documentation. The description does not compensate for the low schema coverage (33%), leaving the patch contents and id semantics completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the target resource ('a squad'), which distinguishes it from create/delete/list siblings. However, it does not specify what properties can be updated, making it slightly generic but still unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only states the action without any context about how it fits into the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits like mutability, idempotency, or side effects. 'Update an agent' reveals nothing beyond the operation name, failing to indicate whether it merges, overwrites, or has any destructive consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (three words), which is concise in length but lacks necessary substance. It does not earn its place because it adds no value beyond the tool name, making it under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with three parameters, no output schema, and no annotations, this description is severely incomplete. It provides no information on return values, required fields like patch, or behavior, making it inadequate for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds zero insight into the patch object or id field, which are undocumented in the schema except for the workspace_id description. Schema description coverage is only 33%, and the description does not compensate for the missing parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and names the resource ('agent'), clearly identifying what the tool does. While it doesn't specify which attributes can be updated, it is unambiguous and distinguishes from sibling tools like create_agent, get_agent, and archive_agent.
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?
There is no guidance on when to use this tool versus alternatives such as create_agent or archive_agent. The description omits any context about partial updates, prerequisites, or when this is the appropriate operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'update,' which is already implied by the tool name, and does not explain side effects, idempotency, permissions, or patch semantics. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three words and under-specifies the tool's behavior and parameters. This is not appropriate conciseness but rather a near-tautology that fails to earn its place beyond restating the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a complex patch object, no output schema, and no annotations, the description is extremely incomplete. It provides no information about expected response, how patch is applied, or any constraints on updates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only workspace_id has a description). The description does not add any meaning about the required 'patch' object or 'id' parameter. For a tool with an arbitrary patch object, this lack of parameter guidance is a critical omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('Update') and the resource ('an issue label'), which distinguishes it from sibling tools like create_label, delete_label, and update_issue. However, it is a minimal restatement of the tool name with no added context about what aspects of a label can be updated.
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 regarding when to use this tool versus create_label, delete_label, or list_labels. The description does not mention any prerequisites, alternatives, or context for updating an issue label.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but it only names the resource. It does not state whether the operation is read-only, what data is returned, whether it is aggregated, or any operational constraints—critical gaps for an agent deciding to invoke it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single fragment, not a structured sentence. While it is short, it is under-specified rather than concise, offering too little information to be useful for an agent.
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?
Even for a simple tool with one optional parameter, the description is incomplete. It does not clarify the time granularity ('daily'), what credits/tokens refer to, or how it relates to sibling dashboard tools, leaving significant gaps for the agent to infer.
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 fully documents the single optional workspace_id parameter with a description, so the schema coverage is 100%. The tool description adds no parameter-specific semantics, but the baseline of 3 is appropriate since structured data already handles parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Daily credit/token usage' is a noun phrase rather than a verb+resource construction, making it somewhat vague about whether the tool retrieves, lists, or summarizes data. It conveys the subject but does not clearly distinguish it from sibling tools like dashboard_usage_by_agent or dashboard_agent_runtime.
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. The description simply states a topic and offers no context about typical use cases, prerequisites, or situations to avoid, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Update a project.' and fails to disclose that this is a partial patch operation, whether the update is idempotent, what happens to unmentioned fields, required permissions, or the return value. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence and front-loaded, with no wasted words. However, it is under-specified for a tool with an arbitrary patch object; while not bloated, it is not appropriately sized to convey necessary context. It is acceptable but lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has a nested object parameter (patch), no output schema, and no annotations. The description is extremely incomplete: it does not explain the patch structure, the role of workspace_id, the return value, or any side effects. Given the moderate complexity and missing structured metadata, the description fails to provide a usable level of context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes workspace_id but leaves id and patch undocumented, and the description adds no parameter information. With schema coverage at only 33%, the description needed to explain the 'patch' object semantics (e.g., partial update, allowed fields) but does not. The description provides zero value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a project.' clearly states the verb and resource, identifying it as a mutation tool for projects. It distinguishes from sibling tools like update_agent or update_issue by naming the resource, but it lacks any additional specificity about what aspects of a project can be updated.
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?
There is no guidance on when to use this tool versus alternatives, such as create_project or delete_project, or when to use workspace_id. No prerequisites, exclusions, or context are provided. The tool name implies modifying an existing project, but the description offers no explicit usage direction.
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, the description carries the full burden. It only says 'Create a skill,' which adds no behavioral disclosure beyond the verb itself. It does not mention permissions, reversibility, side effects, or what happens to existing skills.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified and essentially repeats the tool name. Conciseness should not sacrifice necessary information; this is too brief to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain what a skill is, what content vs. description means, how workspace_id affects creation, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only workspace_id is described). The description 'Create a skill' adds no meaning to the parameters name, content, or description, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Create a skill'), which clearly states the action. However, it does not distinguish from the sibling tool 'import_skill', which also creates a skill, so it lacks sibling differentiation.
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?
There is no guidance on when to use this tool versus alternatives like import_skill or update_skill. The description provides no context or exclusions.
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, the description carries the full burden of disclosing behavior. It only says 'Update an issue,' implying a mutation, but does not state what happens if the issue does not exist, how the patch is applied (merge vs replace), or any side effects or error conditions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The sentence is short but not appropriately sized for the tool's complexity. It is under-specification rather than concise; it omits necessary information about parameters and behavior, so it fails to earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a complex patch parameter, no annotations, no output schema, and many related issue tools, a one-line description is grossly incomplete. It does not explain the expected input format, the meaning of an 'issue,' or the outcome of the update, making it inadequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters with only 33% coverage, and the description does not explain any of them. It does not clarify what 'id' refers to, what structure 'patch' should have, or when to use 'workspace_id.' The patch object is particularly opaque with no guidance on its keys or values, so the description adds zero value for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an issue' clearly identifies the action (update) and the resource (issue), which distinguishes it from sibling tools like create_issue, delete_issue, and get_issue. However, it is minimal and does not specify what fields or aspects can be updated, so it falls short of a 5.
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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison with related tools like patch vs create_issue. This is essentially no guidance beyond the inherent meaning of 'update'.
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 carries the full burden of behavioral disclosure. It only states the action without mentioning return values, side effects, authentication needs, error conditions, or idempotency, which is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is compact but redundant with the tool name, offering no additional value. It is under-specified rather than usefully concise, as it simply restates the action.
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?
For a creation tool with sparse schema and no annotations, the description is inadequate. It omits return value, required fields, and behavioral expectations, making it insufficient for reliable invocation despite the tool's apparent simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only workspace_id has a description), and the tool description adds no parameter meaning. It does not explain title, description, or how workspace_id affects creation, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a project' clearly states the action (create) and the resource (project), making it easy to distinguish from siblings like update_project and delete_project. However, it provides no additional context about project-specific scope or fields, so it is a minimal but clear statement.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or relationships to list_projects, update_project, or delete_project, leaving the agent without contextual cues for selection.
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 are provided, and the description only states that this is an activity log. It does not disclose response format, pagination, authentication, or any side effects. For a read operation, the minimal phrasing gives the agent no behavioral context beyond the tool name.
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?
A single concise phrase, front-loaded with the key concept 'Activity log'. It has no redundant words, but it is also under-specified; however, conciseness itself is high.
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?
Given no output schema, no annotations, and a minimal description, the tool's behavior is under-specified. The description is too thin to fully prepare an agent for invoking it correctly, especially with sibling tools that might overlap in functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes workspace_id but not the required 'id' parameter. The description's 'one runtime' implies that 'id' identifies the runtime, but it does not explain the format or how workspace_id interacts. With 50% schema coverage, the description provides only marginal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Activity log for one runtime' clarifies the scope (single runtime) and the data type (activity log), but lacks an explicit verb and does not distinguish it from the similar get_runtime_usage tool. It is more than a tautology but not fully explicit.
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?
The description provides no guidance on when to use this tool versus alternatives like get_runtime_usage or list_runtimes. No exclusions or prerequisites are mentioned, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the action without mentioning effects on the squad, required permissions, or failure scenarios. No information on reversibility or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it sacrifices necessary detail. It is not verbose, but it is under-specified.
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?
For a tool with 3 parameters and no output schema, the description lacks details on success/error behavior, parameter meaning, and workspace context. It is not complete enough for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions only for workspace_id (33% coverage), and the description adds no explanation of what id or agent_id refer to. It does not compensate for the missing schema 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 uses a specific verb 'Remove' and clearly identifies the resource ('a member from a squad'), which distinguishes it from siblings like add_squad_member and list_squad_members.
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 remove_agent or delete_squad. The description gives no context or exclusions.
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 are provided, so the description carries the full burden. It only states the action without disclosing side effects, error behavior, idempotency, or requirements (e.g., what happens if the skill is already attached). This is insufficient for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It essentially restates the tool name in natural language without adding any useful detail, so it does not earn its place as a helpful description.
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?
For a tool with 3 parameters and no output schema, the description is incomplete. It does not explain what the return value is, how workspace_id behaves, or any potential errors. The lack of behavioral and parameter context makes it difficult for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (workspace_id is described, but id and skill_id are not). The description does not clarify that 'id' refers to the agent ID, and it adds no meaning beyond the parameter names. With low schema coverage, the description should compensate, but it fails to do so.
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 ('Attach') and the resources ('a skill to an agent'), using a specific verb and object pair. It naturally distinguishes from sibling tools like detach_skill_from_agent and list_agent_skills, making the tool's purpose unambiguous.
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?
There is no guidance on when to use this tool, prerequisites, or alternatives. The description does not mention that detach_skill_from_agent exists for the reverse operation, nor does it explain any context such as required permissions or state conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits on its own, but it fails to mention whether deletion is permanent, cascading, or permission-restricted. For a destructive operation, this lack of transparency is a serious safety gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, but this brevity sacrifices essential detail. It is not a well-structured, informative description; it is minimal and under-specified, balancing brevity against completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation with no output schema and no annotations, the description is grossly incomplete. An agent lacks information about side effects, reversibility, or prerequisites, making it unsafe to invoke autonomously.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters (workspace_id has a description), but the required 'id' parameter is not described, and the tool description adds no parameter meaning whatsoever. An agent cannot infer that 'id' refers to the project ID or what workspace_id does beyond the schema's minimal 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 action (delete) and the target resource (project), using a specific verb and noun that distinguish it from create_project, update_project, and delete operations on other entities like squads or issues.
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, nor any prerequisites, exclusions, or consequences such as whether deleting a project affects associated issues or members. The description simply says 'Delete a project.' with no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It provides no information about whether deletion is permanent, what happens to skills currently attached to agents, or any error conditions such as trying to delete a non-existent skill. This is a critical gap for a destructive 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?
The description is a single concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it immediately clear what the tool does. This level of brevity is appropriate for a simple delete operation.
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?
Given that there are no annotations, no output schema, and only partial parameter descriptions, this tool description is far too sparse. It does not explain the return value, irreversible nature of deletion, or side effects on linked entities like agents. An agent invoking this tool would lack critical context for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 50% coverage: the workspace_id parameter is described, but id has no description. The tool description 'Delete a skill.' does not help clarify what id refers to or its format. Since the description must compensate for the missing id documentation but does not, the parameter semantics are weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a skill.' clearly states the action (delete) and the resource (skill), which distinguishes it from other delete tools that target different entities like issues or projects. However, it is essentially a restatement of the tool name and adds no extra specificity beyond the resource name.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that deleting a skill differs from detaching a skill from an agent, nor any prerequisites such as ownership or permission. The usage context is entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden for behavioral disclosure. It only says 'Get one autopilot,' which adds no information beyond the tool name itself. It doesn't indicate whether this is a read-only operation, what happens if the autopilot is not found, or any error behavior.
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 sentence with no filler or redundancy. It is appropriately minimal and front-loaded, stating the core purpose in the fewest possible words.
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?
The tool is simple (2 params, no output schema), but the description is too sparse to be considered complete. It doesn't mention the return value, how to handle missing autopilots, or the role of the parameters. Given the lack of annotations and output schema, more context is needed for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 50% description coverage (workspace_id is described, id is not). The description adds no parameter-level insight, failing to explain that 'id' is the autopilot's unique identifier. Without this, an agent may not understand which ID to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get one autopilot' clearly states the operation (get) and the resource (autopilot), and 'one' distinguishes it from list_autopilots. However, it is very terse and doesn't explicitly mention that it fetches by ID, though that is implied by the schema.
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 like list_autopilots. It does not mention prerequisites, such as having an autopilot ID, or any exclusions. The usage context must be inferred entirely from the tool name and schema.
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 carries the full burden, but it only says 'resource consumption metrics' without disclosing what metrics are included, whether the operation is read-only, any required permissions, or if data is aggregated over time. This is a significant gap for a tool that may have different data granularity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is brief and front-loaded, but it lacks necessary elaboration, making it under-specified rather than efficiently concise. It could be improved with a second sentence on what metrics are returned or how they are presented.
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?
Given the absence of an output schema and annotations, the description should explain return values, units, or time ranges, but it only provides a vague phrase. The overall tool context is simple but still incomplete for an agent to know what to expect when invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes workspace_id but not id; the description says 'one runtime' which implies id is the runtime identifier, but adds no further meaning about formats, defaults, or relationships. With only 50% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool retrieves resource consumption metrics for a single runtime, and the name 'get_runtime_usage' reinforces this. It distinguishes from sibling tools like get_runtime_activity or dashboard_usage_* by focusing specifically on resource consumption for one runtime.
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?
There is no mention of when to use this tool versus alternatives like dashboard_usage_daily or get_runtime_activity. The description provides no context on typical scenarios, prerequisites, or exclusions.
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, the description carries the full burden of behavioral disclosure. It only says 'list', implying a read operation, but does not reveal whether authentication is required, pagination behavior, or scope limitations. It adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is under-specified, lacking the useful structure seen in top examples that might include alternative guidance or scope qualifiers.
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?
Given no output schema, no annotations, and a minimal description, the tool is not fully contextualized. It does not mention return format, whether members are full objects or IDs, or the meaning of the required id parameter. The tool is simple, but the description still leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers workspace_id but leaves id without a description, giving 50% coverage. The description does not compensate by explaining what id refers to or how the parameters interact. It merely says 'a squad's members', which weakly implies id is the squad identifier but adds no detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists a squad's members, using a specific verb and resource. It is distinct from sibling tools like add_squad_member/remove_squad_member, though it does not explicitly contrast with get_squad or list_squads.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where another tool might be more appropriate, such as get_squad if full squad details are needed.
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, the description carries the full burden of behavioral transparency. The phrase 'full-text' does hint that the search covers text content, but it omits any details about query syntax, pagination, filtering capabilities, or whether it is a read-only operation. The description adds minimal value beyond what the tool name suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and free of any wasted words, but it is under-specified. At only three words, it reads more like a label than a functional description. It is concise but does not earn its place by delivering necessary detail.
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?
The tool has only two parameters and no output schema, but the description still falls short. It does not explain what kind of 'issues' are searched (e.g., by scope), how search results are returned, or any limitations. Given the rich set of sibling issue-related tools (create_issue, update_issue, list_issues), the description provides insufficient context for an agent to understand its unique role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only workspace_id has a description). The description does not explain the 'q' parameter or clarify the role of workspace_id. While one might infer that 'q' is the search query, this is not explicit, and the description adds no additional parameter-level context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: 'full-text search issues.' This is a specific verb (search) and resource (issues), with 'full-text' adding a useful qualifier. However, it does not explicitly differentiate from sibling tools like 'list_issues' or 'get_issue,' so it doesn't fully distinguish its 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention whether it should be used instead of list_issues for keyword searches, nor does it note any limitations or prerequisites. The only hint is the word 'search,' but the usage context is entirely assumed.
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 are provided, so the description carries the full burden. It states a mutation ('add') but discloses nothing about return values, idempotency, permissions, or side effects. This is minimal beyond what the name implies.
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 with no fluff. However, it is under-specified rather than efficiently detailed, so it doesn't earn a 5 for structure.
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?
For a mutation tool with no annotations, no output schema, and low parameter coverage, the description fails to address return format, required context, or how this fits with sibling tools like list_comments. The complexity is low, but the lack of critical behavioral information makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only 33% of parameters (workspace_id has a description; id and body do not). The description does not explain 'id' (presumably issue ID) or 'body' (comment content), leaving these ambiguous. It adds no meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a comment to an issue' uses a specific verb ('add') and resource ('comment to an issue'), clearly distinguishing it from sibling tools like create_issue or list_comments. It is unambiguous but does not explicitly contrast with alternatives.
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, nor are prerequisites such as the existence of the issue or required authentication mentioned. The description merely states the action without context.
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 are provided, so the description carries the full burden of behavioral disclosure. It only states 'Create a task' and a dispatch scenario, without explaining side effects, prerequisites, default behaviors, or what happens on success. This is a significant gap for a create operation.
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 is front-loaded with the core purpose. It earns its place without fluff, though it could be improved with structured details about parameters for clarity.
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?
For a tool with 10 parameters, no output schema, and no annotations, this description is severely incomplete. It fails to indicate required vs optional fields, default values, expected return values, or any constraints, making it difficult for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20%, and the description adds clarity only for assignee_type and assignee_id by explaining that combining them with 'agent' dispatches to an agent. Other parameters like status, priority, project_id, description, and parent_issue_id are left unexplained, leaving the agent to guess their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a task' with a specific verb and resource. The second sentence about dispatching to an agent adds a particular use case but doesn't fully distinguish from sibling tools like assign_issue_to_agent. The name 'create_issue' itself is clear, so purpose is mostly unambiguous.
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?
The description provides one specific usage scenario: dispatch to an agent by setting assignee_type='agent' and assignee_id. However, it offers no guidance on when to use this tool versus alternatives such as assign_issue_to_agent, nor does it explain general issue creation use cases or exclusions.
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 the full burden. It only states 'Create an issue label' with no disclosure about side effects, required permissions, behavior on duplicate names, or color format. This is minimal behavioral context beyond the verb itself.
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 extremely short and free of verbosity. However, it is under-specified, so while it is concise, it sacrifices content for brevity.
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?
The tool has no annotations or output schema, and the description provides only the bare minimum. It does not explain important behaviors such as duplicate name handling, color format, workspace_id effect, or error cases. This is insufficient for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only workspace_id has a description). The description does not elaborate on the meaning or format of name, color, or workspace_id. It relies entirely on the schema, which is sparse for name and color.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and the resource ('an issue label'), making the tool's basic function evident. It does not differentiate from siblings like update_label or delete_label, but the create verb sets it apart.
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 for when to use this tool versus alternatives. There is no mention of prerequisites, when a label should be created, or how it relates to list_labels/update_label.
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 are provided, so the description must carry the full burden of behavioral disclosure. 'Delete an attachment' implies a destructive operation but does not state whether deletion is permanent, whether permissions are required, or whether related resources (e.g., issue association) are affected. This is a significant gap for a mutation tool.
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, brief sentence with no wasted words. It is efficiently front-loaded with the action verb, but its brevity comes at the cost of completeness, which is appropriate to penalize in other dimensions.
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?
For a deletion tool with two parameters and no output schema, the description is critically incomplete. It omits return values, error behavior, irreversibility, permission requirements, and any note about how attachment IDs are obtained. The tool is under-specified for an AI agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 50%, the `id` parameter is undocumented in the schema and the description does not compensate by explaining what `id` refers to. The description adds no parameter-level detail beyond the schema's sparse information, leaving ambiguity about required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('an attachment'), which distinguishes it from sibling tools like get_attachment and list_issue_attachments. However, it lacks context about what kind of attachment (e.g., issue attachment) or any scope, so it is not as specific as it could be.
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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or whether it is appropriate for a given attachment type. With sibling delete tools like delete_issue and delete_project, the lack of contextual exclusions or alternatives makes it hard to choose correctly.
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 bear full responsibility for disclosing behavioral traits. 'Delete' implies a destructive mutation, but the description does not mention permanence, side effects on issues, permissions required, or error conditions. This is a significant gap for a write operation.
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 is clear and front-loaded. It is not verbose and every word earns its place. However, it is so minimal that it misses opportunities to provide useful context, but structurally it is well-formed.
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?
For a delete operation with no annotations and no output schema, the description is inadequate. It does not explain what happens after deletion, whether the label must be detached from issues first, or any potential impact. This leaves an agent without enough context to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 parameters with 50% description coverage (workspace_id has a description; id does not). The tool description adds no parameter information beyond the implication that 'id' refers to the label to delete. It fails to clarify the id format or how workspace_id interacts with the deletion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an issue label' uses a specific verb ('Delete') and a resource ('issue label') to clearly identify the tool's action. It is unambiguous and distinct enough from sibling delete tools (e.g., delete_issue, delete_project) due to the unique resource type, though it does not explicitly differentiate itself.
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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or context. The description merely states the action without explaining situations where deletion is appropriate or how it relates to sibling tools like delete_issue or update_label.
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 carries full responsibility for behavioral disclosure. It only states the action without revealing return format, error behavior, authentication needs, or side effects. While 'get' implies a read-only operation, the lack of any additional context leaves significant gaps.
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 short sentence, making it highly concise and front-loaded with the essential message. It avoids unnecessary words, though it is perhaps under-specified for a tool with no annotations or output schema.
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?
There is no output schema, and the description does not mention what the returned details look like or how errors are handled. Given the presence of sibling tools like list_skills and attach_skill_to_agent, the description lacks contextual links that would help the agent understand the tool's role and expected outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers workspace_id with a description but leaves the required id undocumented. The description adds no parameter-level meaning, and with 50% schema coverage, it should compensate for at least the id parameter's semantics. It does not, so the agent must infer that 'id' refers to a skill identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get one skill's details' clearly states the verb 'get' and the resource 'skill', making the core function unambiguous. The singular form implicitly distinguishes it from list_skills, though it does not explicitly name alternatives, so it falls short of a top score.
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 list_skills, create_skill, or update_skill. There is no mention of context, exclusions, or prerequisites, leaving the agent without decision-support information.
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 are provided, so the description carries the full burden of behavioral disclosure. It only says 'list tasks', which implies a read operation but does not disclose any behavioral traits such as return format, filtering semantics, pagination, sorting, or whether it includes all historical tasks. It adds minimal value beyond the basic operation.
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 primary action. It is not verbose, but it is also minimal to the point of under-specification. Still, it earns a high score for efficiency.
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 annotations, no output schema, and only a terse description, the tool is incomplete for an agent to use correctly. It does not clarify what kind of tasks are returned, the meaning of the required 'id', or any behavioral details. Complexity is low, but the description still leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 parameters with 50% description coverage (only workspace_id is described). The description does not explain what 'id' refers to (presumably an agent ID) or how it relates to the task listing. It adds no meaning beyond the schema, leaving the required parameter under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tasks an agent has worked on, which is a specific verb+resource combination. However, it does not explicitly distinguish itself from sibling tools like list_issues or list_autopilot_runs, and 'tasks' is somewhat vague. Overall, it is clear enough for basic selection.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that it is agent-specific, nor does it direct users to other tools for different scenarios. The usage context is only implied by the name and the description.
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, the description carries the full burden of disclosing behavior. It only mentions 'update' without indicating whether it performs a partial patch, requires special permissions, or has side effects on running runtimes. Critical behavioral details are omitted.
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 with no filler. It is appropriately short for the core action, though it lacks structure or additional sections that could aid understanding without bloating the text.
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?
Given the lack of annotations and output schema, plus a nested patch object and three parameters, the description is far from complete. It provides no context on how to construct a valid request, what the patch object should contain, or what the response will be, making it inadequate for reliable tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (workspace_id), leaving id and patch undocumented. The description adds only the vague term 'configuration', which hints that patch modifies configuration but provides no details on parameter structure or allowed fields. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and the resource (a runtime's configuration). It distinguishes from sibling update tools by naming 'runtime', though it doesn't elaborate on what 'configuration' encompasses, preventing a perfect score.
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 given on when to use this tool versus alternatives, prerequisites, or how it relates to other runtime operations like list_runtimes. The single sentence provides no usage context.
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, the description must disclose behavioral traits, but it only states the action. It does not mention idempotency (what happens if the agent is already a member), permissions needed, or return value. This is insufficient for a mutation tool.
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, six-word sentence with zero wasted words. It is perfectly concise for its content, though the brevity sacrifices completeness in other dimensions.
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?
Given no annotations, no output schema, and low schema coverage, the description is far too sparse. It lacks context about behavior, prerequisites, and edge cases, making it inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds only the semantic roles 'agent' and 'squad', implying agent_id and id respectively, but does not explicitly map parameters. Schema coverage is only 33%, and the description does not compensate by explaining the required 'id' and 'agent_id' fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'add' and the resource 'agent to a squad', distinguishing it from sibling tools like 'remove_squad_member' and 'list_squad_members'. However, it does not explicitly map the 'id' parameter to the squad, leaving minor ambiguity.
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, nor any prerequisites such as the squad and agent existing. The description omits exclusions or conditions, making it a bare action statement.
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, the description carries the full burden, but it only states the creation action and visibility advice. It does not disclose side effects, permission requirements, reversibility, or any runtime-specific behavior, leaving the agent to infer these from the schema alone.
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, consisting of two short sentences. The primary action is front-loaded, and the visibility recommendation is a valuable addition. No filler or redundant phrasing exists.
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?
For a tool with 8 parameters, no output schema, and no annotations, the description is insufficiently detailed. It omits essential context such as return values, required fields beyond runtime_id, how model is selected, and any prerequisites. The single visibility hint is helpful but leaves major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (2 of 8 params have descriptions). The description adds guidance for the visibility parameter ('workspace' recommended), but provides no semantic context for name, model, instructions, max_concurrent_tasks, or workspace_id, which are otherwise undocumented. This does not sufficiently compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create an agent') and the target context ('on a runtime'), which is specific and actionable. However, it does not explicitly distinguish this from sibling tools like create_agent_from_template, though the 'on a runtime' qualifier provides some implicit differentiation.
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?
The description includes a best-practice directive ('Use visibility 'workspace' so all members can use it'), but gives no guidance on when to choose this tool over alternatives such as create_agent_from_template or update_agent. No exclusions or selection criteria are provided.
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 are provided, so the description carries full responsibility for disclosing behavioral traits. However, it omits crucial destructive-action details such as permanence, cascading effects on runs or history, and permission requirements. This is a significant transparency gap for a delete operation.
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 extremely concise with no wasted words. However, its brevity sacrifices useful context, making it less effective as a standalone guide. It is appropriately sized for a simple operation but lacks supporting structure.
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?
Given the tool's destructive nature, no annotations, and no output schema, the description is too incomplete. It fails to mention the outcome, irreversibility, or any prerequisites, leaving the agent with insufficient contextual information for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: the required 'id' parameter lacks a description, and the tool description adds no clarification. While 'workspace_id' is described in the schema, the description does not compensate for the undocumented 'id' parameter.
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 ('Delete') and resource ('autopilot'), clearly distinguishing it from sibling tools like create_autopilot, update_autopilot, and list_autopilots. It is unambiguous about the operation performed.
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?
The description offers no guidance on when to use this tool versus alternatives, nor any caveats (e.g., irreversibility, dependencies, or whether an active autopilot can be deleted). The intended use is only implied by the verb.
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 carries the full burden. 'Get full details' implies a read operation, but it does not explicitly confirm read-only behavior, error handling, response format, or any additional behavioral traits. Minimal disclosure beyond the tool's name.
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, direct sentence with no superfluous words. It is appropriately sized for a simple get-by-id tool and front-loads the core purpose clearly. Excellent conciseness.
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 low-complexity read tool, the description is minimally adequate. It conveys the action and resource, but lacks explicit mention of return value shape (no output schema), prerequisites, or edge cases. 'Full details' is vague and could benefit from examples or a note that all agent fields are returned. Overall, a basic but functional description with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (workspace_id is described, id is not). The description does not explain the meaning or usage of either parameter, nor does it compensate for the missing id description. The agent must rely solely on parameter names and the schema's partial description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get full details of one agent' clearly states the verb (get), resource (agent), and scope (one). It distinguishes from list_agents by implying singular access, though it doesn't explicitly name alternatives. This is clear but lacks explicit sibling differentiation.
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 like list_agents, or on prerequisites such as the agent existing. The description simply states what it does without context on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It merely states the action 'Re-run' without explaining side effects, whether it starts a new run, if it overwrites previous results, or any required permissions. This is insufficient for a mutating 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?
The description is a single, focused sentence with no wasted words. It conveys the core action clearly and is appropriately concise for a simple operation.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't mention prerequisites (e.g., an existing agent task), potential side effects, or expected behavior. For a side-effectful tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (workspace_id has a description, id does not). The tool description does not add any explanation for the 'id' parameter or clarify how it maps to an issue. It fails to compensate for the missing schema 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 uses a specific verb ('Re-run') and clearly identifies the resource ('an issue's agent task'). This distinguishes it from sibling tools like update_issue or assign_issue_to_agent, as it's the only rerun operation.
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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The context is only implied by the name and action.
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 carries the burden of explaining behavior, but it only says 'Manually trigger', implying user-initiated action without detailing side effects, idempotency, required permissions, or what constitutes a successful trigger. The transparency is minimal.
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, front-loaded sentence with no unnecessary words. However, it is extremely terse, bordering on under-specification, which slightly reduces its value despite being concise.
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?
For a tool with 2 parameters and no output schema or annotations, the description is insufficient. It does not explain what 'id' refers to, what the trigger does, or what the user should expect after invocation. The agent cannot confidently use this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (workspace_id has a description, id does not). The description adds no parameter meaning, leaving the required 'id' ambiguous—it could be an autopilot ID, a run ID, etc. The description does not compensate for the schema gap.
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 'Manually trigger an autopilot run' clearly states the verb (trigger) and resource (autopilot run), distinguishing it from sibling tools like list_autopilots, get_autopilot, create_autopilot, update_autopilot, and delete_autopilot. It is specific and unambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives, such as whether it should be used for immediate runs or if there is a scheduling mechanism. No prerequisites or exclusions are mentioned, leaving the agent to infer usage context.
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 carries the full burden. It discloses the core mutation (unsubscribing) but omits side effects such as idempotency, whether it only affects the current user, error conditions if not subscribed, or any permission requirements.
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 sentence, front-loaded with the verb and resource, and contains no unnecessary words. It is appropriately concise for a simple tool.
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?
The tool is simple, but the description lacks critical contextual information: no usage guidance, no behavioral details like idempotency, no expected return value, and no note about authentication or subscription requirements. It is not complete enough for an agent to invoke confidently.
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 50%: only workspace_id has a description. The description indirectly adds meaning for 'id' by indicating it refers to the issue, but it does not explicitly explain the parameter or its format. Some compensation exists, but it is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unsubscribe from an issue's notifications.' clearly states the action (unsubscribe) and resource (issue notifications), and is implicitly differentiated from the sibling tool subscribe_to_issue. However, it does not explicitly specify that it applies to the current user's subscription, leaving a small ambiguity.
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, no prerequisites (e.g., being subscribed), and no exclusions. It is simply a definition, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers no behavioral details beyond the basic listing action. It doesn't disclose whether it returns all squads, handles pagination, requires specific permissions, or what the response structure is. With no annotations provided, the description fails to carry the burden of 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?
The description is a single, front-loaded sentence that wastes no words. It immediately communicates the action and resource, with a parenthetical clarification. While minimal, it's highly concise.
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?
Given there is no output schema and no annotations, the description should provide more context about what is returned or any scoping rules. It does not explain that listing may depend on workspace context, nor does it describe the response format. This is insufficient for a tool with no structured metadata.
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 description does not mention the optional workspace_id parameter. However, the input schema includes a clear description for this parameter, so schema coverage is 100%. Thus, the description adds no additional meaning beyond the schema, but the baseline of 3 applies.
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 action ('List') and resource ('squads'), with a clarifying synonym ('teams'). This distinguishes it from related tools like list_squad_members and get_squad, which operate on different resources or granularities.
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 regarding when to use this tool versus alternatives such as get_squad or list_squad_members. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer usage from the name alone.
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, the description carries the full burden but only says 'create an agent'. It does not disclose side effects, permissions, return values, or any behavioral nuances beyond the basic action.
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?
A single, tightly worded sentence that is front-loaded with the core action. It is concise with no redundant information, though this brevity sacrifices detail elsewhere.
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?
The tool has 5 parameters and no output schema or annotations. The one-sentence description is insufficient to understand invocation requirements, return format, or how parameters interact, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description only maps the 'slug' parameter via 'template slug'. It fails to explain runtime_id, name, visibility, or workspace_id, leaving critical parameters undocumented.
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 (create an agent) and the unique source (template slug), distinguishing it from the sibling tool create_agent. It is specific and unambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives like create_agent. It does not mention prerequisites, exclusions, or give context for selecting this tool over others.
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 carries full responsibility for behavioral disclosure. It hints at behavior by saying the autopilot 'files an issue,' but does not explain side effects, activation requirements, scheduling semantics, or what happens when the autopilot triggers. This lacks important context for a tool that creates a background automation.
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 sentence that front-loads the tool's purpose. Every word contributes meaning, with no filler or redundant information.
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?
Given the tool has 8 parameters, no annotations, and no output schema, this one-line description is far from complete. It does not convey return values, prerequisite conditions, or parameter behaviors, leaving too much for the agent to infer. The description covers core purpose but omits critical operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38%, so the description must compensate by explaining key parameters. It fails to do so—none of the required fields (title, assignee_type, assignee_id, execution_mode) are explained beyond their names. The phrase 'files an issue for an agent' offers a vague hint about assignee_id but is insufficient for 8 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 creates an autopilot, defining it as a recurring/triggered automation that files an issue for an agent. This verb+resource+scope structure distinguishes it from sibling tools like create_issue or create_agent, making its unique purpose immediately apparent.
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 phrase 'recurring/triggered automation' implies this tool should be used when an issue needs to be generated on a schedule or in response to a trigger, rather than for one-off issue creation. However, it does not explicitly state when NOT to use it or mention alternatives like create_issue, leaving some room for misinterpretation.
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 carries the full burden for behavioral disclosure, but it only states the action without mentioning side effects, reversibility, permissions, or error conditions. There is no contradiction with annotations.
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-formed sentence that immediately conveys the core action. It is concise and front-loaded, with no wasted words.
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?
Given the tool has three parameters, no output schema, and no annotations, the description is too sparse to provide complete context. It does not explain the expected result, prerequisites, or implications of detaching a skill, leaving the agent with insufficient information for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (workspace_id is described, but id and skill_id are not). The tool description adds no parameter meaning, leaving ambiguity about which id refers to the agent and which to the skill. It fails to compensate for the low schema 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 the action with a specific verb ('detach') and resource ('skill from an agent'), making the tool's purpose unambiguous. It also distinguishes itself from the sibling tool 'attach_skill_to_agent' through the verb choice.
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. The description does not mention related operations like 'attach_skill_to_agent' or conditions under which detachment is appropriate.
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, the description carries the full burden of behavioral disclosure. It only states the action ('List attachments') without detailing return format, pagination, whether full attachment data or just metadata is returned, or any side effects. This is a minimal disclosure beyond the name itself.
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 concise sentence that is front-loaded and immediately conveys the core purpose. Every word is necessary, and there is no redundancy or irrelevant detail.
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?
There is no output schema, so the description should explain what the tool returns, but it does not. It also lacks information about pagination, ordering, filtering, or any special behaviors. For a simple list operation with minimal schema information, this is insufficient for an agent to fully understand the tool's behavior and expected response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (workspace_id has a description, but id does not). The description adds no parameter meaning beyond the schema, failing to clarify that 'id' refers to the issue ID or to explain any constraints on the parameters. It does not compensate for the undocumented required parameter.
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 'List attachments on an issue' uses a specific verb and resource, clearly distinguishing it from sibling tools like 'get_attachment' (single) and 'delete_attachment' (delete). It identifies the scope (attachments on an issue) and is easily differentiated from other list tools such as 'list_comments'.
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 like 'get_attachment' or 'delete_attachment'. There are no explicit usage contexts, prerequisites, or exclusions, leaving the agent to infer from the tool name alone.
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 disclose behavioral traits itself. It only says 'subscribe' without explaining side effects, whether it affects the current user, idempotency, or any prerequisites. This is a significant gap for a mutation action.
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, focused sentence with no redundant words. It front-loads the action and resource, making it easy to parse. For a simple tool, this is appropriately concise.
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?
The tool has no output schema, no annotations, and partial schema documentation. The description does not cover the user identity, workspace context, or expected result of the subscription. This leaves the agent with insufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not clarify the parameters. The schema covers 50% (workspace_id has a description), but 'id' lacks any documentation. The phrase 'an issue' hints that id is an issue identifier, but this is implicit and not compensated for in the 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 action ('subscribe') and the target ('an issue's notifications'). It distinguishes the tool from siblings like unsubscribe_from_issue and list_issue_subscribers, making its purpose unambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives (e.g., unsubscribe_from_issue or listing subscribers). The agent must infer usage solely from the tool name, which is insufficient for nuanced decisions.
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 are provided, so the description must disclose behavioral traits. It only states 'List runs of an autopilot' without confirming read-only status, return format, pagination, ordering, or permission requirements.
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?
A single, clear sentence that is front-loaded with the action and object. No filler words or redundant information.
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?
For a list operation with no output schema, the description is insufficiently detailed. It does not clarify whether all runs are returned, how runs are defined, or any limits/filters. Sibling context (like trigger_autopilot) implies runs are executions, but this is not stated.
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 50% (workspace_id only). The tool description adds no parameter context beyond the schema. The 'id' parameter is implied to be the autopilot ID by the tool name, but the description does not explicitly map it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'runs of an autopilot,' clearly distinguishing it from sibling tools like list_autopilots (which lists autopilots) and get_autopilot (which retrieves a single autopilot).
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?
The description provides no guidance on when to use this tool or how it compares to alternatives such as get_autopilot or trigger_autopilot. It is a bare statement of function without any context or exclusions.
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 carries the full burden of behavioral disclosure. It does not describe return format, pagination, ordering, or authentication requirements. The behavior is essentially a restatement of the tool name.
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 concise sentence with no wasted words. It is efficiently front-loaded and communicates the core action immediately.
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?
The tool has no output schema and no annotations, so the description should compensate by explaining return values or further context. It does not mention what data is returned, any pagination, or ordering, leaving the agent with incomplete information for a list 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 50%; workspace_id has a description, while id does not. The description's phrase 'on an issue' clarifies that id refers to an issue identifier, adding some meaning beyond the schema. However, it does not provide explicit field-level details.
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 comments on an issue, using a specific verb and resource. It is easily distinguished from sibling tools like comment_issue (which creates a comment) and list_issues (which lists issues).
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?
There is no guidance on when to use this tool versus alternatives. It does not mention any exclusions or provide context about use cases, leaving the agent to infer from the name alone.
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 exist, so description carries the full burden. It mentions the fields that can be updated but does not disclose mutation semantics such as partial vs. full update, permission requirements, idempotency, or error behavior. This is a minimal disclosure similar to a basic update tool.
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?
A single sentence that directly states the tool's purpose with no filler. It is front-loaded and every word earns its place.
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 annotations or output schema, the description remains incomplete for a mutation tool. It does not explain the patch semantics, what happens to unspecified fields, or what the response contains. The open-ended patch object needs more behavioral context to be fully reliable.
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 does not define any properties for the 'patch' object (0% schema coverage), so the description compensates by listing the updatable fields. However, it does not provide types or syntax for these fields, and the schema's additionalProperties allows any property, which somewhat conflicts with the implied limited field set.
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 (update) and resource (workspace) while listing specific mutable fields (name, description, context, issue prefix). This distinguishes it from sibling update_* tools targeting other resources.
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?
Provides no guidance on when to use this tool versus other update tools or related workspace operations. No prerequisites, exclusions, or alternative recommendations are given. The intended usage is only implied by the tool name and resource type.
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 are provided, so the description must fully disclose behavioral traits. It only states that the tool gets a squad with members, which implies a read operation but does not explicitly confirm it is read-only, nor does it mention error behavior, permissions, or response format. The phrase 'with its members' hints at nesting but is vague.
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, direct sentence with no redundant words. It is front-loaded and effectively communicates the core function. This is appropriate conciseness, not under-specification (which is covered elsewhere).
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?
The tool has no output schema and no annotations, so the description bears the responsibility for explaining return values and edge cases. It only states that members are included, not the structure of the response or any error conditions. The optional workspace_id behavior is only partially covered by the schema, and the description does not compensate for the missing return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: workspace_id has a description, but id does not. The tool description does not explain the 'id' parameter or how it relates to the squad, nor does it clarify the optional workspace_id. It adds no meaning beyond the schema, leaving the required parameter undocumented in the 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 'Get one squad with its members' uses a specific verb ('get'), identifies the resource ('squad'), and clarifies that members are included. This clearly distinguishes it from sibling tools like list_squad_members (which only lists members) and list_squads (which lists squads without necessarily including members).
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 usage (fetching a single squad with its members) but does not explicitly state when to use this tool over alternatives like list_squad_members or list_squads. No exclusions or alternative recommendations are provided, leaving the context to be inferred from the tool name and description.
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 available, the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, how pagination or filtering works, or what happens when workspace_id is omitted beyond the schema's note. The description is minimal and does not reveal potential limitations or 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 a single, front-loaded sentence that is immediately understandable. It contains no filler or redundancy, efficiently conveying the core purpose.
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?
This is a simple list tool with one optional parameter and no output schema, but the description does not mention the return shape or any behavioral nuances like default workspace resolution. While the core functionality is clear, the lack of return structure and additional context makes it only minimally 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 already provides a clear description for the single optional parameter workspace_id, covering 100% of parameters. The tool description adds no additional semantic value beyond the schema, so this is at the baseline of 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 uses a specific verb ('List') and resource ('agents') with a clear workspace scope, distinguishing it from sibling tools like list_squads or list_autopilots. The sentence is unambiguous about what the tool does.
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 get_agent, list_agent_templates, or list_autopilots. The description implies it is for listing all agents in a workspace, but it does not state exclusions or preferred contexts.
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 are provided, so the description carries the full burden. It only states the purpose and gives no additional behavioral context such as read-only nature, required permissions, pagination, or output format. 'List' implies a safe read, but the description adds no extra 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?
A single concise sentence that is front-loaded with the verb and resource. Every word earns its place, with no filler or repetition.
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 simple list tool, the description is minimally viable: it states what is listed and the agent association. However, with no annotations and no output schema, it lacks details about return shape, pagination, or error conditions, leaving some gap for a fully informed agent.
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 documents only workspace_id, and the description does not explicitly state that 'id' refers to the agent ID. However, the phrase 'attached to an agent' implies the id identifies an agent, adding some meaning beyond the bare schema. With 50% coverage, the description partially compensates but leaves ambiguity.
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 a clear resource: 'skills attached to an agent'. This clearly distinguishes it from the sibling tool 'list_skills', which likely lists all skills globally.
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?
The description provides no guidance on when to use this tool versus alternatives like 'list_skills' or when combined with 'attach_skill_to_agent'/'detach_skill_from_agent'. It lacks any exclusions or context about selecting this over other list tools.
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 carries the full burden for behavioral disclosure. It does not explicitly state that this is a read-only operation, nor does it describe pagination, default behavior when no filters are applied, or any side effects. The description only states that it lists issues and filters, offering little beyond the obvious.
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 concise sentence that front-loads the purpose and then lists filter options. There is no wasted wording or redundant information. It is appropriately sized for a simple listing tool.
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 there is no output schema, the description does not mention what is returned (e.g., list of issue objects) or any response details. It also does not clarify behavior with no filters or mixed filter usage. However, as a read-only list tool, the description provides adequate basics but leaves room for improvement.
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 only 20% (only workspace_id has a description). The description adds meaning for status, assignee, and project by naming them as filter dimensions, but it does not explain assignee_type or how filters combine. It partially compensates for the low schema coverage but leaves several parameters undefined.
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 ('List issues (tasks)') and identifies the resource. It also specifies the filterable dimensions (status, assignee, project), which distinguishes it from related issue tools like get_issue or create_issue. The purpose is unambiguous and not merely a restatement of the name.
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?
The description provides no guidance on when to use this tool versus alternatives such as search_issues. It does not mention exclusions, limitations, or recommended use cases. The only implied context is that it lists issues, which is minimal 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List issue labels' only restates the operation and gives no context about read-only behavior, pagination, ordering, permissions, or return format. It is slightly better than a tautology but still very limited.
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 three-word sentence: 'List issue labels.' It is extremely concise, front-loaded, and contains no filler or redundant information. Every word contributes to the meaning.
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?
This is a simple tool with one optional parameter and no output schema, so the minimal description is partially acceptable. However, it omits useful context such as whether labels are global or issue-scoped, whether results are paginated, and what fields are returned. It is adequate but has clear 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?
The input schema has 100% coverage: workspace_id is clearly described in the schema ('Omit to use the default or your only workspace'). The tool description adds no parameter-level detail, so the 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 uses a specific verb ('List') and a clear resource ('issue labels'), distinguishing this read-only list operation from label mutation tools such as create_label, update_label, and delete_label. It is unambiguous and immediately tells the agent what the tool does.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention typical use cases, differences from list_issues or other label-related tools, or any prerequisites such as workspace selection.
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. It only states the basic action with no disclosure of return format, pagination, ordering, permissions, or default workspace behavior. Minimal 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?
A single, front-loaded sentence with no wasted words. Extremely concise and easily scannable.
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 simple list tool with one optional parameter, the description is minimally adequate but lacks details about return contents or behavior. No output schema exists, so some return information would help, but complexity is low.
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% and the parameter description already explains the optional workspace_id behavior. The description adds no additional parameter detail, so baseline 3 applies.
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?
Specific verb 'List' + resource 'members' + scope 'of a workspace' clearly distinguishes from sibling list_squad_members. Purpose is unambiguous.
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 on when to use this tool versus alternatives. There is no mention of list_squad_members for squad-level member listing or any other exclusions.
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 are provided, and the description only states the action without disclosing side effects, prerequisites (e.g., the agent must be archived), or what 'restore' entails operationally. This leaves the agent without behavioral guidance.
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, direct sentence with no filler words, front-loading the action and resource.
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?
For a mutation tool with no annotations or output schema, the description lacks necessary context about the restore behavior, such as whether it reactivates the agent, any constraints, or the effect of workspace_id. This is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the 'id' parameter or how it relates to an agent, and only the schema provides a minimal description for workspace_id. With 50% schema coverage, the description fails to compensate for the undocumented 'id'.
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 (restore) and resource (agent) with a qualifier (previously archived), clearly distinguishing it from siblings like create_agent, update_agent, and archive_agent.
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 undoing an archival but does not explicitly state when to use it over alternatives or provide exclusions. It does not mention that it reverses archive_agent or that create_agent is for new agents.
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 are provided, so the description carries full responsibility for behavioral disclosure. It conveys a read operation ('Get') and mentions 'full detail,' but does not specify what that includes, error behavior, permissions, or any side-effect-free assurance. This is minimal disclosure for a tool with no annotations.
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 sentence that immediately conveys the tool's purpose. There is no wasted wording, and the key info is front-loaded. 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?
The tool is simple with two parameters and no output schema. However, the description leaves 'full detail' ambiguous and gives no hint about response structure or error cases. Given the lack of annotations and output schema, more context is needed for the agent to know what to expect, especially compared to list_issues which might also return issue data.
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 50% (only workspace_id has a description). The description adds no parameter information. Since the required id is self-evident and workspace_id is already described in the schema, the description does not need to compensate heavily, but it also adds zero 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 states a specific action ('Get') and resource ('one issue'), clarifying with '(task)' and adding 'full detail' to indicate comprehensive retrieval. This clearly distinguishes the tool from siblings like list_issues (plural, listing) and search_issues.
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?
No explicit when/when-not guidance is provided, but the phrase 'one issue' implies use for retrieving a single issue's full data as opposed to listing or searching. No alternative tools are named, making the usage context implied rather than explicit.
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 carries the full burden. It merely restates the tool's name and provides no additional context about behavior, such as read-only status, pagination, authentication requirements, or rate limits.
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 five-word sentence that is perfectly front-loaded and wastes no words. Every word earns its place.
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 and no annotations, the description should explain return behavior and context. It fails to mention pagination, required permissions, what the returned subscribers list contains, or how to handle workspace_id. The minimal description leaves significant gaps for a tool with no structured metadata.
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 50%, with only workspace_id described. The description adds no parameter-specific meaning beyond implying that 'id' refers to the issue, though this is reasonably inferable. It does not compensate for the undocumented id parameter.
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 resource ('subscribers on an issue'), clearly distinguishing it from sibling tools like subscribe_to_issue or list_comments. The scope is precise.
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 usage for viewing subscribers but gives no explicit guidance on when to use it vs. alternatives, such as when to use list_comments or get_issue. No exclusions or alternatives are mentioned.
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 are provided, so the description must fully disclose behavioral traits. It mentions 'dispatches the task,' hinting at a side effect, but it does not explain permissions, reversibility, status changes, or any other side effects. This is insufficient for a mutation tool.
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 sentence that immediately states the action and purpose. It is front-loaded and every word contributes meaning, with no redundancy or filler.
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 three parameters, no output schema, and no annotations, the description should at least clarify the effect on the issue and perhaps what is returned. It only gives a minimal action statement, leaving significant gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only workspace_id being described. The description does not explain 'id' or 'agent_id' at all. Although the names are somewhat intuitive, 'id' is ambiguous and could refer to any entity without clarification.
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 ('Assign') and resource ('existing issue') with an added note 'dispatches the task' that clarifies the action's effect. This clearly distinguishes it from sibling tools like update_issue or comment_issue.
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 makes the use case clear (assigning an issue to an agent) and implicitly differentiates from other issue operations, but it does not explicitly state when not to use it or mention alternatives. There is no misleading 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only restates that it gets details, offering no insight into read-only nature, error behavior, authentication requirements, or return format. This is minimal beyond the tool's name.
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, front-loaded sentence that conveys the core purpose efficiently. There is no fluff or redundant information.
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 simple one-parameter getter, the description is adequate but has gaps. It does not specify what 'details' includes, nor address errors or output structure, especially since no output schema is provided. It is minimally viable but lacks completeness.
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 fully documents the 'id' parameter (workspace id or slug), so schema coverage is 100%. The description adds no additional parameter semantics, making the baseline of 3 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 with a specific verb ('Get') and resource ('one workspace's details'). It distinguishes from siblings like list_workspaces (plural) and update_workspace (modification), so the agent knows this is for retrieving a single workspace's information.
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 when to use it ('one workspace') but does not explicitly mention alternatives or exclusions. For example, it doesn't say 'use list_workspaces to retrieve multiple workspaces.' The usage context is implied, not explicitly stated.
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 are provided, so the description bears full responsibility for behavioral disclosure. It mentions 'built-in' and 'slugs', but does not disclose pagination, authentication, return format, or behavior with the optional workspace_id. Minimal additional context beyond the tool name.
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 one short declarative sentence with no filler. It is appropriately concise for a simple list operation and every word earns its place.
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 simple list tool with one optional parameter and no output schema, the description is adequate but lacks details like what exactly is returned (array of slugs) and how workspace_id affects results. It is not misleading but leaves some ambiguity.
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 single optional parameter workspace_id is fully described in the schema (100% coverage), so the description does not need to add param semantics. It adds no new meaning beyond what the schema already provides, but the schema is sufficient.
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 as 'built-in agent template slugs', clearly distinguishing it from sibling tools that create or manage agents. It succinctly answers what the tool does.
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 usage (list templates to fetch slugs) but does not explicitly state when to use this tool versus alternatives like create_agent_from_template, nor does it provide context such as 'fetch before creating an agent'. The verb 'List' gives a basic hint, but no direct 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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the basic action and scope, without mentioning that it is a read-only operation, what data it returns, or any pagination/ordering behavior. This is minimal and does not add meaningful behavioral context beyond the verb 'list'.
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 concise sentence that is front-loaded with the main action and resource. It avoids redundancy and every word contributes meaningful information.
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 simple list tool with one optional parameter and no output schema, the description is minimally viable. However, it lacks details about the return format, potential pagination, or whether it lists all skills or only those accessible to the user. This leaves some gaps for the agent's understanding of the full 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?
Schema description coverage is 100% for the single optional parameter workspace_id, which already provides a clear explanation. The description does not add extra parameter semantics, but the baseline of 3 is appropriate since the schema fully documents the parameter.
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 'List skills available in the workspace' uses a specific verb ('list') and a clear resource ('skills') with a scope ('workspace'). It clearly distinguishes from siblings like get_skill (single skill) and list_agent_skills (skills attached to an agent), so the purpose is unambiguous.
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 usage by stating the workspace scope, but it does not explicitly explain when to use this tool versus alternatives such as get_skill or list_agent_skills. No exclusions or alternative references are provided, so guidance is only implicit.
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 the burden of disclosing behavior. It does disclose that the archive is a soft-delete and that the agent stops picking up new work, which is valuable. However, it does not mention whether the action is reversible (restore_agent exists as a sibling), what happens to current/running tasks, or any permissions or side effects. Thus it provides some transparency 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 a single, concise sentence that front-loads the main action ('Archive an agent') and adds essential clarifications in parentheses. Every word earns its place, with no filler or repetition. It is appropriately sized for the tool's simplicity.
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 low complexity (2 params, no output schema, no annotations), the description is minimal but covers the core purpose and immediate effect. However, it lacks important context such as reversibility, impact on existing tasks, and any prerequisites or restrictions. While the sibling restore_agent hints at undoability, the description itself does not provide that context, leaving some gaps for an agent invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only 50% of parameters (workspace_id has a description, id does not). The description does not elaborate on what 'id' refers to, leaving the primary parameter undocumented. It also does not mention that workspace_id is optional or explain its default behavior beyond the schema. Since schema coverage is low, the description fails to compensate, adding little semantic value for 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 archives an agent, using a specific verb and resource. It distinguishes from a hard delete by noting it is a soft-delete and further clarifies the effect by saying it stops picking up new work. This aligns with the sibling restore_agent, making the purpose unambiguous.
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 when to use this tool—when you want to softly delete an agent and prevent new work—but it does not explicitly contrast with alternatives like restore_agent or a potential hard delete. There are no exclusions or conditions stated, so the usage guidance is adequate but not fully explicit.
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 must carry the burden of behavioral disclosure. It indicates a read operation via 'Get' and mentions the inclusion of a download URL, but it does not disclose potential errors, permissions, or whether the URL is temporary. For a simple read, this is adequate 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 a single, focused sentence that efficiently communicates the tool's primary function 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?
The tool is simple, but the description does not outline the full metadata structure or any constraints like required workspace context. Given no output schema, a bit more detail on return values would improve completeness, but the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. The schema covers workspace_id with a description, but id is undocumented, and the description adds no information about the expected value format or how to distinguish between attachment ID and other identifiers.
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 'Get' and clearly identifies the resource as an attachment's metadata, explicitly noting it includes the download URL. This distinguishes it from similarly named tools like delete_attachment and list_issue_attachments.
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 fetching attachment metadata, but it does not explicitly state when to choose this over list_issue_attachments or delete_attachment, nor does it mention any exclusions or prerequisites.
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 are present, so the description carries the burden. It only states the action without disclosing details like read-only behavior, pagination, sorting, or response format.
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 concise sentence that directly states the function 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 simple one-parameter read tool and full schema coverage, the description is mostly sufficient, though it omits any note about return structure or default behavior beyond what the schema states.
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 fully documents the single optional workspace_id parameter with a clear description; the tool description adds no additional parameter semantics.
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 the specific verb 'List' with resource 'projects' and scope 'workspace', clearly distinguishing it from sibling tools like create_project, update_project, and delete_project.
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?
No explicit guidance on when to use versus alternatives; the description implies usage for enumerating projects but doesn't mention any alternatives or conditions.
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 carries the full burden of disclosing behavior. It only restates the core action ('List agent runtimes') without detailing side effects, permissions, pagination, ordering, or any other behavioral traits. The read-only nature is implied but not explicitly stated.
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 sentence that is front-loaded and contains no filler. It efficiently communicates the tool's purpose while adding a useful clarification ('machines'). Every word contributes to the 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?
For a simple list tool with one optional parameter and no output schema, the description is largely sufficient. It identifies the scope and what is being listed, though it does not describe return values or default workspace behavior (the latter is covered by the schema).
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 has 100% coverage for the single optional parameter workspace_id, including its purpose and default behavior. The description does not add any parameter-specific detail, so it neither helps nor hurts beyond the schema baseline.
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 resource ('agent runtimes (machines)') with clear scope ('in the workspace'). It distinguishes itself from sibling tools like update_runtime and get_runtime_usage by focusing on listing all runtimes, making the purpose unambiguous.
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 usage (call this to see the runtimes in a workspace) but provides no explicit guidance on when to use it versus alternatives. It does not mention exclusions or prerequisites, though the context is reasonably clear from the verb and resource.
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 carries the full burden of disclosing behavior. It only says 'import' without addressing permissions, side effects, idempotency, or outcome. This leaves the agent unsure whether the operation is safe or mutating and what happens on success or failure.
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?
A single, direct sentence with no filler. It front-loads the core action and source types clearly.
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 simple tool with full schema coverage and no output schema, the description is minimally viable. It explains the core operation but lacks details on behavioral expectations, such as whether the import is additive or replaces an existing skill, and what the response contains.
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 covers both parameters with descriptions (100% coverage), so the tool description adds no additional meaning beyond what the schema already provides. The baseline of 3 applies.
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 action (import) and the resource (skill), and specifies the source types (GitHub, ClawHub, or URL), which distinguishes it from sibling tools like create_skill that would create from scratch.
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 gives clear context on when to use this tool—when you have an external source URL—but it does not explicitly state alternatives or exclusions. The naming and sibling list imply distinction from create_skill, but no direct comparison is made.
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 are provided, so the description carries the full burden of disclosing behavioral traits. It only states the resource type and does not mention that it is a read-only operation, any authentication requirements, pagination behavior, or the structure of the returned list. For a list tool, the lack of output details is a notable gap.
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 one concise, front-loaded sentence that wastes no words. The parenthetical clarification is valuable without being verbose, and all content earns its place.
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 simple list operation with one optional parameter, the description is minimally sufficient. However, it does not specify the return format or what fields are contained in the list, and there is no output schema or annotations to compensate. The sibling tools (e.g., get_autopilot) imply some structure, but the description alone leaves room for ambiguity.
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 single parameter workspace_id is fully documented in the schema with a clear description, so schema coverage is 100%. The tool description itself does not add any additional meaning to the parameter beyond what the schema already provides, keeping this at the baseline.
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 ('List') and the resource ('autopilots'), with the parenthetical 'scheduled/triggered automations' adding helpful domain context. This distinguishes it from sibling tools like get_autopilot (singleton details) and list_autopilot_runs (historical runs) by specifying the top-level collection.
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 that this tool lists all autopilots. The parameter description for workspace_id adds a usage nuance (omit to use default/only workspace), which is helpful. However, it does not explicitly mention when to prefer this over get_autopilot or list_autopilot_runs, so it lacks explicit exclusions/alternatives.
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 the full burden. It explicitly discloses that deletion immediately clears comments, reactions, and attachments and that the action cannot be undone. This is valuable behavioral context beyond a simple 'delete' statement, though it does not mention permissions or response behavior.
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 short sentences, front-loaded with the core action 'Delete an issue.' Every phrase adds value: the cascade effect and irreversibility are concise and clearly structured, with no filler.
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 delete tool with no output schema, the description is largely complete: it explains what is deleted, the immediate cascade, and irreversibility. It falls slightly short by not mentioning any success/failure indicators or whether the issue ID must exist, but these are typical implicit expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers workspace_id with a description but leaves id undocumented. The description adds no parameter-level meaning, failing to explain the required 'id' parameter. Since schema coverage is only 50%, the description should compensate, but it doesn't, leaving the most critical parameter underspecified.
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 an issue,' which is a specific verb+resource action. It distinguishes this from sibling tools like create_issue, update_issue, and get_issue by focusing on deletion and adding the cascading cleanup of comments, reactions, and attachments.
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 usage for permanent deletion with the caution 'cannot be undone,' but it does not explicitly state when to use this versus alternatives like update_issue for closing or deactivating an issue. There is no mention of prerequisites or when not to use the tool, so guidance is only 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?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the operation is a soft-delete/archive and that assigned issues transfer to the leader, which are important side effects. It does not mention permissions, reversibility, or failure scenarios, but the core behavior 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 a single, concise sentence that front-loads the verb 'Archive' and immediately states the key side effect. Every word contributes, with no redundancy or filler.
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 tool with 2 parameters and no output schema, the description covers the primary action and a key side effect. However, it omits any indication of return values, prerequisites, error conditions, or what happens to unassigned issues, making it moderately complete but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with only workspace_id documented. The tool description does not add any explanation for the 'id' parameter or clarify the semantics of either parameter beyond the schema, leaving a gap for the undocumented id. It relies on the tool name to infer that id refers to the squad, but this is not explicit.
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 'Archive (soft-delete)' on the 'squad' resource and specifies the consequence for assigned issues (transfer to leader). This distinguishes it from sibling tools like update_squad and delete_issue, providing a specific verb+resource+effect.
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 indicates the purpose is to archive/soft-delete a squad and explains the resulting behavior for issues, giving clear context for when to use this tool. However, it does not explicitly mention when not to use it or name alternatives, but since there is no sibling tool for deleting squads, the context is sufficient.
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 provided, the description carries the full burden. It clearly states a 'Get' operation, implying read-only behavior, but does not disclose potential error conditions (e.g., invalid token) or authentication expectations. It adds minimal context beyond the basic action.
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, front-loaded sentence with no redundant wording. Every word contributes to understanding the tool's purpose.
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 zero-parameter read-only identity check with no output schema, the description is largely sufficient. It could mention the return format or authentication details, but given its simplicity, it covers the essential function adequately.
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 accepts zero parameters and the schema is empty, so the description need not explain parameter meanings. Per the 0-param baseline guideline, a score of 4 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 'Get the authenticated user/account for the current token' uses a specific verb ('Get') and resource (authenticated user/account), clearly distinguishing it from all sibling tools. No other tool performs an identity lookup.
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 when to use the tool: when you need to know the current token's user/account. However, it does not explicitly mention alternatives or exclusion criteria, making the usage guidance implicit rather than explicit.
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 the full burden. It discloses that the operation is scoped to the token's access, but it doesn't explicitly state that it's read-only, nor does it mention return format or pagination. The verb 'List' implies a safe read, but the description is minimal and doesn't add significant behavioral context beyond that.
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 sentence that front-loads the verb and resource, with no wasted words. It's concise and immediately 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 the tool's simplicity (zero parameters, no output schema), the description is adequate. It specifies what is returned (a list of workspaces) and the scope (token access). One might expect more detail about the output structure, but for a zero-param list tool this is reasonably 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?
The tool has zero parameters, and the schema coverage is complete (empty properties). The description needs to add nothing about parameters, and it doesn't. Baseline for 0 params is 4, which 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 ('List'), the resource ('workspaces'), and clarifies the scope with a parenthetical ('companies') and the access constraint ('this token can access'). This distinguishes it from sibling tools like get_workspace or list_members.
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: it lists all workspaces accessible by the current token. It doesn't explicitly mention alternatives or when not to use it, but the scope is evident. No exclusions are stated, which is acceptable for a simple list tool.
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:

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

Score Badge

Copy to your README.md:

[![aacworkflow-mcp MCP server](https://glama.ai/mcp/servers/AAChibilyaev/aacworkflow-mcp/badges/score.svg)](https://glama.ai/mcp/servers/AAChibilyaev/aacworkflow-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/AAChibilyaev/aacworkflow-mcp'

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