AI Team OS

by CronusL-1141

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.11.3
Disambiguation2/5
There is heavy overlap among memory-related tools (memory_add, memory_list, memory_invalidate, memory_reconcile_candidates, memory_reconcile_apply) and especially within the ecosystem staging pipeline where tools like ecosystem_scan, ecosystem_scan_periodic, ecosystem_index_update, and ecosystem_apply_shallow_summary/ecosystem_claim_shallow create a complex web of stage workers. Some boundaries are documented but an agent must parse long descriptions to distinguish e.g. ecosystem_summary_health vs ecosystem_summary_weekly vs ecosystem_summary_by_tag vs ecosystem_summary_top_n, all of which sound similar. The legacy/duplicate tools (meeting_create vs debate_start vs debate_code_review, task_run vs task_create, agent_update_status vs team_status) add genuine confusion.
Naming Consistency3/5
Most tools follow a consistent noun_verb pattern (task_*, team_*, agent_*, meeting_*, ecosystem_*, briefing_*, channel_*, project_*, memory_*), which is good. However, there are notable outliers: 'fleet_dispatch', 'link_trace', 'unified_search', 'verify_completion', 'diagnose_task_failure', 'prompt_effectiveness', 'usage_attribution', 'os_restart_api', 'os_health_check' break the pattern and mix noun-first with verb-first styles. Verbs are also inconsistent (create vs add vs save for essentially 'create' operations). The set is readable but not uniform.
Tool Count1/5
109 tools is far beyond the well-scoped range for any single MCP server and dramatically exceeds even the generous 25+ level. The ecosystem sub-system alone accounts for ~35 tools, and task/memory/meeting sub-domains each carry 5-10. Even for a sprawling 'AI Team OS' this represents extreme surface bloat, and the number of near-duplicate or staged-pipeline tools (ecosystem_claim_shallow, ecosystem_claim_review, ecosystem_apply_*, ecosystem_release_claim) suggests many could be consolidated.
Completeness3/5
The surface is at times redundant (multiple ecosystem scan/summary/list entry points) yet still has notable gaps: team update/rename and agent removal are absent, project task assignment/lifecycle beyond create/update is partial, and there is no explicit agent_terminate or team_archive. The meeting domain lacks a meeting reminder/cancel, and task retrieval is spread across task_status/task_list_project/task_memo_read in a fragmented way. This is a 'more than enough but not well-shaped' edge case rather than a starvation problem.
Average 4/5 across 109 of 109 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 262 commits in the last 12 weeks
- Last stable release on August 14, 2026
- 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

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 discloses nothing about behavior beyond 'search' — no mention of whether results are ordered, whether scope affects behavior, what happens with empty queries, or whether this is a read-only operation. For a tool with zero annotations, this is a significant gap, though the lack of destructive intent is at least implied by the name and description.
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 with zero waste. It's minimal but appropriately concise. However, it's arguably under-specified rather than concise — the one sentence covers only the most basic purpose and provides no additional value.
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 schema is fully documented (100% coverage) and there is an output schema, which reduces the burden on the description for parameters and return values. However, given the large set of related search and memory siblings, the lack of differentiation guidance makes the description incomplete for tool selection confidence. The complexity is moderate but the description fails to address the 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?
Schema description coverage is 100%, so the schema documents all 4 parameters (limit, query, scope, scope_id). The description adds no parameter meaning itself. The schema already describes each parameter reasonably, including the scope_id default inference behavior. Since coverage is high, the baseline of 3 applies — the description adds nothing but the schema carries the load adequately.
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 'Search the memory store in AI Team OS' uses a clear verb (search) and resource (memory store), but is extremely generic. It doesn't specify what kinds of memories are searchable, what the search returns, or how it differs from the many sibling search tools like unified_search, ecosystem_search, or memory_list. The verb+resource is clear but the scope and distinction from siblings is absent.
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 memory_search vs alternatives. There are several search-related siblings (unified_search, ecosystem_search, find_skill, context_resolve) and related memory tools (memory_list, memory_add, memory_invalidate), but the description provides zero context on when this specific search tool is appropriate. No exclusions or alternatives 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?
With no annotations, the description must disclose all behavioral traits. It fails to mention that the tool potentially saves a report (as implied by the save_report parameter defaulting to true) or the fact that output is markdown. The description is too sparse to inform an agent about side effects or persistence.
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 sentence, front-loading the core purpose. It is efficient with no wasted words, though it sacrifices clarity 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 description lacks important context: it does not explain what 'profile / scan / tag coverage / archive ratio' entails, what the output looks like (despite an output schema existing), or the implications of the save_report parameter. For a self-check tool, more detail is needed to ensure proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters (author and save_report) and their defaults. The description adds no additional meaning about parameters; it focuses on the report content. Baseline 3 is appropriate.
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 states 'Platform self-check markdown: profile / scan / tag coverage / archive ratio.', indicating it produces a health report, but the verb is implicit and the scope is vague. It does not clearly distinguish from sibling ecosystem_summary_ tools like ecosystem_summary_by_tag or ecosystem_scan_status, which may overlap.
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 (e.g., ecosystem_scan for scanning or ecosystem_summary_weekly for periodic summaries). There is no mention of prerequisites, expected 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?
No annotations exist, so the description must disclose behavior. It only states the basic lookup action, with no mention of side effects, permissions, or guarantee of read-only operation. For a lookup tool, the description is insufficiently transparent.
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 directly states the action. It is front-loaded and efficient, though it could be slightly expanded 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?
Given the existence of an output schema, return values need not be explained. However, the description lacks any context about prerequisites, error cases (e.g., no deep review found), or relation to other deep review tools. For a simple lookup, it is 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?
With 100% schema coverage, the baseline is 3. The description mentions repo_id but adds no semantic value beyond the schema's description 'EcosystemRepoProfile.id.' It does not explain how to obtain or format the ID.
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 looks up the most recent deep-review for a given repo, using a specific verb and resource. While it differentiates from siblings like ecosystem_deep_review_list (which lists all) by focusing on a single most recent result, it does not explicitly compare itself to siblings.
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 ecosystem_deep_review_list or ecosystem_deep_review_request. The description lacks context for when this lookup 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?
No annotations provided, so full burden is on description. It only states the action (linking) but omits behavioral traits like idempotency, overwrite behavior, permissions, or error handling. Minimal disclosure 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?
Very concise single sentence, front-loaded with key action. However, it is extremely terse and could benefit from slight expansion without losing 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?
Given the simple tool with an output schema, the description lacks context about its role in the pipeline (Stage 3), prerequisites, or outcome. Not enough for an agent to decide when to invoke it.
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 existing parameter descriptions are clear ('Task id returned by...', 'Target deep_review row id.'). The description adds no extra meaning, so baseline 3 is appropriate.
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 states 'link integration task id back to review row', which is a specific verb+resource that clarifies the tool's purpose. However, it does not differentiate from sibling tools like 'ecosystem_link_debate_meeting', but the action is distinct enough.
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. The description mentions 'Stage 3 helper' implying a pipeline context but provides no explicit when/when-not or alternative 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?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, authentication needs, or rate limits. The description only states what the tool does, not its behavioral profile. Since the description carries the full burden, it is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the core action. It efficiently communicates the holistic nature of the result. However, it could be slightly more structured without becoming verbose, so it does not earn a perfect score.
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 that an output schema exists, the description does not need to explain return values in detail. However, for a tool with 4 parameters and multiple returned components, the description is somewhat sparse. It adequately covers the basic purpose but lacks context about how the parameters influence the output or edge cases.
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?
All parameters are described in the input schema (100% coverage), so the baseline is 3. The description does not add any additional meaning about the parameters beyond what the schema already provides. Therefore, it meets the baseline but does not exceed it.
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 retrieves a holistic detail of an ecosystem repo, listing the included components (profile, tags, deep reviews, relations, scan run). It uses a specific verb 'Get' and resource 'ecosystem repo', making the purpose evident. However, it does not differentiate from sibling tools like ecosystem_repo_events or ecosystem_repo_tags, which might share some functionality.
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 prerequisites, when it is appropriate, or when to use other tools like ecosystem_repo_events or ecosystem_scan_status. Given the large number of sibling tools, this is a significant gap.
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 full burden. It only states 'Delete a project.' without disclosing side effects, reversibility, or cascade deletion. The destructive nature is implied by the name, but not elaborated.
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 wasted words. It is appropriately sized for a simple tool, though it could be slightly more informative without losing 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?
Given the simple one-parameter tool with output schema, the description is somewhat adequate but missing details like return value indication (e.g., success message or deleted project object) and permissions needed. It meets minimum but not full 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?
Schema description coverage is 100% for the single parameter project_id. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
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?
Description clearly states verb 'Delete' and resource 'a project', making the action unambiguous. However, it does not differentiate from sibling tools like project_create or project_update, so it misses the highest 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 on when to use this tool versus alternatives, no prerequisites or exclusions provided. The description offers no context for appropriate usage.
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 behavioral traits like idempotency, authorization needs, side effects (e.g., whether the briefing is archived), or error conditions (e.g., invalid briefing_id). 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?
Extremely concise single sentence that front-loads the action and object. However, it lacks any supporting detail; it is concise but arguably under-specified. Still, it earns a 4 for 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?
With an output schema present, the description does not need to detail return values, but it still fails to explain side effects, prerequisites (e.g., user must have permission), or error handling. For a state-changing tool, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters documented sufficiently. However, the description adds no additional meaning or constraints beyond what the schema already provides, e.g., format or expected values for 'resolution' or 'briefing_id'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it resolves a Leader Briefing item using the user's decision. The verb 'resolve' and object 'Leader Briefing item' are specific, and it distinguishes from siblings like 'briefing_dismiss' (dismiss without decision) and 'briefing_add' (add a new item).
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 such as 'briefing_dismiss' or 'briefing_list'. It does not specify prerequisites, when a resolution is appropriate, or what scenarios call for this tool instead of 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?
No annotations provided, and the description does not disclose behavioral traits such as side effects (e.g., save_report parameter persists results). The description only states output format without revealing mutation or write behavior.
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 sentence, which is concise, but it sacrifices clarity and completeness regarding behavior. It is appropriately front-loaded but too brief for a tool with 5 parameters.
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 presence of an output schema, the description does not need to explain return values. However, for a tool with multiple parameters and many siblings, more context on usage and side effects would improve 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?
Schema coverage is 100%, and each parameter is well-described in the schema. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Top-N markdown table of ecosystem repos' uses a specific verb ('Top-N markdown table') and resource ('ecosystem repos'), clearly distinguishing it from sibling tools like ecosystem_search or ecosystem_repo_get.
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. Given many sibling ecosystem tools, explicit context on when to choose this tool over others is missing.
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 to indicate safety or destructiveness. The description does not disclose any behavioral traits (e.g., idempotency, caching, access requirements) beyond the basic fetch action, leaving agents without sufficient context.
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 clear sentence with no extraneous words. However, it is minimal and could be slightly more informative without losing 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 simple fetch-by-ID tool, the description is acceptable but lacks any context about when to use it relative to siblings. The presence of an output schema compensates partially, but guidance is missing.
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% (the only parameter 'run_id' is described in the schema). The description adds no additional semantic value beyond the schema's own field 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 'Fetch a single EcosystemScanRun by id' clearly states the action (Fetch) and the resource (a specific EcosystemScanRun by its ID). It is distinct from sibling tools like ecosystem_scan_history (list history) or ecosystem_scan (initiate scan).
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 such as ecosystem_scan_history or ecosystem_deep_review_status. The description lacks context about prerequisites or typical use cases.
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 full burden but only states partial update behavior. It does not disclose side effects, permissions, or whether the update is synchronous. Parameter descriptions in schema cover per-field 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?
Single sentence, front-loaded with verb and resource, parenthetical explains partial update. 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 8 parameters and many sibling tools, the description is too minimal. It lacks guidance on when to use this versus other task operations and does not address potential caveats. Output schema may help, but description is still insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% so baseline is 3. The description adds 'partial update' context but no additional parameter-level meaning 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 states the tool updates a task's fields and specifies it's a partial update. It distinguishes from task creation and other update tools, but does not explicitly differentiate from sibling update tools for other entities.
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 partial updates where only specified fields change, but provides no explicit guidance on when not to use or mention of alternatives like task_run or task_create.
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 must cover behavioral traits. It only says 'Update' (implying mutation) but lacks details on permissions, side effects, idempotency, or what happens during the update.
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 extraneous words. It is as concise as possible while 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?
While the tool is simple and has an output schema, the description lacks usage guidelines and behavioral context. It is minimally adequate but leaves gaps for an AI agent to infer best practices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an Agent's running status,' which is a specific verb (update) and resource (agent status). It distinguishes from sibling tools like agent_register or agent_heartbeat by focusing on status changes.
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 any prerequisites or context. It is a bare statement of function.
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, and the description does not disclose behavioral traits such as side effects (none expected for a query), auth requirements, rate limits, or pagination behavior. The word 'Query' hints at read-only, but not explicitly confirmed.
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 with no wasted words. It front-loads the purpose and provides concrete examples efficiently.
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 presence of an output schema and full parameter descriptions, the description is nearly complete. It could mention ordering (e.g., chronological) but the schema covers limit and filtering. Adequate for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds value by explaining what kinds of decisions are captured (task assignments, approach selections, scheduling), which enriches the meaning of the event_type parameter 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 states the tool queries the team decision log and provides examples of content (task assignments, approach selections, scheduling decisions). However, it does not explicitly differentiate from sibling tools or mention its scope relative to them.
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 vs alternatives, nor any exclusions or prerequisites. The description implies a query context but lacks explicit usage directions.
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 the description carries the full burden. It only says 'Submit... result' without revealing what happens upon submission (e.g., idempotency, merging behavior, error conditions). Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, precisely communicates the core action.
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?
While output schema exists and parameters are covered, the description lacks context on how the result is applied (e.g., append vs. replace) and what layer 3 tagging entails. Adequate but incomplete for full understanding.
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 description essentially repeats schema information without adding new meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Submit' and the specific resource 'Layer 3 LLM tagging result from a sub-agent'. It effectively distinguishes this tool from similar siblings like ecosystem_apply_architecture_md and ecosystem_apply_debate_result by focusing on LLM tagging results.
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 such as ecosystem_tag_apply_batch or ecosystem_tag_dispatch_llm. The description lacks explicit context for usage 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 provided, so description must disclose all behavioral traits. It only lists updatable fields without mentioning side effects, reversibility, error cases (e.g., non-existent project), or concurrency implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, every word adds value. Appropriately concise for a straightforward update operation.
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?
While the tool is simple, the description omits return value or success indication. Given an output schema exists (not shown), additional guidance on expected outcome would improve 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?
Input schema has 100% description coverage, so parameters are already documented. The description adds no additional meaning beyond listing the fields, resulting in baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (update) and resource (project), listing specific fields (name, description, root_path). It distinguishes from sibling tools like project_create, project_delete, and project_list.
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 vs alternatives, no prerequisites, permissions, or conditions mentioned. The description lacks context for appropriate usage.
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 convey all behavioral traits. It mentions that no action is needed after dismissal, but lacks detail on side effects, required permissions, or reversibility. This is adequate but minimal.
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. Every word is necessary, and there is no wasted 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 simplicity of the tool (one parameter, output schema exists), the description is too terse. It does not explain what happens after dismissal (e.g., state change, visibility) or how it differs from related tools. The phrase '(no action needed)' causes ambiguity rather than clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the only parameter 'briefing_id' as 'Briefing item ID'. The description does not add additional meaning or context about how the parameter is used, so it does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (dismiss) and the object (Leader Briefing item), distinguishing it from sibling tools like briefing_resolve and briefing_list. The verb 'Dismiss' 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?
No explicit guidance on when to use this tool versus alternatives such as briefing_resolve. The phrase '(no action needed)' hints at a scenario but does not clearly define when dismissal 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?
No annotations are provided, so the description must disclose behavioral traits. It only states the purpose and event types, but does not mention read-only nature, authentication requirements, rate limits, ordering (e.g., chronological), pagination, or error handling. The behavioral profile is severely under-disclosed for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first sentence states purpose concisely, and the second lists event types to set expectations. The description is front-loaded and efficient. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. It covers the essential purpose and event types. Missing details like default ordering (e.g., most recent first) or behavior for invalid repo_id prevent a perfect score, but the tool is simple and context is mostly complete for use.
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% (both parameters have descriptions). The tool description adds context beyond the schema by listing the event types that may appear, which helps interpret the repo_id parameter. However, it does not clarify how the 'limit' parameter interacts with results (e.g., default ordering, truncation). Baseline of 3 is appropriate since the schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns event history for a single ecosystem repo, specifying the resource ('single ecosystem repo') and the action ('return event history'). It also lists the discrete event types, distinguishing it from sibling tools like ecosystem_repo_get (current state) and event_list (broad events). The verb 'return' and resource are precise.
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 ecosystem_repo_get for current state or event_list for cross-repo events. There are no explicit when-to-use, when-not-to-use, or comparisons with siblings. The agent must infer usage from the name and 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 provided, so the description carries full burden. It does not disclose behavioral traits such as message ordering, pagination behavior, or error handling (e.g., for nonexistent meetings). The minimal description leaves ambiguity.
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?
Extremely concise: one sentence, six words. Every word is necessary and clear, with no wasted content.
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 presence of an output schema and simple parameters, the description is mostly complete for a read operation. However, it lacks mention of ordering or pagination behavior, which would be helpful for 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 coverage is 100% with both limit and meeting_id having descriptions. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'all discussion messages in a meeting', distinguishing it from siblings like meeting_send_message and meeting_list.
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 (e.g., meeting_send_message for writing, channel_read for channels). The description simply states what it does without contextual usage advice.
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 full burden but only mentions the outputs. It does not disclose read-only nature, side effects, auth requirements, or rate limits, leaving behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear structure: verb, resource, key outputs. No wasted words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema and presence of output schema, the description adequately covers what the tool returns. Minor omission: does not state it's read-only, but acceptable for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no new meaning beyond the schema's parameter description. The auto-use of active project is already in schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a quick project summary, listing specific outputs: status, teams, top tasks. This distinguishes it from sibling tools like project_list or task_list_project.
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 explicit guidance on when to use this tool versus alternatives like project_list or task_list_project. The description implies usage for a single project summary but lacks exclusions or 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 should disclose side effects, permissions, and boundaries. It only states 'Read the full content', implying a read-only operation but omits details on error handling, size limits, or authorization 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, concise sentence that uses front-loaded phrasing. Every word adds value with no redundancy or 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?
Given the tool's simplicity (one parameter, output schema present), the description covers the essential purpose. However, it could mention that it returns the full report content versus a summary, but the output schema compensates for this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond 'by ID', which is already implied by the schema's required report_id parameter description. No additional context about the parameter is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('full content of a saved report'), with the qualifier 'by ID'. It effectively distinguishes from sibling tools like 'report_list' and 'report_save'.
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 (e.g., report_list for metadata, report_save for writing). It does not mention 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?
No annotations are provided, so the description carries full burden. It discloses the basic read operation but does not mention any behavioral traits like side effects, permissions required, or error states. Minimal transparency beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence states purpose, the second provides usage guidance. Every word is useful and front-loaded.
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 description is adequate given the presence of an output schema (not needing return value details). However, it lacks information about edge cases (invalid meeting, no participants, round not started) and potential error conditions, making it somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (meeting_id) with 100% coverage. The description does not add any extra meaning beyond the schema's 'Meeting ID' label. Baseline 3 is appropriate.
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 (check) and resource (expected participants) with context (spoken in current round). However, it does not explicitly differentiate from sibling tools like agent_activity_query or meeting_read_messages, which could have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use after spawning agents via dispatch_plan and before advancing to next round or concluding. It clearly indicates when to use, but does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description adds the important note that team_id is never auto-resolved (addressing a potential failure mode). However, it doesn't disclose whether the delete is permanent or recoverable, what the output schema looks like, or whether there are cascading effects on related resources (tasks, meetings, briefings associated with the team). For a destructive mutation tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose and includes the critical usage constraint. It's efficient with zero waste. However, given the tool's destructive nature and absence of annotations, a slightly larger description covering behavioral aspects would arguably justify the space — but as written, it is tight and to the point.
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 destructive mutation tool with zero annotations, the description is thin. It confirms the delete action and parameter requirement but omits crucial context: what happens to the team's associated data, whether deletion is permanent or reversible, permission/auth requirements, and what the output/return value indicates. An output schema exists but the description doesn't reference what it would convey. Given the complexity of team deletion (likely cascading effects across tasks, meetings, briefings), the description is not complete enough.
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% — the single team_id parameter is documented in the schema as 'Team ID or name to delete'. The description adds only that it's REQUIRED and never auto-resolved, which reinforces rather than extends the schema. Since the parameter is simple (one field, no enum, no nested objects), the baseline 3 is appropriate; the description doesn't add semantic detail beyond what the schema provides.
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 states a clear action: 'Delete a team' — a specific verb ('Delete') with a specific resource ('a team'). Among siblings, team_delete is distinct from team_close, team_status, and team_list, and the name itself communicates the destructive intent clearly. It could benefit from noting scope (e.g., permanent vs soft delete), but the core purpose is clear.
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 emphasizes that team_id is REQUIRED and never auto-resolved, which is a meaningful usage constraint. It doesn't explicitly say when NOT to use this or name a sibling alternative, but the destructive nature combined with the sibling set (team_close, team_status) makes the intended usage reasonably clear. Close siblings like team_close are not explicitly differentiated, so a 4 rather than 5.
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 explains some filtering semantics but does not disclose return volume limits, pagination, ordering, whether resolved/dismissed items are summarized or detailed, or whether this is a read-only operation. Given zero annotation coverage, this is a meaningful gap for a list-type 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?
Two short paragraphs, front-loaded with purpose and default behavior, then rationale for filter design. Efficient and focused. Slightly verbose in the project_id explanation but that content earns its place given the unusual 'current' sentinel. 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?
There is an output schema present, so return format is covered. The description covers default behavior, filtering semantics, and design rationale. Minor gaps: no mention of pagination or result ordering for a list tool, and no explicit 'read-only' statement. For a filtered list tool with output schema, 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?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the default status (pending), the project_id empty-default semantics and the 'current' special value, and the tag narrowing use case. This meaningfully complements the schema's reusable intent behind default filtering behavior.
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+resource ('List Leader Briefing items') and clarifies the default behavior (shows pending items). It distinguishes itself from siblings like briefing_add/briefing_resolve/briefing_dismiss since this is the listing operation. It could mention the 'Leader' scope more explicitly but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains default behavior ('Default shows pending items') and gives concrete use guidance: narrowing a long decision queue by project_id and/or tag. It explains the project_id empty-default rationale (not hiding anything, pre-2026 rows unprotected). It doesn't explicitly name alternatives among siblings, but the filtering guidance is actionable and clear.
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 burden. It only states that runs are filtered by 'recent' and ordered by started_at descending, but fails to disclose permissions, rate limits, side effects, or the scope (e.g., project-specific vs global).
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 conveys the essence without any extraneous words. It is front-loaded with the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two optional parameters and a provided output schema. The description covers the core functionality (listing recent runs by date). Minor gap: it doesn't specify the source of 'scan runs' (e.g., across all projects), but this is acceptable for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already well-described. The description does not add additional meaning beyond the schema for limit and strategy. 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 resource ('recent scan runs') with ordering. It clearly distinguishes from sibling tools like ecosystem_scan (which triggers scans) and ecosystem_scan_status (which provides current status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing historical scan runs, but does not explicitly state when to use this tool versus alternatives like ecosystem_scan_status or ecosystem_scan. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It's a read/search operation (implied by 'search'), but nothing explicitly states that it's non-destructive, whether results are paginated defaults, or how the tags parameter behaves (AND vs OR semantics are only in the schema). The description adds the reverse-lookup framing over the schema but doesn't disclose behaviors like default sort, pagination bounds, or that match_mode controls tag combination. Schema covers some of this.
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 crisp sentence that front-loads the verb and resource, then adds the distinguishing parenthetical. Zero wasted words — every token earns its place. This is model conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (so return format is documented elsewhere), 100% schema coverage for all 7 params, and a clean single-sentence purpose statement. For a read/search operation with well-documented schema and output, the description is reasonably complete. It could marginally improve by noting it complements ecosystem_search and is non-mutating, but the output schema + full param docs offset most gaps. Given the tool is a simple filtered search, this is near-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?
Schema description coverage is 100%, so all 7 parameters are already documented in the input schema. The description adds minimal parameter-level value beyond the schema — the reverse-lookup framing helps understand tags, but the description doesn't explain parameter interactions like how match_mode 'all'/'any' combines multiple tags or how min_stars/max_stars bracket popularity. The schema carries the burden, so baseline 3 is appropriate.
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 'Search ecosystem repos by capability tags (reverse lookup from tag → repo)' clearly states the verb (search), resource (ecosystem repos), and the distinguishing characteristic (reverse lookup from tag to repo — the inverse of a forward tag search). This differentiates it from sibling tools like ecosystem_repo_tags, and the parenthetical adds useful clarity. It loses a point because the exact semantics of 'capability' vs general tags is not fully explained.
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 notes this is a reverse lookup from tag→repo, which implies it's the inverse of ecosystem_repo_tags (repo→tags). However, there is no explicit when-to-use/when-not-to-use guidance, no stated alternative tools, and no comparison against ecosystem_search (the likely forward search sibling). The parenthetical hints at positioning but doesn't explicitly guide tool 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the return format without mentioning side effects, permissions, rate limits, or that it is read-only. The agent cannot infer safety or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately stating the purpose and then the return format. Every sentence is essential, with no redundancy or 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?
Given the trivial parameter set and presence of an output schema (not shown), the description adequately covers what the tool does. It could mention that all templates are returned without filtering, but overall it is sufficient for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the input schema covers 100%. The description does not need to add parameter info. According to the rubric, 0 parameters yields a baseline of 4.
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 clearly identifies the resource ('available meeting templates') and their 'round structures'. It distinguishes itself from sibling tools like 'agent_template_list' by specifying meeting templates.
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 vs alternatives (e.g., 'agent_template_list', 'meeting_create'). No mention of prerequisites or context. The description does not help the agent decide when to invoke this tool.
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 full burden for behavioral disclosure. It only states 'Query' but does not confirm read-only behavior, potential side effects, or response format beyond what the output schema implies. More detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, front-loaded with key information. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the essential purpose. The existence of an output schema partially explains return values, reducing the need for elaborate description. However, a brief mention of what statuses might be returned could improve 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?
Schema coverage is 100% (task_id with description 'Task ID'), and the description adds no extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query' and the resource 'current status of a task,' making the tool's purpose unmistakable. It easily distinguishes from sibling tools like task_create or task_run.
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 this tool versus alternatives (e.g., task_subtasks might also show status). The tool is simple, so context is implied, but no exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that this is a write/mutation operation ('Set (or clear) the human override') and mentions 'stored for audit' for the reason parameter, which is useful. However, it doesn't disclose whether this is destructive, whether it can be reversed, what permissions are needed, or what happens to previously set values when clearing. It also doesn't describe response behavior despite having an output schema.
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 compact and well-organized, with the core statement in the first line and supporting context about the historical consolidation following. Every sentence adds value. Minor inefficiency: the historical-tool context, while valuable, could be slightly tighter, but it's justified given the consolidation rationale.
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?
With a write-operation tool, no annotations, and an output schema present, the description should still clarify behavior. It explains the purpose well but omits guidance on the output schema semantics, error conditions, authorization needs, or reversibility of the override. The consolidation context helps a lot, but for a mutation tool the behavioral gaps are noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all four parameters. The description adds meaning by explaining that the status argument's ``pinned`` / ``no_value`` values map to the old distinct tools (pin_active, mark_no_value) and empty string clears. It also clarifies reason is 'recommended when setting,' adding guidance beyond the schema. This is a genuinely helpful layer beyond the structured 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 states the verb+resource: 'Set (or clear) the human override on a repo's active status.' It also provides valuable context by explaining this tool consolidates four historical tools that posted identical payloads. However, it doesn't explicitly name the sibling 'ecosystem_mark_as_reference' or 'ecosystem_repo_get' to differentiate, though the historical-tool context does distinguish it from other ecosystem tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this is the single entry point for all manual verdicts and that four historical tools (pin_active/unpin/mark_no_value/clear_manual_status) are consolidated here, mapping to the status argument values. This gives clear guidance on the semantic range of operations. It doesn't explicitly state when NOT to use it versus read-only tools, but the context about being the only manual-status tool is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that model discovery is auto-derived from local CC transcripts (a useful behavioral detail), that the default comes from a settings file, and that usage is aggregated over N days. However, it does not mention whether this is read-only, whether it makes external calls, or performance characteristics. The detail about behavior is substantive for a pure read/inspection 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?
Single dense sentence with parenthetical asides. The parenthetical commentary like 'the models you actually used' and 'how much fable vs opus the fleet burned' adds flavor and domain context but borders on unnecessary flourish. Well front-loaded with the verb 'Get' and clear components, though slightly verbose for what could be more compact.
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?
An output schema exists, so return-value detail is not required in the description. The tool's three-part return is thoroughly enumerated. The only gap is that behavioral safety (read-only nature) is not explicitly stated, but with an output schema present, the context is largely sufficient for a config inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — usage_days has a complete description (aggregation window, default 7, max 90). The description's reference to 'last N days' and 'over the last N days' reinforces but does not add meaningfully beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 three things this tool returns: available models (auto-discovered), current default startup model, and per-model workflow agent usage over a time window. The verb 'get' and resource 'model governance state' are specific and unambiguous. The sibling tool model_config_set clearly complements it (get vs set), making differentiation natural.
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 this is a read/config-inspection tool but does not state when to use it vs alternatives. However, model_config_set is the obvious sibling and the read-vs-write distinction is largely implied by the name. No explicit when-not-to-use guidance is given for the usage_days window bounds (max 90 in schema).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does an admirable job explaining the compact projection behavior, clarifying that compact means 'trimmed, NOT missing fields', describing how event payloads and pending tasks are projected, and even citing a measured character count on a real team. This goes well beyond a typical description.
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 somewhat long (multiple paragraphs) but front-loads the core purpose in the first sentence, then layers projection details and a measured-size data point that are genuinely useful for an agent deciding how to consume the response. The compact-vs-trimmed clarification earns its place though it adds length.
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?
This is a moderately complex tool with 5 parameters, an output schema, and no annotations. The description covers the response structure, the compact projection semantics, and references the related agent_list convention. It explains what the caller will receive well. Minor gap: no explicit statement about what 'action suggestions' means or costs/limits of the full briefing, but the measured-size hint partially addresses this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly (limit, fields, team_id, include_offline, offline_preview). The description adds context about the 'compact projection' concept referenced in the fields and limit parameters, reinforcing what the schema says. Baseline 3 is appropriate since the schema does the heavy lifting.
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 provides a 'team panoramic briefing' covering team info, member status, events, meetings, tasks, and suggestions. The verb 'Get' plus the resource 'team briefing' is specific, though it doesn't explicitly distinguish from siblings like team_status or team_list. The mention of 'one call' adds context.
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 this is for understanding 'full team status in one call' and references the sibling agent_list convention, but provides no explicit when-to-use vs alternatives guidance. It doesn't say when NOT to use this and prefer team_status, team_list, or agent_list. Usage context is implied rather than stated.
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?
Implies read-only behavior and mentions incremental pull, but with no annotations, it could be more explicit about idempotency or non-destructiveness. Does not cover error cases or behavior for missing channels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: one for purpose, one for key usage hint. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple read tool with output schema and well-documented parameters. Could mention ordering or when to use other channel tools, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no extra meaning beyond the schema, only referencing the 'since' 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?
Clearly states the tool reads messages from a channel, using a specific verb and resource. Distinguishes from sibling tools like channel_send and channel_mentions.
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?
Mentions incremental pull via 'since' parameter, providing a usage hint, but lacks explicit guidance on when to use this tool versus alternatives like channel_mentions or meeting_read_messages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses support for cross-team broadcasting and @mention semantics, but omits details on permissions, rate limits, error handling, or side effects if the channel doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a bullet list. Front-loaded with the primary action, then adds features and channel formats. No redundant 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?
Has an output schema, so no return value explanation needed. Covers the main action, channel formats, and mention capability. Missing behavioral context like prerequisites or error conditions, but sufficient for a simple send tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, setting baseline at 3. The description adds value by defining channel format patterns (team:<name>, project:<id>, global) with examples, and clarifying mention syntax with sample tags, which goes beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a message to a channel', specifying the action and resource. It further details cross-team broadcasting and @mention semantics, and provides explicit channel formats (team:<name>, project:<id>, global), distinguishing it from siblings like channel_read or send_notification.
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 such as cross_project_send or send_notification. The description does not specify prerequisites, restrictions, or contrasting use cases.
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, description carries full burden. Adds ordering behavior and detailed status caveat (e.g., 'running' only matches pre-v1.6.2 rows). Read-only nature implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is highly concise and front-loaded with key action, ordering, and filter option. No unnecessary 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?
Sufficient for a simple list tool with output schema. Missing explicit read-only declaration and usage context against similar sibling tools, but otherwise 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?
Schema coverage is 100%, so baseline 3. Description adds no extra meaning beyond schema; the status filter is summarized but schema already provides detailed parameter 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?
Clearly states it lists deep-reviews with ordering (newest-first) and optional status filter. Distinguishes from siblings like ecosystem_deep_review_request and ecosystem_deep_review_status.
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 (e.g., ecosystem_deep_review_status, ecosystem_search, summary tools). Only describes basic functionality without usage context.
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?
The description mentions the 'supersedes' parameter behavior (old memo marked invalid) which adds behavioral context beyond the schema. However, it does not disclose potential side effects on the task, required permissions, rate limits, or output details. Since no annotations exist, the burden is partially met but incomplete.
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, well-structured sentence that is action-oriented and front-loaded with the tool's purpose. No wasted words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter coverage, the description is largely complete for a simple 'add' operation. However, it lacks guidance on when to use this tool over sibling tools like memory_add or decision_log, which would improve 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?
All five parameters have detailed descriptions in the schema (100% coverage), so the tool description adds little extra meaning beyond the overarching purpose. The description's mention of use cases aligns with the memo_type parameter but does not deepen understanding of individual 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 verb 'Add' and resource 'memo record to a task', and lists specific use cases (tracking progress, recording decisions, marking issues). This distinguishes it from sibling tools like memory_add (general memory) or decision_log (logging decisions).
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 provides clear contexts for using the tool (progress tracking, decision recording, issue marking), but does not explicitly state when not to use it or suggest alternatives. No exclusions or when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Describes the debate structure but lacks details on side effects (e.g., creation of debate session, persistence), permissions, or output specifics. Output schema exists but is not elaborated in the description.
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?
Extremely concise, front-loaded with purpose, and uses bullet points for clarity. Every sentence adds value.
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?
Explains the debate process but omits details like error handling, prerequisites, or result format. Given the presence of an output schema, the description is adequate but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate parameter descriptions. The description adds minimal extra context (e.g., default roles) but does not significantly enhance understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it starts a debate-style code review for a specific file/change, detailing the 4-round structure with defined roles (advocate, critic, judge). Distinguishes from sibling 'debate_start' by specifying code review context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (for code review) and the process. Does not mention when not to use or alternatives, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool performs validation (checks for architecture_done reviews), produces a suggested payload, and does not itself start the debate (explicitly notes Leader still calls debate_start). This sets clear expectations about side effects — that nothing is written until debate_start and ecosystem_link_debate_meeting are called. Missing: no mention of what happens on validation failure (does it error, return partial payload?), but the core behavior is well disclosed.
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 reasonably compact for the complexity involved — three sentences covering purpose, validation, and follow-up sequence. The title line 'Stage 2' adds orchestration context. Could be tightened: the inline code formatting and follow-up sentence could be combined, but the structure is effective and front-loads the key 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?
This is a relatively complex staged tool (validate → build payload → hand off to debate_start → link meeting). The description captures the orchestration flow well and references the output schema (payload with topic + roles + review_ids). With an output schema present and 100% parameter coverage, the description adequately rounds out the picture. Missing: error/validation-failure behavior and what happens if a repo lacks architecture_done — whether it's skipped or errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all 5 parameters thoroughly. The description does add context: it clarifies the parameters are 'suggested' and 'overridable at debate_start' for the judge/critic/advocate roles, and notes repo_ids are finalists selected from Stage 1. However, the description doesn't explain format constraints (e.g., repo_id format) or how research_goal influences topic generation beyond what the schema states. Baseline 3 is appropriate given full 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 it builds a debate dispatch payload, validates architecture_done reviews, and returns a payload for the caller to invoke debate_start. Verb+resource are specific and it distinguishes itself from debate_start (which it explicitly delegates to) and ecosystem_link_debate_meeting (which it names as the follow-up). Slight deduction because the core purpose — 'build a debate dispatch payload' — could be clearer about what debate dispatch means, but the follow-up sentences explain the mechanics.
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 validates repo_ids have architecture_done reviews, then returns a payload for the caller to invoke debate_start. It also explicitly names the sequential relationship — first debate_start, then ecosystem_link_debate_meeting. This gives good when-to-use guidance distinguishing it from sibling tools. Deduction for not explicitly stating when NOT to use it or listing alternative dispatch paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses undirected traversal semantics, depth cap (<=2 via 'depth <= 2'), and that both limit and depth constrain results. It does not mention cost, performance implications, or what happens when limits are exceeded, though the output schema helps. The 'reference neighborhood' framing plus depth/limit bounds gives reasonable behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two short sentences plus a two-line example block, front-loading the core semantic ('Trace the reference neighborhood of an object'). The examples earn their place by clarifying intent. Minor inefficiency: the depth constraint '<= 2' is repeated in the description and in the depth param default, but overall the structure is clean and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (4 params, 6 seed kinds, bidirectional graph traversal) but benefits from a complete schema and an output schema. The description covers traversal semantics, depth limits, and motivating examples. It does not document edge cases like disconnected seeds or what the output JSON shape contains, but the presence of an output schema mitigates that gap. Adequate for the complexity level.
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 each parameter (kind, id, depth, limit) has a clear description in the schema itself, establishing a baseline of 3. The description adds context around what kinds of ids are valid across entity types ('a uuid for task/report/memo, a run id like wf_cbad7348, a commit sha') via the schema. The description itself adds minimal parameter meaning beyond what the schema already documents.
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 traces the reference neighborhood of an object using an undirected fanout up to depth 2. It provides concrete example queries ('which tasks/reports touched commit 9d8f020') that make the purpose vivid and unambiguous. This distinguishes it from siblings like unified_search (topic-based) and task_execution_trace (linear execution path).
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 tool purpose implies when to use it (exploration of connected objects around a seed), and the examples clarify intended scenarios like recent-work or commit relationships. However, it does not state when NOT to use it or explicitly name alternative tools, such as unified_search for keyword lookups or memory_search for semantic searches. The guidance is 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?
No annotations provided, so description carries full burden. It only says 'Update meeting fields' without disclosing any behavioral traits such as immediate effect, required permissions, or whether updates are reversible. Lacks transparency 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?
Two sentences conveying essential information. First sentence states the resource and fields; second provides usage guidance and alternative tool. Extremely concise with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (update fields), the description covers purpose and usage. However, lacks behavioral transparency and does not mention any preconditions or side effects. Output schema exists, so return value details are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds little beyond what is in the schema (e.g., 'add conclusions/notes' is already in the notes parameter description). 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?
Description clearly states the verb 'Update' and the resource 'meeting fields' (topic, participants, notes). It distinguishes from sibling 'meeting_conclude' by explicitly stating that concluding should use a different tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'add conclusions/notes to a meeting or update its topic'. Also gives a clear when-not-to-use: 'To formally conclude a meeting... use meeting_conclude instead', pointing to the appropriate alternative.
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 partially fills the gap by stating the return format (list of projects with fields). However, it omits details like whether the list is ordered, paginated, or if any rate limits or authentication requirements exist. The description is minimal but not misleading.
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: two sentences with no redundant information. The purpose is front-loaded, and the return fields are clearly listed. Every word is earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, the existence of an output schema, and the simplicity of the tool, the description is fully complete. It covers what the tool returns and does not require additional context.
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?
There are zero parameters, so schema coverage is 100%. Per guidelines, the baseline for 0 params is 4. The description adds no parameter information because none is needed, but it does not detract from understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all projects in the system' with a precise verb and resource. It specifies the return fields (id, name, description, root_path, etc.), leaving no ambiguity about the tool's function. The name itself distinguishes it from sibling list tools for other entities.
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 other list tools. There are no exclusions, prerequisites, or context hints beyond the basic purpose. The agent must infer usage solely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It transparently discloses the tool's history (task_replay fold-in, 2026-07-27) and the behavioral difference of include_stats. However, it doesn't disclose what happens on invalid/missing task_id, whether this is read-only versus potentially expensive, or output characteristics beyond the derived summary distinction.
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?
Efficient and well-structured: a lead sentence stating the core function, then a compact historical note explaining the merge. No wasted words; the tool-fold history is genuinely useful for agents that might remember task_replay.
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?
There's an output schema present, so return-value explanation isn't required. For a two-param read tool with full schema coverage, the description adequately covers behavior. Minor gap: no note about failure modes or performance for stats computation, but this is a fairly complete description for a filtered read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both params. Still, the description adds real value by explaining include_stats in plain terms (the old replay view) and clarifying the distinction between timeline-only versus checkpoints+stats. The chronological memo/lifecycle-event detail goes beyond the schema's terse boolean 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?
Clear verb+resource: 'Get a task's execution timeline' with the choice of plain vs checkpoints+stats. It's identifiable against siblings like task_status or task_run, though it doesn't explicitly name a distinguishing alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the plain-timeline vs include_stats distinction well. It doesn't explicitly name sibling alternatives to use instead ('when not to use this'), but the use-case framing around 'how did this task actually go' is clear. Notably it folds in task_replay history, which helps an agent understand the consolidation.
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 of behavioral disclosure. It identifies the operation as read-only (implied), but does not mention potential side effects, authentication requirements, rate limits, or return characteristics such as ordering or pagination. A more detailed disclosure would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of one sentence that front-loads the action and purpose. It is efficient with no wasted words, though a slightly more structured format could improve clarity.
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 (one required parameter, output schema present), the description is largely adequate. It covers the core functionality and use case. However, it omits details such as the format of returned data (though the output schema fills this gap) and any limitations on volume, which would enhance 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 has 100% coverage with one parameter 'task_id' described as 'Task ID'. The description adds meaning by explaining why the tool is used (progress understanding), but does not add semantic detail beyond what the schema provides. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads all memo records for a task, using a specific verb ('Read') and resource ('memo records for a task'). It distinguishes itself from the sibling tool 'task_memo_add' which writes memos, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool ('read before picking up a task to understand historical progress'). It does not, however, mention when not to use it or offer alternative tools, which would strengthen the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Lists three checks but doesn't disclose whether the tool has side effects (likely read-only) or what happens on failure. Output schema exists but behavioral details are partially inferred.
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?
Well-structured with bullet points and usage note. Concise at ~50 words, though the phrase 'task_memo_add' could be clarified as a tool reference.
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 one parameter and existing output schema, description covers purpose, checks, and usage timing. Minor gap: no mention of return value or error handling, but partially mitigated by output 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?
Schema coverage is 100% with param description 'Task ID to verify'. Description adds no additional semantics beyond what schema provides, so baseline score 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?
Description clearly states the tool verifies task completion with specific checks, distinguishing it from sibling tools like task_status or task_memo_read which query but don't verify completeness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this after an agent reports completion' providing clear usage context. Could be improved by specifying when not to use (e.g., before completion) or mentioning alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive behavioral detail beyond what annotations (none exist) and schema offer. It explains the default compact projection, field omissions, detailed size example (268,753 chars), and how agent rows are trimmed. It also clarifies that the compact view retains scalar data and excerpts results, and explains the relationship between planned_agent_count and dynamic_nodes. No annotations are provided, so the description fully carries the burden.
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 informative but somewhat lengthy (over 600 characters). It front-loads the main purpose in the first line, which is good, but subsequent details about size examples and field interpretations could be more tightly organized. Some redundancy exists between the description and schema (e.g., mentioning 'compact' default), but the extra context is valuable enough to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters including a view selector, boolean toggle, and size limit), the output schema exists, and annotations are absent, the description provides robust context about behavior and edge cases (large runs, field projection logic). It explains how to interpret response fields like dynamic_nodes, which is not in the schema. However, it does not mention error handling or permission requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 4 parameters described in schema). The description adds value by explaining how parameters like fields=compact work in practice (what gets trimmed, example sizes) and how include_agents relates to the compact view's projections. However, it does not describe the limit parameter's effect beyond what schema already states, but overall it deepens understanding significantly.
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 explicitly states the tool retrieves a workflow run's archive including totals, summary/result, and per-agent telemetry. It clearly distinguishes the 'compact' view from the full archive, though the sibling list includes workflow_list which lists runs, not retrieving their data, so there is no direct sibling confusion.
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 explains when to use the compact view versus the full archive, and discusses how to interpret planned_agent_count and dynamic_nodes. However, it does not explicitly state when to use this tool vs alternatives in the sibling list, nor does it mention preconditions or fallback options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It states the state change and that the prompt won't reappear, but doesn't mention reversibility or side effects. Adequate for a simple toggle.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear verb-object structure. No wasted words. Front-loaded with action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one optional parameter and an output schema. Description sufficiently covers purpose and effect. Could mention if dismissal can be undone, but not critical.
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 already fully describes the only parameter (cwd) with default and explanation. Description does not add further meaning beyond schema, hitting 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?
Description clearly states the action: marking current cwd as dismissed for project registration. It distinguishes itself from siblings by being project-registration-specific, unlike briefing_dismiss or ecosystem_clear_manual_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool is straightforward: call to dismiss registration prompt for cwd. The phrase 'won't ask again' makes its effect clear. No explicit when-not-to-use, but simplicity implies only use when dismissal is desired.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral effects: it writes specific fields (quality_score, quality_notes, reviewed_by, reviewed_at) and clears claimed_by to allow other workers to pick up the next row. With no annotations provided, this provides sufficient transparency for a simple update 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 two sentences with no unnecessary words. The first sentence states the high-level purpose, and the second provides specific details about the fields and lock release. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema (context indicates present), the description does not need to explain return values. It covers the essential behavioral effects and side effects. It does not mention error conditions or idempotency, but for a straightforward update tool, it is largely 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?
Schema description coverage is 100%, so baseline is 3. The description mentions some fields (quality_score, quality_notes) that are parameters, but adds minimal additional meaning beyond the schema. It also mentions reviewed_by and reviewed_at, which are not input parameters, potentially causing confusion.
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 'Submit quality review result and release the claim lock', which specifies the verb (submit/release) and the resource (quality review/claim lock). It distinguishes from siblings like ecosystem_claim_review (which claims) and ecosystem_release_claim (which only releases) by combining both actions.
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?
While the description implies the tool is used after a review is completed and to release the lock, it does not explicitly state when to use it versus alternatives (e.g., using ecosystem_release_claim instead if no review submission is needed) or mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates that the tool 'claims' a repo, implying a state change (marking it as claimed), and returns the shallow_summary. However, it does not explain side effects in detail (e.g., whether the claim is blocking, expiration, or required permissions). The return value is mentioned, but deeper behavioral traits are absent.
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: two sentences that front-load the action and follow with necessary context. Every sentence serves a purpose, no fluff. It is efficient for an AI agent to parse.
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 presence of an output schema (not shown but indicated), the description need not detail return values beyond mentioning shallow_summary. It explains the filtering logic clearly. However, it could be improved by noting any prerequisites (e.g., worker registration) or what happens if no matching repo exists. Overall, it is fairly complete for a claim tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (worker_id, min_stars) already described in the schema. The description does not add additional meaning beyond what the schema provides. According to guidelines, baseline is 3 for high coverage, and no extra parameter insight is given.
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: 'Claim the next shallow_done repo for quality review.' It specifies the action (claim), the resource (shallow_done repo), and the context (quality review). The additional details about filtering criteria differentiate it from sibling tools like ecosystem_claim_shallow, which likely handles shallow scanning claims.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: when a repo is in 'shallow_done' status with no quality_score and no active claim. It gives clear context but does not explicitly state when not to use it or mention alternative tools. However, the specificity is sufficient for an agent to understand the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It mentions that the diff is computed dynamically from the event log (v1.6.0 event sourcing), which implies a read-only operation and provides version context. However, it does not address potential side effects, performance implications, or data freshness guarantees, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: first states the main action, second describes the output, and third provides context (replacing legacy). Every sentence adds value with no unnecessary words, and the structure is front-loaded with the core 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?
The description explains the output (summary counts by event type) and differentiates from the legacy approach, which is sufficient given the existence of an output schema. However, it could mention edge cases (e.g., empty result) or performance notes, but overall it is complete enough for a diff tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (from_date, to_date) described in the schema as YYYY-MM-DD inclusive. The description does not add additional semantics beyond what the schema provides, so it meets the baseline without improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a time-period diff computed dynamically from the event log, grouping events by type (new repos, topics, stars, status). It uses a specific verb (return) and resource (diff), and distinguishes itself from the legacy index_diff snapshot approach.
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 by stating it replaces the legacy index_diff snapshot approach, implying it is the preferred method for dynamic diffs. However, it does not explicitly state when to use this tool versus other ecosystem tools like ecosystem_summary_* or ecosystem_repo_events.
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 of behavioral disclosure. It reveals that the tool adds a tag and advances state, and that the repo becomes highlighted in searches. However, it omits details about reversibility, permissions, side effects for other tags or statuses, and whether the operation is idempotent. More behavioral context would improve 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 extremely concise and front-loaded. It opens with the core action ('Stage 3 reference path — add lifecycle:reference tag + advance to referenced') and follows with usage guidance in a single compact paragraph. Every sentence earns its place without fluff.
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?
Considering the tool has 3 parameters, an output schema, and a clear domain context, the description is reasonably complete. It explains the lifecycle stage, the decision trigger, and the user-visible effect. It does not mention the output schema, but that is acceptable since the schema itself conveys that. Minor gaps in behavioral details lower the score below a 5.
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 all three parameters (agent_id, confidence, deep_review_id) with descriptions, achieving 100% coverage. The tool description does not add any additional meaning or guidance beyond the schema, 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 clearly states the tool's action: mark a repo as a reference by adding a lifecycle tag and advancing its state. It distinguishes itself from sibling tools like ecosystem_mark_no_value by specifying the 'Stage 3 reference path' and the condition 'not integrated', making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the debate concludes that the repo is worth keeping as an architectural reference but not integrated', providing clear guidance on when to use. It also explains the consequence (highlighted in searches). While it doesn't explicitly name alternative tools for when the repo is integrated, the guidance is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It clearly states the tool adds a tag, advances stage_status, and returns a ready-to-post payload. This sufficiently discloses state changes and output without contradiction.
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 compact and well-structured, with a clear purpose first, followed by action steps and a follow-up note. The Chinese line about ownership is slightly extraneous for English-agent contexts but adds important context. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (producing a payload for an external API, requiring a follow-up call), the description covers all necessary steps: what it does, what it returns, and what to do next. It also clarifies that ecosystem does not own the implementation, which is critical for correct multi-step workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds no additional detail beyond the schema for parameters; it restates the same info (e.g., 'Optional task title (auto-generated if empty)'). Thus, it meets but does not exceed expectations.
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: to build a task_create payload and tag the repo during Stage 3 integration. It explicitly names the sibling follow-up tool, setting it apart. The verb 'build' and specific actions 'adds tag', 'advances stage_status' are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool (Stage 3 integrate path) and references the next step (call ecosystem_link_integration_task). However, it does not provide explicit when-not-to-use scenarios or compare to alternatives, relying on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output format (markdown table with specific columns), sorting (stars desc), and archiving behavior (excluded unless include_archived=True). With no annotations, it provides sufficient behavioral context, though no mention of error handling for missing tags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a note, front-loaded with the main action. No unnecessary words, efficiently conveys purpose and key behaviors.
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?
Completeness is high: covers output format, sorting, archiving, and save behavior. Output schema exists so return values are covered elsewhere. Minor gap: no description of behavior for missing tag (likely returns empty table).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions. The description adds context for tag and include_archived but does not significantly expand on the schema. Baseline of 3 is appropriate given 100% 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?
Clearly states 'List every repo carrying tag as a markdown table', specifying verb and resource. Distinguishes from sibling tools like ecosystem_search_by_capability by focusing on tag-based listing with star/language/summary.
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?
Does not explicitly state when to use this tool over alternatives like ecosystem_search or ecosystem_summary_top_n. The description implies listing repos by tag but lacks comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the side effect of persisting the report via report_save when save_report=True. However, it does not specify whether the tool is read-only or the nature of any other potential 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a clear purpose followed by aggregation details and optional persistence behavior. It is front-loaded and contains no unnecessary words, though grouping related information more tightly would improve flow.
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 presence of an output schema (not shown), the description does not need to detail return values, but it does not mention error cases, prerequisites, or the nature of the markdown content beyond aggregation lists. It is adequate but not fully comprehensive for a tool with side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by explaining that save_report=True triggers report_save with report_type='ecosystem-weekly'. This goes beyond the schema. However, it does not provide additional semantics for author or top_movers_limit beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a past-N-days ecosystem briefing in markdown format, listing specific data aggregated (profiles, reviews, archive counters, top star movers). It distinguishes from sibling tools like ecosystem_summary_health or ecosystem_summary_top_n by focusing on a comprehensive weekly briefing.
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 generating ecosystem briefings over a configurable window, but does not explicitly state when to use this tool over alternatives (e.g., other ecosystem_summary tools). There is no mention of 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the tool is read-only, requires authentication, or has any side effects. The description focuses on the tagging system structure rather than the tool's behavior.
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 fairly concise at 7 sentences. The first sentence clearly states the purpose, and the bullet points organize the layers. However, the bullet list could be slightly more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (listing a dictionary of default tags) and the presence of an output schema, the description is complete. It explains what the tool returns (21 canonical tags) and provides useful context about the three-layer tagging system.
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% (both parameters have descriptions). The description adds no additional meaning beyond the schema; it only restates the tool's purpose. Baseline 3 is appropriate for high 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 states 'List ecosystem tag dictionary entries' and explains the three layers of tagging, clarifying that it returns only the canonical tag dictionary (21 default tags). It distinguishes from the sibling tool 'ecosystem_tag_apply_batch' which actually applies tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'This tool only returns the canonical tag dictionary (21 default tags). Use ecosystem_tag_apply_batch to actually apply tags to repos.' This provides clear when-to-use and when-not-to-use guidance, naming the alternative tool.
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?
There are no annotations, so the description carries full burden. It describes the 3-layer loading behavior and progressive detail levels, which is useful behavioral context. However, it does not disclose return structure, output format, or any side effects. The description does disclose the legacy migration (ecosystem_recipes content moved into integration category), which is helpful context beyond what schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear layer breakdowns and a final note about the integration category. Each sentence adds value and the progression is logical. It's slightly long but all content is load-bearing — the layer descriptions directly help the agent decide how to call the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and 100% parameter coverage, the description's job is to explain the multi-level behavior, which it does thoroughly. The 3-layer explanation, category guidance, and legacy migration note make this complete for a discovery/recommendation tool with no safety concerns. The tool has no destructive or mutating behavior implied, and all 4 parameters are mapped to use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters well. The description adds the mapping of level→parameter usage (level 1 uses task_description, level 2 uses category, level 3 uses skill_id), which adds meaning beyond raw schema. However, this mapping is implicit rather than explicitly stated as a level-to-parameter correlation table, so it adds moderate but not rich value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool finds ecosystem skills/plugins with a specific verb+resource. It breaks down the three-layer progressive loading system (quick recommend, category browse, full detail), giving strong specificity. It also distinguishes itself from the many ecosystem_* sibling tools by focusing on discoverability/recommendation rather than repo management or scanning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what each of the 3 levels is for (describe task, browse by category, get full detail) and which inputs map to which level. It doesn't explicitly say when NOT to use this vs. alternatives, but it does clarify that the integration category absorbed what used to be the ecosystem_recipes tool, which helps the agent route correctly. It provides clear context for choosing the right level, though it doesn't enumerate alternative tools to prefer.
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 adds behavioral context: force=True records a warning event. However, it does not disclose other side effects (e.g., notifications, irreversible completion) or prerequisites (e.g., meeting must be active). More transparency would be beneficial.
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: two short paragraphs with no redundant text. The first sentence immediately states the primary action, and the following sentences add essential details efficiently.
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 presence of an output schema (handling return values) and 100% parameter coverage, the description is nearly complete. It covers the key behavioral aspects (default check, force warning) but omits details like whether the meeting can be reopened or if participants are notified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description repeats some of this info (e.g., force records an event) but does not add new meaning beyond the schema. Thus scores baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Conclude a meeting, marking it as completed.' This is a specific verb-resource pair that distinguishes it from sibling tools like meeting_update or meeting_attendance_check, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default behavior (attendance check) and when to override with force=True. It does not explicitly mention alternative tools for attendance checks, but the context from siblings implies such options. The guidance is clear for basic use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral traits: optional status filter and team auto-selection. However, it does not mention ordering, pagination, or whether it lists only future meetings or all. Despite this, the context is adequate for a simple list 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, front-loaded sentence of 10 words. Every word is necessary, and there is no extraneous information. 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.
Completeness4/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 optional params, no required params, output schema exists), the description covers the main purpose and key behavioral hint (team auto-selection). It could be more specific about the time range of meetings listed, but overall it is sufficiently 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?
Schema description coverage is 100%, with both parameters fully described in the schema. The description adds no new meaning beyond 'optionally filtered by status', which is already implied by the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'meetings', and the scope 'for a team' with an optional status filter. It distinguishes this tool from sibling tools like meeting_create and meeting_update, as it is specifically for listing.
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 listing meetings but does not provide explicit guidance on when to use it versus alternatives (e.g., meeting_template_list) or when not to use it. No when-to-use or when-not-to-use conditions are mentioned.
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?
Discloses key behaviors: project isolation and automatic dashboard appearance. With no annotations, the description must cover safety and side effects; it omits whether the tool is idempotent or can overwrite existing reports.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and key behavioral context. 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?
With an output schema present, return value details are not needed. Description covers purpose and storage behavior, but could mention constraints like size limits or update capability. Mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 6 parameters with descriptions. The description adds no extra semantic meaning beyond the schema, so score is baseline 3 for high 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?
Description clearly states the tool saves a 'research/analysis report to the database', with a specific verb and resource. Among sibling tools like 'report_list' and 'report_read', this uniquely identifies the save operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use: reports are stored with project isolation, require no filesystem permissions, and automatically appear on the Dashboard. However, it does not explicitly exclude alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions task scope and visibility but omits side effects (e.g., triggers, notifications) and authorization needs. The presence of an output schema mitigates return value ambiguity, but the description could add more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no redundant information. Every sentence earns its place, making it highly efficient for an AI agent to parse quickly.
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 complexity (8 parameters, 1 required) and the presence of an output schema, the description covers the essential purpose and context (project-level, planning-phase). However, it could be more complete by explaining post-creation behavior and how this tool relates to siblings like task_run or task_auto_match. Still, it is fairly 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond what the schema provides, except for noting that task_type is deprecated and suggesting an alternative (CC Workflow). This is useful but does not significantly raise the score above 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 verb (create), resource (task in project), and distinguishes from team-level tasks. It also explains the context (visible on project task wall) and suitability for planning-phase tasks, making it easy for an agent to select this tool over siblings.
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 suggests using this tool for planning-phase tasks not assigned to a team, providing clear usage context. However, it does not explicitly mention when not to use it or name alternative tools for team projects, which would further improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an exceptional job. It discloses the compact projection is a trimmed view not missing data, explains that offline agents are terminated processes that cannot be messaged or assigned work, reveals the payload-size failure history and the 96.4% offline-row statistic, and explicitly assures nothing is deleted. This is richly transparent about edge cases and consequences.
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 efficiently structured with a leading one-line purpose, then a compact-projection explanation, then offline-handling context. While dense and front-loaded, some sentences are long and packed with multiple clauses; the failure-history narrative, while valuable for transparency, adds verbosity. Still, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 6 parameters, an output schema, no annotations, and an unusual default behavior (count+digest for offline). The description thoroughly explains the compact vs all distinction, the offline folding logic, the termination implications, the payload-size failure rationale, and the include_offline escape hatch. For a tool of this complexity, the description is remarkably 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?
Schema coverage is 100%, so the schema fully documents all 6 parameters. The description adds context beyond the schema by explaining the relationship between include_offline and offline_preview (digest vs full rows) and clarifying what the compact projection omits. However, it doesn't add per-parameter syntax or format details beyond what the schema already provides, so the baseline 3 is appropriate.
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?
Clear verb+resource: 'List a team's members'. The description distinguishes compact vs full projections and explains offline member handling, which differentiates it from sibling tools like team_list, team_status, and team_briefing that operate at the team level rather than member level. However, it doesn't explicitly name the sibling it competes with, so it loses the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to request offline history ('on request'), when to use fields='all' versus compact, and how include_offline interacts with the default count+digest behavior. It provides clear conditional context though it doesn't explicitly state when NOT to use this tool or name 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 provided, the description carries the full behavioral burden. It discloses that recommendations are 'live template match against the installed template dirs' ranked by relevance, and explicitly states the team_composition layer is 'static seed, not a live probe' — this distinction between live and static behavior is genuinely valuable and goes beyond what structured data reveals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with two labeled layers, making the dual-purpose output easy to parse. The sentence explaining the static nature of team_composition is valuable but slightly verbose. Overall concise and front-loaded with the core purpose, though the layer breakdown could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be described. With 2 optional params at 100% schema coverage, the description effectively complements the schema by clarifying the output structure (two layers) and the behavioral distinction between them. Coverage is good for a moderately complex dual-output tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (keywords, task_type) already have clear descriptions with examples in the schema. The main description adds the project-type list for task_type (web-app/api-service/data-pipeline/library/refactor/bugfix), which enriches the semantic understanding. However, it doesn't describe how keywords interact with task_type or whether both can be provided together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Recommend') plus resource ('Agent templates') and adds a distinct secondary purpose (team shape for known project types). It effectively differentiates from siblings like agent_template_list (listing templates) and agent_reuse_recommend (reuse recommendations), establishing its unique job of recommending templates and team composition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when the team_composition layer applies ('when task_type names a project type') and explicitly names which project types qualify. It also clarifies that team_composition is 'a static seed, not a live probe', which tells the agent about limitations. It doesn't explicitly name alternatives or exclusions, but the two-layer breakdown gives clear context for when to use versus other recommender tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the 4-round structure and roles of Advocate, Critic, and Judge in detail, providing behavioral context. However, no annotations exist, so the description carries the full burden; it does not disclose side effects, permissions, or error conditions.
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?
Highly concise, with a clear main sentence followed by structured bullet points for the rounds. Every line adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 5 parameters and an output schema, the description covers the process and roles adequately. No gaps remain given the schema and output schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in the schema. The description adds no additional semantic information beyond the schema, meeting the baseline expectation.
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 'Start a structured 4-round debate meeting between an Advocate and a Critic,' specifying the action and resource. Differentiates from siblings like 'debate_code_review' by emphasizing structure and roles.
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?
Implies use for structured debate but lacks explicit when-to-use or when-not-to-use guidance. No alternatives mentioned, leaving usage somewhat 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?
The description reveals that the tool writes 'debate_meeting_id' onto reviews, which is a behavioral trait beyond the input schema. However, with no annotations provided, it omits details like idempotency, error handling, or whether the write is destructive. The description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: first states the purpose, second adds usage context, third explains the effect and reason. It is front-loaded and contains zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description correctly avoids explaining return values. It covers the full workflow context (the hook that uses the written data), making it self-contained for an agent to understand when and why to 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 input schema already provides 100% coverage with descriptions for both parameters. The description adds context by referencing the origin of the parameters (e.g., 'returned by debate_start'), but this does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'link debate_start meeting id back to review rows'. It specifies the action (link/write), the resource (review rows), and distinguishes itself as a 'Stage 2 helper' in the debate workflow, setting it apart from sibling tools like debate_start and ecosystem_trigger_debate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Called immediately after debate_start succeeds', providing clear when-to-use guidance. It does not explicitly exclude other contexts or mention alternatives, but the sequential dependency is well-communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool performs an incremental refresh, probes each active-set repo once, writes a status snapshot, re-queues shallow summary only for repos with new pushes, and handles 404/403 errors. It also mentions the 'hint' field in the response. This is good transparency, though it could be improved by noting potential side effects or resource usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three sentences that efficiently convey the purpose, replacement context, and workflow. It is front-loaded with the purpose. However, it could be slightly more structured (e.g., bullet points) for easier parsing, but it remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one optional parameter, output schema exists), the description covers the workflow, the response hint field, and the replacement of the weekly cron. It explains the conditions for re-queuing shallow summaries. It is complete enough for an agent to use the tool appropriately, though it could mention the effect on the ecosystem state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'notes', with a description that matches the one in the tool description. The description adds no additional meaning beyond what the schema already provides. The baseline for high coverage is 3, and no extra value is given.
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: 'On-demand incremental refresh of the project's active ecosystem set.' It specifies the verb 'refresh' and the resource 'ecosystem set', and distinguishes itself from sibling tools like ecosystem_scan, ecosystem_scan_periodic, and ecosystem_apply_shallow_summary by explaining its specific role as a trigger for subsequent shallow scans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: 'refresh happens when the user asks for it' (on-demand). It provides context about the retired weekly cron and outlines the subsequent step of running shallow scans via ultracode/Workflow. However, it does not explicitly state when not to use it or list alternative tools, so it lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It transparently discloses that this writes to the DB (update ecosystem_repo_profiles), sets needs_deep_review=True conditionally, auto-classifies heuristically, and supports a dry_run mode to avoid writes. This is honest about the mutating nature and workflow impact, though it doesn't detail destructuring of existing profiles or idempotency behavior, keeping it shy of 5.
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 structured with a clear summary sentence, a bulleted query list, and a closing behavior note. It's efficient and scannable. Slight redundancy exists between the prose explanation and the parameter schema docs for min_stars, and the query list could arguably live in the output schema or be trimmed, but overall it's well-organized without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (8-10 queries, dedup, classification, conditional flags) and has a rich output schema. The description covers the query set, filtering logic, and side-effect behaviors well. A short note on expected duration or idempotency when re-running would strengthen it, but the combination of description plus schema is nearly complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters thoroughly. The description reinforces min_stars as a popularity floor and maps values to strategy (full vs incremental), which adds some nuance. However, this largely echoes schema content; baseline 3 is correct since the description adds modest value over the schema's detailed parameter docs.
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 verb+resource action: 'Scan popular Claude ecosystem repos (>=min_stars) and update ecosystem_repo_profiles.' It clearly enumerates the 8-10 gh search queries and the filtering/dedup logic. While sibling ecosystem tools exist, this one is clearly the scanning entry point, differentiated by its concrete query list and update behavior.
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 details mechanics (queries run, thresholds, classification heuristics) without explicit when-not-to-use guidance. However, sibling names like ecosystem_scan_periodic suggest a periodic variant, and the description's threshold rules imply when to invoke (full vs incremental sweeps). It lacks explicit exclusions naming alternatives, so 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does well: it lists the exact return fields, explains the meaning of the self_learning_pending map, and even discloses the threshold behavior (a class becomes eligible once count reaches 3). This provides meaningful behavioral context beyond a simple status read.
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 reasonably concise and front-loaded with the core purpose in the first sentence. The Returns section is a slightly verbose but useful structured enumeration of output fields. Each sentence earns its place, though the prose-like Returns block could be tightened into a compact list format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only status tool with an output schema present, the description is complete. It documents the purpose, the output fields, and the non-obvious semantics of self_learning_pending. The presence of an output schema means the return-value structure is already encoded elsewhere, and the description supplements it with meaning (the threshold rule). Given the tool's simplicity, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema coverage (the schema is an empty object with additionalProperties: false). With no parameters to document, the baseline is 4 per the rubric, and the description goes further by thoroughly documenting the return value structure, effectively compensating for any ambiguity about what the tool produces. This exceeds the baseline.
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 what the tool does: 'Show Stage 0 shallow-scan queue status for the active project.' It names the specific resource (shallow-scan queue) and scope (active project). Among siblings like ecosystem_scan_status, ecosystem_summary_health, and ecosystem_repo_manual_status, it distinguishes itself by focusing specifically on the shallow-scan queue status, though it doesn't explicitly name the distinguishing sibling.
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 this is the go-to tool for checking shallow-scan queue status ('Show Stage 0 shallow-scan queue status'), which allows an agent to infer when to use it. However, it provides no explicit when-to-use/when-not-to-use guidance or exclusions vs. siblings like ecosystem_scan_status or ecosystem_summary_health, which could cover related informational needs.
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 discloses the concurrency cap (max_concurrency default 20), the token-spend rationale, and that excess repos are returned in skipped_due_to_limit (a partial/failure behavior). It also clarifies this tool only builds a plan and does not execute tagging, which is an important behavioral distinction. It could add whether results are returned synchronously or how pagination works, but core behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose in the first sentence. It adds the pipeline context and the concurrency/skip behavior in short, scannable paragraphs without redundancy. Efficient and well-structured, though a touch more detail on the skipped_due_to_limit semantics would round it out.
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 dispatch-plan tool with an output schema present and 100% parameter coverage, the description is reasonably complete. It explains the tool's role in the pipeline, how to consume launch_call.params, and the concurrency/skip behavior. It doesn't need to explain return values since an output schema exists. Some color on error handling or empty-repo-list behavior would be a marginal improvement but isn't essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (repo_ids, agent_template, max_concurrency) are well-documented in the schema itself. The description adds the cross-reference to launch_call.params and clarifies max_concurrency caps concurrency to limit token spend, which adds some value beyond the schema. However, at 100% coverage the baseline is 3, and the description doesn't dramatically enrich parameter meaning beyond what's already there.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Build a Layer 3 sub-agent dispatch plan for repos that need LLM fallback.' It distinguishes this from siblings like ecosystem_tag_apply_batch and ecosystem_tag_apply_llm_result by positioning it as the dispatch/planning step in a pipeline, and explicitly says the Leader spawns sub-agents which submit via ecosystem_tag_apply_llm_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how outputs are consumed ('Leader expected to spawn each sub-agent via Agent tool using launch_call.params') and identifies the downstream tool (ecosystem_tag_apply_llm_result) for result submission. It notes repo_ids are 'typically flagged by ecosystem_tag_apply_batch with needs_llm=True,' giving clear pipeline context, though it doesn't name explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations provided, the description carries the full burden and does so thoroughly. It discloses: unknown/missing op fields return error without blocking others, invalidate/merge on already-invalid items returns noop (idempotency), Zep invalidation semantics (doesn't delete), red-line quota limits (400字 per item, 1200/1500/300 budget by scope), and auto-refresh of last_reconcile_at after application. This is exceptionally detailed behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and well-structured with clear op-type headers, but is somewhat long. It front-loads the core purpose and dispatches mechanism, then enumerates each op type. Every sentence carries information; there is no filler. It could be slightly tightened but is reasonably efficient given the complexity it must convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex multi-op tool with five operation types, idempotency semantics, quota red-lines, and side effects (last_reconcile_at refresh). An output schema exists, so return values need not be described. Given the absence of annotations and the complexity, the description is remarkably complete — covering failure isolation, idempotency, quota limits, invalidation semantics, and state refresh.
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 'operations' parameter is described at 100% schema coverage, so baseline is 3. The description adds substantial value by documenting every op sub-field (merge, invalidate, score, promote, keep) with their exact structures and constraints, which the schema only glosses over as 'additionalProperties: true'. Since the actual sub-structure is only fully documented in the description, it genuinely compensates beyond the minimal baseline.
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 title 'memory_reconcile_apply' and description clearly state this batch-executes LLM-confirmed memory operations with deterministic, idempotent behavior. It distinguishes itself from siblings like memory_reconcile_candidates (which would generate candidates) and memory_invalidate (single-op) by being the batch-apply executor. However, the connection to 'LLM精判确认后' presumes a pipeline context 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use this tool (after LLM confirmation, batch executing operations) and details each op type with clear semantics. It notes idempotent behavior and the edge case of red-line quota enforcement for promote. However, it doesn't explicitly name alternatives or state 'do not use when X', relying on implied pipeline context rather than explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool performs a read-only reachability check on the team list endpoint and additionally reports token-attribution coverage data. The returns section explains what information is delivered (API reachability, team count, usage coverage summary, narrowest link). This is a read-only operation, and the description makes that clear by describing verification rather than modification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence stating the primary purpose, followed by an elaboration of the method and a returns section. It's moderately concise with no wasted words, though slightly verbose in the returns section listing details like 'measured / dispatched per path'.
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 this is a zero-parameter diagnostics tool with an output schema present, the description reasonably covers what it checks (API reachability, team count) and what additional data it reports (attribution coverage). The presence of an output schema means return values don't need full documentation. The description is adequate for a health-check utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description doesn't need to document parameters but instead explains what the tool examines (team list endpoint) and what it returns, which adds relevant context about the tool's internal behavior despite having no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks the health status of the AI Team OS API service by accessing the team list endpoint. It specifies the verb (check), the resource (AI Team OS API service), and the method (accessing team list endpoint), distinguishing it from siblings like team_status and team_list which check specific team/OS states.
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 (to verify API service is running normally) but does not explicitly state when not to use it or mention alternatives. For a zero-parameter diagnostics tool, the health-check purpose is fairly self-evident, but no exclusions or alternative tool comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses that it reads execution traces, compares with similar tasks, and returns suggestions. This gives good insight into internal behavior without contradicting any hidden 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?
Three concise sentences: first states purpose, second explains method, third tells when to use. No fluff, front-loaded, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown), the description adequately covers input (task_id), process (trace reading + comparison), and output (fix suggestions). It is complete for a diagnostic tool, though could mention if any prerequisites exist.
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 task_id has schema description 'ID of the failed or stuck task', which is echoed in the description ('failed or stuck task'). Schema coverage is 100%, so description adds minimal extra meaning beyond confirming the task status.
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 'auto-diagnose' and resource 'task failure', clearly distinguishing it from siblings like task_execution_trace which only reads traces. It states the tool identifies failure points and suggests fixes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when a task fails or gets stuck', providing clear guidance on when to invoke. Does not explicitly mention when not to use, but context implies it is for diagnosis rather than other task operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains effects (persist summary, advance stage, route failures) and mentions rate_limit_remaining for 403. However, missing details on idempotency, auth requirements, or consequences of repeated calls—adequate but not thorough.
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?
Well-structured with clear sections for success and failure paths. Front-loaded with main purpose. Efficient, though could slightly condense the error_kind enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the two main workflows and parameter roles. Output schema exists (not shown) so return values are covered. Lacks mention of prerequisites or whether the agent should call this directly vs. it being system-invoked—but sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value by grouping parameters into success/failure paths, explaining the role of deep_review_id, and listing valid error_kind values. This goes beyond 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?
Clear statement: 'Stage 0 worker callback: write back a shallow summary OR report a failure.' Distinguishes success and failure paths, and the name implies its role among ecosystem sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use success vs. failure path, lists valid error_kind values. Lacks explicit 'when not to use' or comparison with other ecosystem apply tools, but context from name and description suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses atomic behavior (only one worker claims) and return fields. It does not contradict any annotations (none exist). However, it omits details like authentication needs or potential side effects beyond claiming.
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 very concise, with three clear sentences. The first sentence states the core purpose, the second explains atomicity, and the third notes additional return fields. No redundant information, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description appropriately does not detail return values but mentions key fields. It covers the tool's behavior and usage context well. Some possible prerequisites (e.g., needing to be a registered worker) are not mentioned, but for a tool with one parameter, it is reasonably 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?
Schema description coverage is 100% for the single parameter 'worker_id', which is already described as 'Unique worker identifier string.' The tool description does not add any additional meaning or context beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Claim the next queued repo for shallow scanning (stage_status=queued).' This clearly indicates the verb 'Claim' and the resource 'repo' with context, distinguishing it from siblings like ecosystem_claim_review which likely claims for review.
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 guidance by noting atomicity (only one worker gets each row) and that since v1.7.0 it returns extra fields to avoid a separate ecosystem_repo_get call. This implies when it's beneficial to use, but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool creates data sources and persists a scan profile, and mentions the API endpoint. However, it omits details such as whether existing data sources are overwritten, error handling, or idempotency, leaving room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences and an API endpoint note. It is front-loaded with the core purpose and efficiently provides necessary details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (though not shown) and 4 parameters with full schema coverage. The description explains the combined setup behavior and when to use it. Missing elements include prerequisites, error conditions, and return value details, but it remains fairly complete for a wizard tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds useful context beyond the schema (e.g., 'each enabled by default' for sources, 'advanced override dict' for custom_profile, and that queries apply to all data sources). This provides meaningful guidance for parameter usage.
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 the tool is a 'one-shot ecosystem setup wizard' that creates data sources and a scan profile in one call. It clearly identifies the verb (create) and resources (data sources + scan profile), and distinguishes itself from siblings like ecosystem_data_source_create and ecosystem_scan_profile_update by combining both operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool 'when bootstrapping a fresh project to ecosystem indexing,' providing clear context. However, it does not specify when not to use it or contrast with alternative tools that handle individual steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it clears claimed_by and records reason in quality_notes. Missing details on permissions, idempotency, or error states, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. Front-loaded with purpose, then usage guidance, then effects. Ideal structure for quick comprehension.
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 and presence of an output schema, the description covers the main purpose, usage triggers, and side effects. It could mention return value or error conditions, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no new meaning beyond the schema descriptions. The reason parameter's role is implied but not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (release a worker claim without quality review), resource (worker claim), and context. It distinguishes from submitting a quality review and from sibling tools like ecosystem_claim_review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'when a worker abandons a task (timeout, error)'. Explains effect on claimed_by and quality_notes. Does not mention when not to use or alternatives, but the guidance is specific and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and explicitly discloses key behaviors: skipping recently scanned repos, applying filters, marking old repos as archived, and recording runs. It lacks detail on side effects or authorization needs, but the core behavioral traits are 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 concise: a short introductory sentence followed by four bullet points. It front-loads the purpose and each bullet adds distinct, necessary information. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, output schema exists), the description covers key behaviors and usage distinctions. The presence of an output schema relieves the need to describe return values. However, it could briefly mention the output contains scan run details, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well-described. The description adds minimal new meaning (e.g., noting 'incremental strategy' aligns with strategy param, but does not elaborate on values or usage beyond what the schema provides). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs 'incremental or full ecosystem scan' via the scanner service, establishing a specific verb and resource. It explicitly distinguishes itself from the sibling ecosystem_scan by listing four behavioral differences, making the tool's unique purpose evident.
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 contrasts this tool with ecosystem_scan via bullet points, which implicitly guides when to use it: when incremental scanning, filters, archiving, or audit logging are needed. However, it does not provide explicit examples of when not to use it or mention other alternatives beyond the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait: the default compact projection is a trimmed view (marked by view="compact" + hint), not missing data. It also transparently explains the fields="all" option for full rows and the project_id-session resolution behavior. It doesn't disclose pagination or rate limits, but the parameter schema covers offsets/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 tight, structured block of three short paragraphs with no wasted words. It front-loads the core purpose, then explains the compact projection behavior and routes to the alternative tool. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter search tool with 100% schema coverage and an output schema, the description covers the essential behavioral context: default projection mode, how to get full rows, and how to restrict to a specific project's archive. It avoids repeating schema detail. It could mention pagination implications or facet_counts behavior, but parameters already document those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents every parameter richly (limit max 200, sort options, tag_match_mode AND/OR default). Baseline 3 is appropriate. The description adds marginal value by clarifying the compact projection fields (repo/stars/lang/status + summary) and that full rows live in ecosystem_repo_get, but most parameter semantics are already in the schema itself.
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 verb+resource: 'Query ecosystem_repo_profiles archive.' It clearly names the data source (Stage E enhanced) and explains the default compact projection behavior. It distinguishes from sibling ecosystem_repo_get by explicitly naming it as the tool for retrieving a single repo's full profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when each fields mode is appropriate ('full rows here' vs pointing to ecosystem_repo_get for single-repo full profiles). It clarifies the default response is compact and that this is a trimmed view, not missing fields. It doesn't explicitly state when to use alternative search tools like ecosystem_search_by_capability or memory_search, but it does handle the primary alternative (ecosystem_repo_get) well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool generates three learning artifacts and saves them to team memory, which is a significant behavioral trait. It does not cover potential side effects on the task or rate limits, but the core behaviors are 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 concise, with a clear structure: purpose first, then usage condition, then output artifacts. Every sentence adds value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the existence of an output schema, the description adequately covers when to use it and what it produces (three artifacts). It does not explain whether repeated calls are safe or affect task status, but it is sufficient for typical use.
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?
Both parameters (task_id, team_id) are described in the input schema with 100% coverage. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes failed tasks and generates three specific artifacts (antibody, vaccine, catalyst). It uses specific verbs and resources, and distinguishes itself from siblings like 'diagnose_task_failure' by emphasizing deep failure analysis and learning artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this tool when a task permanently fails (exceeds retry limit). It does not explicitly mention when not to use it or name alternatives, but the context of deep failure analysis vs. other diagnostic tools is implied. The condition for use is clearly stated.
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?
The description provides useful behavioral context: edges are extracted automatically via zero-LLM regex from task memos and reports, and it lists the types of IDs supported (wf_id, uuid, short-hash, memory-slug). However, since no annotations are provided, the description should ideally disclose more about side effects or performance, such as whether the tool is read-only or if it triggers any background processing. The given info is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences front-loading the core purpose followed by a succinct explanation of edge extraction and supported ID types. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, 100% schema coverage, and an output schema), the description is mostly complete. It explains the source of edges and the kinds of endpoints, which is sufficient for most use cases. However, it could mention that results are paginated via the limit parameter or that direction defaults to both, but these are inferred from the schema. The output schema likely provides return structure, so the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema documents all four parameters well. The description adds value by clarifying that edges are derived from specific sources (task memos and reports) and by explaining the endpoint kinds more explicitly than the schema's descriptions. It also gives concrete examples of ID formats, which enhances understanding beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries cross-domain reference edges for an object, specifying both inbound and outbound directions. The verb 'query' and resource 'cross-domain reference edges' are specific, and the tool distinguishes itself from siblings like 'link_trace' and 'unified_search' by focusing on automatically extracted edges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: to find references to or from an object. It also specifies that edges are extracted automatically from task memos and reports, setting context for appropriate usage. However, it does not explicitly state when not to use it or compare directly to siblings like 'link_trace' or 'unified_search', which may have overlapping functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions getting messages for a specific agent and the agent_name parameter default, but does not disclose ordering, pagination, time range, or error handling. Behavior is partially 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?
A single, well-structured sentence that front-loads the key action and resource. No unnecessary words or repetition; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values need not be described) and the tool is straightforward, the description adequately covers what the tool does without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the agent_name default behavior ('leave empty to use current agent') and that limit controls maximum messages. It enhances the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and resource 'channel messages' with a specific qualifier 'that @mention a specific agent'. It precisely defines the tool's function and distinguishes it from sibling tools like channel_read.
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 implies when to use (to get mention messages) but does not explicitly state when not to use or provide alternative tools. While the context is clear, it lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It reveals constraints (non-empty fields, enum values) and the intended state transition ('advance to debated'). However, it does not describe side effects, authorization requirements, error conditions, or what happens on success/failure. This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just two sentences. The first sentence states the core purpose, and the second provides critical usage notes. Every phrase adds value; there is no fluff or redundancy. It is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter descriptions, the description provides all necessary context: the tool's role in a multi-stage process, required constraints, and enum options. It is sufficiently complete for an agent to understand how and when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline descriptions for all 6 parameters. The description adds value by clarifying operational constraints: at least one of risks_md, learnings_md, integration_md must be non-empty, and integration_recommendation is an enum with specific values. This supplements the schema beyond mere descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Stage 2 writeback — submit debate conclusion to advance to debated.' It uses a specific verb ('submit') and resource ('debate conclusion'), and implies a state transition. This distinguishes it from sibling tools like ecosystem_apply_architecture_md, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a usage constraint: 'At least one of risks_md / learnings_md / integration_md must be non-empty.' It also notes the enum values for integration_recommendation. However, it does not give guidance on when to use this tool over alternatives like other ecosystem_apply_* tools, missing an opportunity for stronger differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure, and it delivers richly. It details the full pipeline, the config sources (min_stars gate, focus_topics, alert_max_new_per_scan), and explicitly states which tables are touched when dry_run=False vs. untouched when dry_run=True, citing BUG #6/#8 fix and a test name. This is exemplary transparency for a state-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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and then provides dense technical detail. While every sentence earns its place (config, pipeline, dry_run semantics, test reference), it is fairly long and includes somewhat esoteric details like BUG #6/#8 reference numbers that a typical agent user may not need.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which relieves the need to explain return values), the description is exceptionally complete for a complex tool with zero annotations. It explains config sources, the full pipeline order, the dry_run guardrails, which tables are written, and even provides a verification test reference. This leaves no ambiguity about behavior.
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 single dry_run parameter is fully described in both the schema and the description. The description reinforces the semantics ('simulate... return diff preview' vs 'persist profile upserts'). Baseline 3 is correct since the schema already documents the parameter thoroughly and the description adds only modest reinforcement.
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 ('Trigger ecosystem index update — runs scanner + computes diff') with a specific verb and resource. It distinguishes itself from siblings like ecosystem_scan by explicitly describing the full pipeline (gh search → classify → diff → alert → persist), which differentiates index_update from the raw scan tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the operational context: scan config comes from project ecosystem settings, and explicitly documents the dry_run behavior (default True = simulate, False = persist). It clearly states when writes happen vs. when they don't, though it doesn't explicitly name alternative tools to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the tool scans discovered_via_queries across profiles and aggregates counts, disclosing its read-only behavior and purpose. It does not mention performance impacts but is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three purpose-driven sentences, front-loaded with the main action, and no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It adequately covers what the tool does, the source data, and the aggregation, making it complete for agent selection.
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?
There is only one optional parameter (project_id) with schema description coverage at 100%. The description does not add additional meaning beyond the schema, meeting 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 tool returns a recap of search queries that discovered repos, aggregates counts, and is useful for auditing query productivity. It distinguishes itself from siblings by its specific function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is useful for auditing query productivity, providing clear usage context. It does not explicitly exclude alternative tools, but the niche function makes it obvious.
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 discloses the return structure: associations with confidence, source layer (github_topic / auto_rule / auto_llm / manual), and tag metadata. No mention of permissions or side effects, but as a read operation, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states purpose, second describes output. Front-loaded and highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, full schema coverage, and an output schema present, the description is complete. It explains purpose and return format with no missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (repo_id) with schema description 'EcosystemRepoProfile.id.' The tool description adds 'single ecosystem repo' context, but the schema already explains the parameter. With 100% schema coverage, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all tags currently associated with a single ecosystem repo.' This specifies the verb (list), resource (tags), and scope (single repo), distinguishing it from sibling tools like ecosystem_tag_list which likely list tags across repos.
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?
Usage context is clear: it lists tags for one repo. However, no explicit guidance on when to use this vs alternatives like ecosystem_tag_list, nor any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral transparency. It details the two-layer tagging process, confidence values, the effect of replace_auto (deleting existing tags of certain sources), and the needs_llm flag. It does not cover authentication, rate limits, or error handling, but for a mutation tool this is a solid disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose and several informative paragraphs. Each sentence adds value, explaining layers, fallback behavior, and usage context. It is not overly verbose, though it could be slightly more concise; overall it is appropriate for the tool's complexity.
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 five parameters, no annotations, and an output schema (assumed), the description provides sufficient context for effective tool invocation. It covers input behavior, processing logic, and follow-up actions. It does not mention return values, but the output schema likely covers that. It is complete enough for an agent to decide when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter description coverage. The description adds meaning beyond the schema by explaining how the layers work together, the confidence levels, and the interplay between repo_ids and repo_full_names. It also clarifies the flagging mechanism for LLM dispatch, enhancing semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies "Layer 1 + Layer 2 auto-tagging to a batch of ecosystem repos," specifying two layers with confidence levels and sources. It distinguishes from siblings by focusing on batch processing and tagging, contrasting with other ecosystem tools like single-repo operations or LLM-based tagging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (batch auto-tagging) and provides an explicit alternative: repos with fewer than 2 matched tags should be passed to ecosystem_tag_dispatch_llm. It also clarifies behavior when both repo lists are empty. However, it does not explicitly state when not to use it, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 clearly discloses the deprecation warning behavior for legacy string participants and the difference in output (empty launch_call vs fully populated). It also adds context that team_name is deprecated and ignored by the CC Agent, clarifying a behavioral quirk. This is meaningful behavioral transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence stating purpose, then a compact two-bullet format breakdown. Every sentence adds value; there's no filler. It's slightly longer than minimal but the format examples justify the length given the complexity of the participants parameter. Not a 5 because it could be tightened slightly, but it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 params, an output schema, and no annotations, so the description must carry significant weight. It covers both input formats in depth, explains the output dispatch_plan difference, and clarifies the deprecated team_name field. The presence of an output schema means return-value documentation isn't needed in text. This is reasonably complete for a moderately complex tool, though it doesn't mention behaviors like required rounds count, meeting validation, or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all 7 parameters. However, the description adds real value by explaining the participants parameter's two accepted formats with concrete examples, showing the structure of structured dicts (name, agent_template, role, context_files, expected_output) and what each produces. It also clarifies the team_name deprecation. This goes beyond the generic 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 ('Create') plus resource ('team meeting') and clearly states the outputs: a dispatch_plan and an Agent tool launch_call. It distinguishes itself from sibling tools by explicitly covering the two participant formats (legacy strings vs structured dicts), which no sibling description implies.
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 clearly explains when to use structured vs legacy participant formats and what each returns, giving practical guidance on format selection. It doesn't explicitly name alternatives or state 'use this when X' exclusions, but the format guidance plus the sibling set (meeting_send_message, meeting_conclude, meeting_update) provides adequate context. No explicit when-not-to-use guidance, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adds significant behavioral context: data source origin, default filtering (valid entries), grouping by kind order, and time ordering. Discloses read-only nature implicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences in English followed by Chinese explanation, both concise and informative. Front-loads core purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema existence, description fully covers purpose, behavior (grouping, ordering, filtering), and data source. Provides enough context 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?
Schema covers both parameters (100% coverage). Description adds context about default behavior (valid entries) and grouping, but does not significantly enhance individual parameter semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists direction-layer memories, valid by default, grouped by kind, and specifies scope (global/user/project) and ordering. Distinguishes itself from siblings like memory_add or memory_search.
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?
States the tool is used to review 'what the agent will inherit', providing clear usage context. While no explicit alternatives or when-not-to-use are given, the purpose is well-defined.
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, description carries full burden. It discloses aggregation of activity records to compute success rate, average duration, top failure reasons, and associated failure alchemy lessons. Does not mention data freshness or performance, but is transparent about computed outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise paragraphs: first states purpose, second lists computed statistics, third gives usage guidance. Well-structured 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single optional parameter and an output schema, the description provides sufficient context for an agent to understand what the tool does without needing additional details about return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already well-documented in the schema. The tool description adds no additional parameter context beyond what the schema provides, resulting in baseline score 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?
Description clearly states 'Return effectiveness statistics for Agent templates' with specific verb and resource. It distinguishes from siblings like agent_activity_query (raw activity) and agent_template_list (list templates) by focusing on computed statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to identify which Agent templates perform well and which need prompt improvement.' Provides clear context for when to use, though doesn't explicitly mention when not to use or name 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 provided, the description carries full burden. It discloses that the tool returns reports filtered and sorted, and operates within the current project context. It does not explicitly state it is read-only, but the 'list' verb implies non-destructive behavior. The description adds value beyond the schema by explaining sorting and scoping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and filters, then details about sorting. No extraneous words; every sentence adds value. It is appropriately concise for a list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the input schema covers all parameters and an output schema exists, the description provides necessary context: scope (current project), sorting (newest-first), and optional filters. It is complete for a straightforward listing tool with no additional behavioral complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters. The description redundantly mentions filter options (author, topic, type) but does not add new details beyond the schema. For parameters with schema descriptions, the tool description adds marginal value, meeting 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 clearly states the verb 'list' and resource 'saved reports', with optional filters by author, topic, or type. This distinguishes it from sibling tools like report_read (for single report content) and report_save (for creation). The purpose 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (to list reports with optional filters) and implicitly separates it from other list tools via the resource. However, it lacks explicit guidance on when not to use it (e.g., for reading a specific report) or mention of alternative tools like report_read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers richly: it discloses the historical misnomer, that values were previously silently dropped, that priority/horizon are honored now (fixed 2026-07-27), and that the tool only creates a row, never executes. This goes well beyond what annotations would have covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with three focused paragraphs: what it does, what it doesn't do, and why the name/behavior is the way it is. The history note is slightly verbose for a tool description but earns its place by preventing callers from assuming execution behavior. Slightly long but efficiently organized.
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 9-parameter task-creation tool with full schema coverage and an output schema, the description covers the critical gaps: it clarifies the no-execution behavior, dispatch responsibility, memo feedback loop, and priority/horizon semantics. It doesn't enumerate every parameter (schema does that), and the output schema presumably describes return values. Reasonably complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all 9 parameters. The description adds context that priority and horizon 'drive the task wall's ordering' — valuable behavioral framing beyond the schema's enum strings. However, it doesn't elaborate on tags, depends_on, assigned_to, or model semantics; baseline 3 is appropriate with full 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 tool 'puts a task on a team's wall' and explicitly clarifies it does NOT execute tasks — distinct from what the historical name implies. It effectively distinguishes from task_create/task_update siblings by framing this as wall-posting with separate dispatch, though it doesn't name an alternative tool directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when this tool is appropriate: it creates the wall row only, dispatch is left to the caller via Agent(...) / SendMessage, and progress is written back via task_memo_add. It explicitly warns that nothing executes the task and an Agent must pick it up, which is valuable exclusions guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes three retrieval arms, RRF fusion (k=60), and Chinese bigram native, adding significant behavioral context beyond the schema. However, lacks mention of read-only nature, rate limits, or result ordering. With no annotations, this is a strong but not exhaustive disclosure.
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?
Two paragraphs with front-loaded purpose and clear technical details. Slightly verbose with algorithm specifics but no wasted sentences; structure supports understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers scope, retrieval method, and usage examples. With an output schema present, missing pagination details are acceptable. Still could mention result format briefly, but overall adequate for a complex search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description reinforces with examples (queries like 'wf_d01f207f') and explains the fusion logic, adding value over the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Search across all OS knowledge: task memos, reports, and tasks.' clearly defining scope and distinguishing it from sibling tools like ecosystem_search, memory_search, and pattern_search by being a general unified search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to recall past work' with concrete examples, but does not state when to avoid using it or compare directly to alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the scan path, ingests telemetry, and states idempotency and safety to re-run, offering good behavioral insight beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear paragraphs: first states purpose and when to use, second details behavior and parameters. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, return values are covered. The description covers scan scope, idempotency, and file path, making it complete for a reconciliation tool with two optional parameters.
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%, providing clear parameter descriptions. The description adds context about scanning file paths and ingesting telemetry but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'reconcile' and the resource 'finished Workflow runs' with context 'from disk into the OS'. It distinguishes itself from sibling tools like workflow_get and workflow_list by specifying a repair function after OS offline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions 'repair after OS was offline', providing a clear when-to-use scenario. It does not explicitly mention when not to use or list alternatives, but the context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full behavioral burden. It communicates what this tool does (adds to a review queue for the user) and its underlying purpose/motivation. While it doesn't explicitly state side effects like whether items are persisted long-term or how they get resolved, the 'for user review' framing and the note about decisions 'never actually received' provide meaningful behavioral context about the tool's role in the decision workflow.
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 compact — roughly 4 sentences that each earn their place. Front-loaded with the core action ('Add a decision item'), followed by concrete use cases, then a compelling operational rationale. No wasted prose or repetition of schema content.
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 6-parameter tool with an output schema and 100% schema coverage, the description is nearly complete. It explains the purpose, triggers, examples, and the failure mode it prevents. Minor gap: doesn't clarify the relationship between this tool and briefing_list/resolve/dismiss lifecycle, but the sibling differentiation is adequately handled through purpose and usage guidance. The description is complete enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all 6 parameters fully documented in the input schema itself: title, description, options, recommendation, urgency, tags. The description doesn't add parameter-specific detail beyond the schema, which is acceptable given full coverage. The baseline of 3 applies since the schema does the heavy lifting; no additional parameter nuance is provided in the description but none is strictly needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb+resource: 'Add a decision item to Leader Briefing for user review.' It goes beyond and specifies the exact use case (project direction, architecture, budget, allocation) and even explains why this matters — 'a decision parked in report prose is a decision the user never actually received.' This strongly distinguishes it from siblings like briefing_list, briefing_resolve, briefing_dismiss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Use when Leader encounters decisions that require user input') with concrete examples (project direction, architecture choices, budget/resource allocation). It also gives clear exclusionary framing — anything a sub-agent leaves 'for the user to decide' belongs here — and contrasts with what should NOT happen (decisions parked in report prose). This is highly actionable for an agent deciding between this and related briefing/dismiss/resolve tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently explains the multi-team behavior — that a project routinely has several teams simultaneously (session container team plus one per Workflow run) — and clarifies the 3-tier priority resolution for the singular 'team' field. This is meaningful behavioral context beyond a generic read.
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?
Well-structured and front-loaded. The first sentence states the core purpose, followed by the infrastructure rationale, then clarifies the important teams vs team distinction, and ends with a concise return summary. Every paragraph earns its place 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?
Given the tool has an output schema, the description doesn't need to enumerate return values in detail. It's a read-only context retrieval tool with no parameters, and the description adequately handles the one subtle behavioral nuance (multi-team vs singular team) that could confuse callers. The role as infrastructure is well explained.
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 0 parameters with 100% schema coverage, so the baseline is 4 per the rubric. The description confirms it takes no parameters and describes the return structure (Context dict with project/team/teams/agents), adding value about what the caller should expect.
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 gets the current active OS context including active project, teams, and member list. It distinguishes itself by establishing itself as 'the infrastructure for all simplified operations' and explains its role in auto-filling parameters for other tools, which differentiates it from siblings.
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 clearly explains when to use this tool — as a first call to establish context before using simplified operations. It explains that other tools (like Leader) use it to auto-fill parameters. However, it doesn't explicitly state when NOT to use it or name alternatives, though the value proposition is clear enough given its foundational role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavioral traits: it advances stage_status to shallow_failed, derives status to failed, adds a cancellation note, and explains sub-agent behavior. This covers all necessary transparency beyond what annotations would provide.
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?
Description is brief (4 lines), front-loaded with the primary action, and every sentence adds value (state condition, effects, sub-agent behavior). No unnecessary 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?
Input schema is simple and fully covered. An output schema exists (per context) but is not shown; per rules, description need not explain return values. The description covers the cancellation flow adequately. Minor gap: could mention if any side effects, but sufficient for a cancel action.
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 has one parameter (deep_review_id) with full description, so schema coverage is 100%. The description does not add semantic detail beyond 'EcosystemDeepReview.id', which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool cancels an in-flight deep-review (stage_status='queued'), using a specific verb and resource. It distinguishes from sibling tools like ecosystem_deep_review_request and ecosystem_deep_review_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies the condition for use (stage_status='queued'), providing clear context. Does not explicitly state when not to use or name alternatives, but the condition is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it does well. It discloses the compact projection behavior ('view="compact"' trimmed view NOT missing fields), explains the server-side filter implementation history, and clarifies the default output shape. It doesn't mention auth requirements, rate limits, or pagination beyond the cap note, but the output-schema presence reduces that burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the main purpose first, a history/context note, then the compact-projection detail. It's readable and front-loaded with the core purpose. The history note about fixing server-side filters is useful context but slightly verbose for the tool's operational description. Still, every sentence earns its place — the firehose-to-filtered evolution explains why this tool exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 optional parameters with 100% schema coverage and an output schema that documents the return shape, the description covers the essential concerns: default behavior, compact vs. full projection semantics, the cap behavior, and filter scoping options. The tool is a read/list operation with no mutation concerns, so the absence of auth/permission caveats is acceptable. Very complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: it explains the compact vs. all projection difference (important for agents deciding whether to request full payloads), clarifies the 60-row cap on compact view versus uncapped for fields='all', and the project_id 'auto' semantics for active project resolution. The limit schema description also provides the cap context, supplementing well.
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 'List recent events in the system, optionally filtered' with a specific verb+resource. It explains all four filters are server-side and that the tool previously only exposed a global firehose. The purpose is distinct from sibling tools like task_status, team_status, and agent_activity_query, which target specific entities rather than a cross-system event stream.
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 the tool (listing recent system events, optionally filtered by type/source/entity/project). It doesn't explicitly name alternative tools for exclusions, but the filtering options and the note about it being a firehose vs. filtered tool provide clear usage guidance. It lacks explicit when-not-to-use guidance but is otherwise strong.
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 adequately discloses behavior: it writes to a specific file, explains the effect of an empty string (removing the key), and states the effect scope (new sessions only). This provides sufficient transparency for a configuration 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 with a parenthetical detail, front-loaded with the action and resource. Every word adds value, and there is no wasted text. It is highly concise.
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 nature of the tool (one parameter, no nested objects, output schema likely trivial), the description covers the key aspects: purpose, mechanism, and side effects. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (100%), but the description adds meaningful context beyond the schema: it explains the effect of empty string and the scope of the change. This improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' and the specific resource 'default startup model for new CC sessions'. It distinguishes itself from the sibling tool 'model_config_get' by focusing on writing. The resource is precisely described, avoiding vagueness.
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 for when to use (changing default model for new sessions) and notes that it takes effect only on new sessions. While it doesn't explicitly state when not to use or list alternatives, the purpose is well-defined and the scope is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the irreversible nature, the automatic agent status change (offline), and the lack of member deletion — meaningful behavioral context beyond what any schema could convey. It also warns that team_id never falls back to auto-resolving.
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 compact (roughly 60 words) with every sentence earning its place. Key behaviors are front-loaded in the first sentence, and the second paragraph reinforces the critical non-reversibility constraint without redundancy. 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?
The description is comprehensive for a single-parameter, irreversible operation: it covers purpose, behavioral side effects, reversal constraints, and parameter sourcing. With an output schema present, return-value explanation isn't needed. Could add slightly more on validating preconditions (e.g., confirming team completion), but overall well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single team_id parameter, so baseline is 3. The description adds value by stating team_id is REQUIRED (emphasizing the no-fallback behavior), noting it accepts 'ID or name', and pointing to team_list as the lookup mechanism — context beyond what the schema description provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource ('Close (complete) a team'), explains the two concrete behaviors (sets status to completed, marks all busy agents as offline), and distinguishes itself from siblings like team_delete/team_list by clarifying members are not deleted but set offline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use ('Use this when the team's mission is fully done'), explicitly states members are not deleted (differentiating from team_delete), and emphasizes the non-reversibility. However, it does not explicitly name alternative sibling tools to check first, though team_status is implied as a precursor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It richly discloses behavioral traits: the compact projection trims (NOT drops) fields, the full-list would exceed the MCP result ceiling at 148,173 chars / 316 teams, and teams accumulate per Workflow run/CC session so the list grows unbounded. This is excellent behavioral disclosure that justifies the default compact mode.
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 efficient — three sentences, front-loaded with the core purpose in the first sentence, then progressively detailed behavioral context. Each sentence earns its place: purpose/order, projection behavior, and the size/rationale. Slightly verbose with the measured character count but that empirical detail is genuinely useful justification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and 100% schema coverage on parameters, the description is complete for this complexity level. It explains defaults, ordering, projection differences, and crucially the size/rationale that prevents agent confusion about why compact is the default. The empirical data about the result ceiling is exceptional context that prevents failed calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (limit, fields, offset, status) are documented in the schema. The description adds value by explaining the compact projection semantics (trimmed vs missing fields) and the size rationale behind defaults, going slightly beyond the schema. Baseline 3 is appropriate since schema already covers parameter meanings well.
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?
Clear verb+resource+scope: 'List teams — active ones by default, newest first.' It precisely states what the tool does, the default filtering, and ordering. While 'team_list' vs 'team_status' siblings could be confused, the description clearly distinguishes it as a listing operation of teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains default behavior (active teams, newest first) and the default compact projection. It doesn't explicitly name alternatives, but the context of listing teams is clear enough, and the description of default vs 'all' fields gives usage context. No explicit when-not-to-use guidance against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It excellently discloses a critical behavioral trait: the default compact projection with trimmed rows and offline members folded into counts/digests, justified by concrete size measurements (170,331 and 69,660 chars) that would otherwise break the MCP ceiling. It also clarifies API route and Dashboard JSON are untouched. This is substantial behavioral disclosure beyond what the schema conveys.
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 front-loaded with the core purpose in the first line, then dives into implementation detail in the second paragraph. The detail is dense but earned — it explains WHY the compact projection exists with concrete data. Slightly long for a tool description but every sentence justifies itself; could be trimmed slightly, hence 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a read/observation tool with an output schema present, complex projection logic, and strong rationale documented. The description fully explains the default behavior, the reasoning behind it (with real size measurements), the exception paths (offline members folding into digest), and explicitly clarifies that underlying API and Dashboard JSON are untouched. For a tool with this complexity, the description is remarkably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description adds context to the fields parameter ('compact' means trimmed rows, not missing fields) and explains what includes_offline does (fold into count plus digest), which complements rather than repeats the schema. This adds genuine value on top of 100% 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?
Description clearly states the tool returns 'a team's status summary — team info + members + active tasks' and distinguishes it by explaining it hits /status rather than the bare team endpoint. It explicitly differentiates from sibling 'team_list' by noting the plain team row carries nothing actionable, making the purpose and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when this tool is appropriate (callers asking 'what is this team doing') and contrasts it with the bare team row. It does not explicitly name sibling alternatives or state when NOT to use it, but the context and framing (addressing the limitation of the plain team endpoint) gives clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does well here: it explains de-duplication by frontmatter name, the source field, and most importantly documents the default COMPACT projection including the concrete size figures (32,480 chars) and the grouped repetition problem. This gives real behavioral richness beyond what any structured field could provide.
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 front-loaded with the core purpose in the first line, then layers specifics in order of importance: sources+precedence, de-duplication identity, source field, and finally the compact projection rationale. Every sentence earns its place, and the concrete char count justifies why the default was chosen. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with a single param and an output schema present, this description is unusually complete. It covers resolution semantics, ordering precedence, de-duplication behavior, the default projection tradeoff, and corrects a likely misreading of 'compact'. The output schema handles return structure, and the description handles all behavioral nuance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the fields parameter is self-describing with its compact/all split documented. However, the description adds significant value by explaining the DEFAULT behavior ('compact - trimmed, NOT missing fields'), correcting a likely misinterpretation that compact omits fields. This disambiguation is genuinely useful beyond the bare 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 starts with a specific verb+resource statement ('List every Agent template CC can actually resolve') and goes further to explain the exact scope: which three sources are scanned, the precedence order, and de-duplication logic. This clearly distinguishes it from sibling tools like meeting_template_list and agent_list by focusing on resolution behavior and the subagent_type acceptance match.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool resolves (templates that subagent_type will accept) and the precedence semantics, giving strong contextual guidance on how results should be interpreted. However, it doesn't explicitly state when NOT to use it or name alternatives like agent_template_recommend, leaving the usage boundaries slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden—and it delivers richly. It discloses the async nature (queued vs running), the derived status column behavior change, the watchdog auto-fail mechanism with timeout_minutes, and the external dependency on the Leader spawning a sub-agent via CC Agent tool. This is exceptional behavioral transparency for an async 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 dense but efficiently organized—one opening sentence stating the core action, followed by a detailed paragraph covering secondary behaviors. Every sentence earns its place: the queuing mechanism, status derivation, watchdog timeout, and Leader responsibility are all relevant for correct invocation. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex async tool with side effects, a background process, and external dependencies. The description covers all these aspects: queueing semantics, status derivation, timeout auto-fail, and the Leader/spawn dependency. The interaction between stage_status and derived status is explicitly clarified. Output schema exists, so return values don't need explanation. Completeness is high for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters. The description adds context for repo_id (target of the review) and the timeout_minutes mechanism (auto-fail), but does not add new semantic meaning for agent_id or priority beyond what the schema already states ('Optional pre-assigned agent identifier', 'medium/high/critical'). Baseline 3 is appropriate when schema does the heavy lifting.
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 is highly specific: 'Queue a deep-review for a repo and return the dispatch prompt.' It names the exact resource (EcosystemDeepReview row queued on the funnel), the action (queue), and the return value (dispatch prompt). It clearly distinguishes from siblings like ecosystem_deep_review_status/list/cancel by being the only request/creation tool.
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 clearly explains the queueing workflow, the derived status fields, the background watchdog behavior, and the timeout handling. However, it does not explicitly state when NOT to use this tool or name an alternative (e.g., ecosystem_deep_review_request_batch for batch requests, or shallow review tools). The Leader-responsibility note gives useful context on the distributed workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and does disclose the mutable side effects: it creates an EcosystemDeepReview row per candidate. It also clarifies the division of responsibility ('Leader is responsible for actually spawning each agent via the Agent tool'), making the batch-nature and delegation behavior transparent beyond what schema reveals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with a clear Stage-1 label, distinct sentences covering pipeline inputs, side effects, and downstream handoff. Every sentence earns its place; there's no filler or redundancy. It is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (orchestration, batch creation, sub-agent spawning) but the description covers the essential flow: candidate selection criteria, row creation, output payload type, leader responsibility, and downstream write-back tool. Combined with a 100% schema coverage and an existing output schema, this is complete for an orchestration tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3. The description adds value by clarifying the AND-tag semantics and noting empty list returns 400 (behavioral constraint not obvious from schema alone). The description reinforces that research_goal is injected into each sub-agent prompt, though the schema already says this. Slight redundancy, but the tag semantics clarification pushes it above 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 states a specific verb+resource: 'Queue architecture-analysis dispatches for tag-filtered candidates' and describes the pipeline with an explicit Stage label. It clearly identifies inputs (active+shallow_done profiles with AND tag semantics), the output (DispatchIntent payloads), and differentiates this from sibling ecosystem tools by naming the downstream write-back target (ecosystem_apply_architecture_md).
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 operational context: it pulls specific profile states (active+shallow_done), uses AND tag semantics, and names the downstream tool each agent calls. However, it does not explicitly state when NOT to use this versus alternatives like ecosystem_deep_review_request (singular), ecosystem_scan, or ecosystem_trigger_debate, leaving some comparison ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and largely delivers: it discloses the headless resume mechanism, dedup-per-session behavior, shared wake concurrency/circuit-breaker constraints, ledgering in wake_sessions, and the conservative idle guard with its refusal outcome (availability='live'). Minor gap: the return/response shape (beyond the availability field) isn't described, though an output schema exists.
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 thorough but somewhat dense; the safety-gate section is detailed and valuable but runs long with layered sub-clauses. It's front-loaded with the core purpose first, which is good. It earns its length overall but could be tightened without losing the essential safety/disclosure information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a side-effecting dispatch tool with an output schema, no annotations, and 5 parameters, the description is remarkably complete: it covers behavior, safety constraints, failure modes, concurrency limits, source of the key parameter, and explicit non-goals. This is well-rounded for the agent to make a correct invoke/no-invoke decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, giving a baseline of 3. The description adds value by explaining what an 'instruction' means in operational terms (advance task X / report status) and adds context about target_session_id's source, and clarifies max_turns/tools_level defaults behavior (tools_level 'never exceeds the requested preset'). This goes slightly beyond schema, warranting a 4.
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 verb+resource+mechanism: 'Dispatch an operational instruction to another ship (CC session) in the fleet' via headless `claude -p --resume` on an idle session. It clarifies what the tool does (relay operational work, nudge idle ship) and what it does NOT do (no strategic decisions), clearly distinguishing it from sibling tools like task_run, channel_send, and agent_update_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Use it to nudge an idle ship to advance a task or report its status'), explicit when-not ('NOT to make strategic decisions'), and even defines the safety gate conditions that must hold (resumable, not user-live). It tells the agent where to source the key parameter ('Get target_session_id from the fleet view / project summary').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It details discussion rules, security requirements for caller_agent_id, impersonation flagging, audit implications, and legacy behavior, giving comprehensive insight into tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose first, then rules and security. It is concise yet covers essential details. A slightly more streamlined layout could improve readability, but 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 presence of an output schema (though not shown) and full parameter descriptions, the description covers behavioral rules and security comprehensively. It could mention error scenarios or idempotency, but for a messaging tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds value beyond schema by explaining the context and security semantics for caller_agent_id and agent_id, and the round rules enhance round_number, so it goes above 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 tool sends a discussion message in a meeting, with specific verb and resource. It distinguishes from siblings like meeting_read_messages or meeting_create by focusing on message sending and including discussion rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit discussion round rules (round 1, 2+, final) which guide when to use and how to behave, but does not directly compare to alternative tools like meeting_read_messages or outline exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses deterministic behavior (zero LLM), no independent LLM credentials, the agent's role in judgment, and the tool's role in coarse selection and operation application. It also details the four return blocks and their structure.
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 quite long and includes detailed operational instructions that could be provided elsewhere. While structured with bullet points and bold, it could be more concise. Every sentence adds value, but overall length exceeds what is strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (memory reconciliation with multiple output types and manual LLM steps), the description is highly complete. It explains the four output blocks, what to do with them (LLM judgment), and points to the next tool (memory_reconcile_apply). Output schema further complements 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?
Schema coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema for the two parameters (threshold and scope_path). It mentions them briefly but does not elaborate on their effects or defaults more than the schema already does.
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: returning candidate groups, direction inventory, promotion candidates, and operation guide for memory reconciliation. It uses specific verbs ('return', '粗筛') and distinguishes from the sibling tool 'memory_reconcile_apply' which handles the batch application step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool (for session-based memory reconciliation as a deterministic coarse filter) and contrasts it with the LLM's judgment role and the subsequent 'memory_reconcile_apply' step. It also clarifies that this is an on-demand action, not a background process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that a default Phase is automatically created and imposes a root_path constraint. However, it does not mention error handling or other side effects, but given the lack of annotations, it is still informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a warning block. It is front-loaded with the purpose, uses a clear warning format, and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers creation purpose, automatic phase creation, and critical usage constraints. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context for root_path (must match cwd) and implies description is optional, but does not add meaning beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new project with a default Phase automatically created.' It also explains the limitation about auto-registration, distinguishing it from other project tools like project_update or project_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'You should NOT manually create projects unless the auto-registered project is missing.' and 'The root_path MUST match the current CC session's working directory.' This provides clear when-to-use and when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It thoroughly discloses behavioral traits: explains that planned_agent_count is a 'static lower bound', dynamic_nodes can cause legitimate agent count increases, and planned_agent_count==0 means unknown plan (not zero). This is excellent transparency for the tool's domain-specific semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise. First sentence immediately states core purpose. Additional two sentences add critical domain knowledge without fluff. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full schema coverage and an output schema present, the description is complete. It explains all non-obvious behavioral aspects needed to correctly interpret results.
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% (all 3 parameters documented). Description adds no parameter-specific details beyond what the schema already provides, which is fine per guidelines (baseline 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?
Description clearly states it lists 'CC ultracode/Workflow runs tracked by the OS observability layer', using specific verb 'List' and resource 'workflow runs'. Distinguishes well from sibling tools like 'workflow_get' (singular) and 'workflow_reconcile' (different action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed context on when to use this tool vs alternatives by explaining the meaning of fields like planned_agent_count and dynamic_nodes, which helps the agent interpret results correctly. However, it doesn't explicitly state when NOT to use it or name alternative tools for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses behavioral traits beyond the schema: state transitions (stage_status changes), row completion, and UI retry for failure. This provides comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with two clear paragraphs covering success and failure paths. It is front-loaded with the primary purpose. Every sentence adds value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and a moderate number of parameters (4), the description fully covers the tool's behavior, state transitions, and parameter usage. The output schema exists but is not shown, so the description does not need to elaborate on return values. It is complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the conditional relationship between architecture_md and error_message, and reiterates the length requirement (800-1500 characters). This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Stage 1 writeback — submit architecture_md OR report failure.' It distinguishes the success and failure paths explicitly, which differentiates it from sibling ecosystem_apply_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the success path (pass non-empty architecture_md) versus the failure path (pass empty architecture_md and error_message). It does not compare to other tools or specify exclusions, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It extensively documents behavioral traits: quota/overflow behavior (returns all bucket entries + usage gap on overflow), security scanning (rejects invisible Unicode, prompt-injection patterns, credential forms since entries enter agents' system prompts), the injection truncation priority (constraint>design>directive>preference), and the '存得下的一定传得到' guarantee. Loses one point only because the exact return format on success isn't described (though output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely informative — every section earns its place, covering purpose, write-check, quota, overflow protocol, pointer-entry strategy, security, and kind taxonomy. It uses clear structural markers (bold, bulleted kind categories, code examples) and front-loads the core purpose. The only deduction is length; while justified, it's substantial and slightly dense for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex memory-writing tool with a rich output schema, the description is remarkably complete. It covers the direction-layer concept, quota system across scopes, overflow handling with concrete sibling tool references (memory_invalidate, memory_reconcile_apply, task_memo_add), security constraints, and the kind taxonomy with examples and truncation priority. The pointer-entry pattern for long content and soft-threshold test round out what an agent needs to correctly decide and execute.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all 5 parameters are documented in the schema. The description adds value beyond the schema: it explains the four kinds with concrete examples and their truncation priority ordering, defines scope inheritance semantics (project-specific contents that list specific repos fall to dir: fingerprint buckets, never broadcast globally), the '≤400 char' rule per entry, and the supersedes semantics (Zep invalidation without deletion). This meaningfully enriches what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a 'direction-layer memory' — shared cross-task standing preferences. It distinguishes from sibling task_memo_add (情景层) explicitly and defines the exact scope with detailed kind taxonomy. The verb 'add' plus the complex resource ('direction-layer memory with four kinds') is highly specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Excellent when/when-not guidance. It explicitly says single-task preferences should go to task_memo_add (情景层), not here. It provides a soft-threshold test ('how many future tasks does this affect?'), defines quota limits with per-scope buckets, and explains the overflow protocol (when full, return all entries and require memory_invalidate or memory_reconcile_apply first). It also covers the pointer-entry rewriting strategy and security scanning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: three safety guards (busy-agent, port-pin, dead-before-spawn) and fallback to plain start if API is down. Auth and rate limits are not mentioned, but the restart flow 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections. It is front-loaded with purpose and then details guards. Slightly verbose but every sentence adds value; minor conciseness improvements possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (restart with safety guards) and that an output schema exists, the description provides complete context: what it does, when to use, three guards, handling of down API. No gaps for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the 'force' parameter with a description, but the tool description adds context about the busy-agent guard and when to use force, enhancing semantics beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool restarts the AI Team OS FastAPI process safely, distinguishing it from siblings like os_health_check (health monitoring) and os_report_issue (issue reporting). The verb 'restart' and resource 'AI Team OS FastAPI process' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: 'after backend code changes to pick up the new version'. It provides context but does not explicitly state when not to use or mention alternatives. The safety guards imply conditions for use, but missing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: default COMPACT projection is trimmed (NOT missing fields), the I/O summary is excerpted due to result ceiling, windows capped at 50 rows, and sorted by timestamp descending. It adds material behavioral context beyond what the schema conveys.
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 tightly crafted, front-loaded with purpose in the first line, then organized into a compact logical flow: what's returned, default projection behavior, why (with measured evidence), and how to adjust. Every sentence earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (so return values are documented there), 4 params all with 100% schema coverage, and the description thoroughly explains the projection behavior, row caps, sorting, and the tuning strategy, the description is fully complete for an agent to select and invoke this tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the relationship between fields='compact'/'all' and the excerpt semantics, explaining that the compact window caps at 50 rows while the limit parameter defaults to 20, and noting agent_id narrows rather than widens. The interplay between limit and window cap is genuinely useful beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Query Agent activity records for a team', specifying the verb (Query), resource (Agent activity records), and scope (for a team). It distinctively reports tool name, duration_ms, and I/O summary, differentiating it from siblings like task_run, agent_list, or meeting tools. Well-defined purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly documents the default compact projection, explains the reason (43.9k char transcript ceiling), and provides concrete guidance: narrow with agent_id rather than widening limit for narrower windows, and use fields='all' for full records. It tells the agent exactly when and how to adjust parameters for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and largely meets it. It discloses that this is a read/recommend operation (no mutation), that the default output is a COMPACT trimmed projection (not missing fields), and that the resume_hint is a ready-to-run call requiring summary. The 'does not mutate — Leader decides' framing is explicit. Minor gap: it doesn't explicitly state what happens on empty/no-match results or whether candidate data is sourced from storage vs live state.
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 dense paragraph followed by a focused second paragraph on availability tiers and addressing, and a closing on the default compact response. Every sentence earns its place — purpose, decision actions, availability framework, addressing semantics, fallback, and output projection. No filler, no repetition of schema content that isn't enriched.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 params, an output schema, and no annotations, this description is thorough. It explains the decision model (three actions), availability tiers, addressing semantics, name-vs-id fallback, and output projection behavior. The output schema exists so return-value details needn't be in the description. It covers the behavioral and operational context an agent needs to correctly invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful value beyond the schema by explaining the 'Address candidates by NAME' vs agentId fallback semantics, what resume_hint contains (ready-to-run call), and the compact vs all projection meaning (trimmed, NOT missing fields). The 'fields' behavior is enriched beyond its schema line, and the project_id/session_id scoping is clarified (cross-session inference). This lifts it above 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 tool's purpose: recommend whether to reuse an existing sub-agent for follow-up work, ranking candidates by domain match and returning one of three actions. It is specific about the verb+resource (recommend reuse) and the decision framework (reuse/slim_then_reuse/spawn_new). Among siblings like agent_list, agent_template_recommend, and fleet_dispatch, this stands out as the reuse-decision tool, not just an enumeration or dispatch mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('follow-up work: bug re-fix, deeper research, same-domain iteration') for resuming a prior sub-agent to preserve accumulated context. It clarifies the tool only recommends and the Leader decides. The availability tiers and the addressing guidance (by NAME vs agentId fallback) provide strong operational context. While it doesn't name specific sibling alternatives, the situational trigger is precise enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the compact projection behavior prominently with hints, explicitly warns that view='compact' is a trimmed view and NOT missing fields, and explains which fields are kept. This is rich, preemptive clarification about the most likely source of agent confusion.
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 front-loaded with the core purpose in the first sentence, then uses clear sectioned paragraphs for scoping behavior and the compact projection caveat. Every sentence earns its place — no filler, no restating of schema fields. It's appropriately detailed for a tool with 9 parameters and a compact-vs-full projection distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, dual scoping modes, compact/full projections, folded-in sibling tool) and that an output schema exists, the description is complete. It covers scope selection, projection semantics, the consolidation history, and points to alternatives for full task detail, leaving no material ambiguity for the 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?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the team_id semantics (narrow vs empty = all teams) and the project_id default behavior (auto-uses active project; ignored when team_id given), beyond what the schema states. However, most parameter details (limit, offset, status enums, priority options) are fully covered by the schema already.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 'the task wall' with specific verbs and clarifies project-scoped vs team-scoped behavior. It distinguishes itself from siblings by noting it's the 'single task-wall entry point' and explicitly mentions that taskwall_view was folded into it, and points to task_status/task_memo_read as the full-detail alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: pass team_id to narrow to one team, leave empty for all teams plus project-level tasks. It also explicitly names alternatives (task_status for full single-task details, task_memo_read for memo) telling the agent when NOT to use this tool and what to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers exceptionally: it states 'Read-only' explicitly, reveals the two-orthogonal-metric quirk (5-25x apart), discloses the sub-agent coverage shortfall, warns that population paths are never merged, and explains why there's no total field (95.6% cache_read). This is deep, honest behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lean and front-loaded, with the core purpose in the first sentence. Every subsequent sentence earns its place by clarifying a behavioral invariant (denominator/label pairing, two-metric gap, 95.6% cache_read, no total). It covers rich context without padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return-value explanation is delegated. The description handles the complex semantics—dual metrics, sub-agent coverage shortfalls, population non-merging, windowing semantics—comprehensively, which is exactly the depth needed for a tool with these quirks. Combined with a 4-param all-optional schema, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description reinforces key semantics by explaining the day-windowing rationale (never on measurement time) and the population non-merging invariant, adding meaning beyond the schema's field names. It doesn't need to over-compensate given full 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 gives a specific verb+resource ('Report token usage together with how much of it can actually be accounted for') with a clear, distinctive scope. It differentiates itself from read-report siblings by emphasizing the denominator/metric-label pairing and the deliberate absence of a total field, which makes this tool's unique role unmistakable.
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 clearly explains when usage makes sense (accounted-for token reporting) and the 'Read-only' framing signals safe usage context. It doesn't explicitly name alternative tools for token reporting, but it does clarify internal semantics (no total field, why denominators matter, why population is never merged) that guide correct invocation. Marginal missing piece is explicit when-not-to-use guidance against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses API endpoint, return types including success/failure cases, and that dry-run results are excluded. Additionally warns about obsolete field names and legacy API behavior. No annotations exist, so description carries full burden and meets it.
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?
Well-structured with a brief summary, API mapping, and clear bullet points for each possible return scenario. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a modest output schema, the description covers all needed details: endpoint, response shapes, error conditions, and the meaning of success. The presence of an output schema is complemented by the description's field explanations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and schema coverage is 100%, so there are no parameters to document. The description compensates by thoroughly explaining the output structure and various response shapes, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches the latest IndexDiff snapshot for the current project. Distinguishes from siblings like ecosystem_index_update and ecosystem_diff_period by specifying it returns the most recent diff from a real (non-dry-run) update.
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?
Implies usage for retrieving the latest diff but does not explicitly mention when not to use or provide alternative tools. The mention that dry-run previews are not persisted gives some guidance, but no direct comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden, and it delivers richly: discloses Zep invalidation semantics (sets invalid_at without delete, preserves auditable trail), states post-invalidation behavior (no longer injected, absent from memory_list by default), and reveals the multi-match no-op guard policy. This is thorough behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a clear English summary, then adds Chinese operational context. The content is dense but purposeful—each section earns its place (semantics, behavior, dual-identification methods, no-op rules). Slightly verbose in the middle section but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, 100% parameter coverage, and the description explains return/behavior expectations: no-op for 0 or multiple matches, candidate list returned on ambiguity. Given tool complexity (dual-location, uniqueness constraints, invalidation semantics), the description is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are documented in the schema. The description adds value by explaining the 'exactly one of two' relationship (memory_id XOR content_match) and the unique-match constraint on content_match, going beyond what the schema's individual descriptions convey.
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+resource: 'Invalidate a direction-layer memory — mark it invalid without deleting.' Clearly distinguishes from delete, explicitly states it sets invalid_at without removal, and contrasts with memory_list for what happens after invalidation. Well differentiated from siblings like memory_add, memory_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when direction-layer preference is stale/overruled'), describes two mutually-exclusive location methods (memory_id vs content_match), and gives clear when-not (0 or multiple matches result in no-op). Even describes the specific scenario of being quota-limited and needing to avoid an extra lookup.
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:

[![AI-company MCP server](https://glama.ai/mcp/servers/CronusL-1141/AI-company/badges/card.svg)](https://glama.ai/mcp/servers/CronusL-1141/AI-company)

Score Badge

Copy to your README.md:

[![AI-company MCP server](https://glama.ai/mcp/servers/CronusL-1141/AI-company/badges/score.svg)](https://glama.ai/mcp/servers/CronusL-1141/AI-company)

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/CronusL-1141/AI-company'

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