multi-agent-mcp

by shiiman

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: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, with clear descriptions differentiating them. However, some overlap exists, such as multiple cleanup tools (cleanup_workspace, cleanup_on_completion) and redundant task assignment paths (assign_task_to_agent vs create_workers_batch). The sheer number of tools (90) introduces some ambiguity, but careful reading of descriptions resolves most confusion.
Naming Consistency5/5
All tools use consistent snake_case naming with a clear verb_noun pattern (e.g., create_agent, list_agents, send_task, get_dashboard). Even longer names like cleanup_on_completion and create_workers_batch follow the pattern. There is no mixing of conventions, making tool names predictable and easy to understand.
Tool Count1/5
The server exposes 90 tools, which is far beyond what is reasonable for a single MCP server. Many tools are repetitive variations (e.g., 10 memory tools for local and another 10 for global). This extreme count overwhelms both humans and agents, suggesting poor modularity and scope management.
Completeness4/5
The tool surface covers the full lifecycle of multi-agent orchestration: agent creation, task management, workspace setup, messaging, memory, health monitoring, recovery, cost tracking, and templates. Minor gaps exist, such as lack of direct agent log retrieval (only tmux output), but overall the set is comprehensive and leaves few dead ends.
Average 3.3/5 across 72 of 90 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 41 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
With no annotations provided, the description must disclose behavioral traits. It only states the merge action without detailing side effects (e.g., whether it is destructive, conflict handling, permission requirements, or impact on the working branch). The agent lacks critical safety information for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it front-loads the core action efficiently. However, the brevity comes at the cost of omitting essential details that could be included without verbosity. It earns its place but could be slightly expanded to improve completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no annotations, the description is incomplete. It does not cover what the output schema contains, error conditions, or the scope of 'completed tasks.' For a merge operation with multiple parameters and sibling tools, more context is necessary for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no context about parameters. The 5 parameters (session_id, repo_path, base_branch, strategy, caller_agent_id) are not explained; the description does not mention what 'working branch' refers to or how parameters control behavior. The agent cannot map the action to parameter values.
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 ('merge the working branch of completed tasks into base_branch'), providing a specific verb and resource. It distinguishes from siblings like cleanup_workspace or check_all_tasks_completed, which focus on different aspects of task management. However, it is slightly vague on which completed tasks are targeted (e.g., all or a specific session), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., all tasks completed) or scenarios where this tool is appropriate. Siblings like check_all_tasks_completed and cleanup_on_completion may be related, but the description does not clarify relationships or order of operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that recovery is executed without detailing side effects, permissions, or whether recovery is destructive. This is insufficient for safe invocation.
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 short sentence, which is concise, but it lacks critical details that would require more text. It is not verbose, but it sacrifices completeness 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?
Given that the tool performs monitoring and recovery, the description should explain what triggers recovery, the implications of recovery, and what the output schema contains. The current description is too vague 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema offers no explanation for the single parameter (caller_agent_id). The tool description does not explain this parameter, leaving its purpose and allowed values completely undocumented.
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 specifies monitoring and recovery of workers, which clearly states the verb and resource. It distinguishes from sibling tools like healthcheck_agent or attempt_recovery by combining both actions into one, though it could be more precise about the scope (e.g., all workers or specific ones).
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 healthcheck_agent, attempt_recovery, or full_recovery. The agent lacks context to decide whether this combined tool is appropriate instead of individual steps.
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 states the tool restores an entry but does not clarify side effects (e.g., whether the entry is removed from the archive after restoration), required permissions (only Owner/Admin), or idempotency. The return format is briefly mentioned but lacks detail.
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 short and structured with separate sections for purpose, permission note, and Args/Returns. However, the contradiction regarding 'caller_agent_id' reduces clarity, and the format could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, zero schema description coverage, and the presence of a sibling global tool, the description is incomplete. It does not explain what 'restore' entails (e.g., moving vs copying), how the entry is selected, or how errors are reported beyond a list of possible return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must add meaning. For 'key', it provides a clear description ('キー of the entry to restore'). However, for 'caller_agent_id', the description says it is required, contradicting the schema which marks it optional with a default of null. This inconsistency misleads the agent about parameter requirements.
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 ('restore') and the resource ('memory entry from archive'). However, it does not explicitly differentiate this tool from the sibling 'restore_from_global_memory_archive', which could lead to confusion about which archive is targeted.
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 a usage restriction (Owner and Admin only) but offers no guidance on when to use this tool versus alternatives like 'retrieve_from_memory' or when not to use it. No context on prerequisites or typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for transparency. It states parallel creation and task assignment/transmission, but fails to disclose side effects (e.g., whether existing workers are affected), rate limits, idempotency, or the exact nature of 'task assignment and transmission'. The permission note is helpful but 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 very concise (one sentence plus a permission note) and front-loads the main action. However, it omits important details that could be added without significant verbosity, slightly reducing its 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 tool's complexity (6 parameters, batch creation, task assignment, and many siblings), the description is insufficient. It lacks parameter guidance, return value information (output schema exists but not described), and contextual differentiation from related tools like 'create_agent' or 'send_task'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage (no parameter descriptions), so the description must compensate. However, it does not explain any parameter's meaning, especially the crucial 'worker_configs' array structure. Required parameters like 'repo_path' and 'base_branch' are also left undefined, offering no added value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and resource 'workers in parallel', and includes the additional actions of task assignment and transmission. It also notes the permission restriction (Owner/Admin). However, it does not fully differentiate from sibling tools like 'create_agent' (single agent) or 'enqueue_task', and could be more precise about what constitutes a 'worker'.
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 mentions 'Owner/Admin only' as a prerequisite but provides no guidance on when to use this tool versus alternatives. It does not specify scenarios where parallel creation is beneficial or when to avoid it, nor does it reference sibling tools like 'create_agent' for single worker creation.
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?
Given no annotations, the description must disclose behavioral traits. It only describes return fields but does not explicitly state that the operation is read-only, nor does it mention side effects, authentication requirements, or rate limits. The description is insufficient for transparency.
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 short and includes an Args/Returns block. The main purpose sentence is front-loaded. However, there is redundancy in restating the parameter in both the description and schema. It could be more concise by removing the duplicate information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks completeness. It fails to clarify the parameter requirement contradiction, does not elaborate on the return structure beyond listing field names, and provides no context about when the list is empty or fails. Given the output schema exists, more detail on return values would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description labels 'caller_agent_id' as '必須' (required) but the schema marks it as optional (default null). This contradiction is confusing. The description adds minimal meaning beyond the schema, only stating it's the caller agent ID, which is obvious from the name. With 0% schema coverage, more explanation is needed.
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 '利用可能なテンプレート一覧を取得する' which means 'Retrieve a list of available templates.' The verb 'list' matches the tool name, and it distinguishes from the sibling 'get_workspace_template' which retrieves a single template. However, it does not explicitly differentiate from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_workspace_template'. There is no mention of prerequisites, context, or when not to use. The description lacks any usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose whether the tool is read-only or has side effects, nor does it mention any error behavior. The description minimally covers the basic function but omits behavioral traits.
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 relatively short and uses bullet points for args and returns, which aids readability. However, the inclusion of Japanese and English, along with the parameter contradiction, undermines clarity. It earns a middle score for minimal structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description still explains return values, which is acceptable. However, it lacks information on error conditions, edge cases, or the significance of the returned fields. The parameter contradiction also reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It lists both parameters but incorrectly marks 'caller_agent_id' as required while the schema shows it optional. This contradiction reduces reliability. No additional constraints or formats are provided.
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 it detects task type from task description. It specifies admin-only usage, which helps distinguish from other tools. However, it does not explicitly differentiate from sibling tools that may also involve task analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates admin-only usage, providing a clear restriction. But it lacks guidance on when to use this tool versus alternatives, such as other detection or task inspection 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, so the description carries full burden. It only states the return value structure but does not disclose behavioral traits like idempotency, side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear Arg/Return structure. Every element serves a purpose, but it could omit the redundant translation of 'caller_agent_id'.
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 an output schema present, the description adequately covers the basic return signature. However, the parameter contradiction and lack of behavioral details reduce completeness for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'caller_agent_id' is described as required (必須) but the schema shows it is optional (default null). This contradiction undermines clarity. Schema coverage is 0%, and the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a cost summary, using a specific verb and resource. However, it does not differentiate from the sibling tool 'get_cost_estimate', which could cause confusion.
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 like 'get_cost_estimate'. The description lacks context for appropriate usage and does not specify any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions return fields (success, summary) but omits behavioral details such as idempotency, side effects, or error handling. Additionally, the description states caller_agent_id is required while the schema marks it optional, causing confusion.
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 very short and uses a clear Args/Returns structure. However, the inconsistency with the schema reduces its value, preventing a higher score.
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 presence of an output schema (implied) and only one parameter, the description lacks completeness. It does not mention error conditions, prerequisites, or how this tool relates to 'get_dashboard'. The contradiction with the schema further undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds a brief explanation for caller_agent_id but incorrectly claims it is required, contradicting the schema. This misleads about parameter usage.
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 dashboard summary, using a specific verb and resource. However, it does not differentiate from the sibling tool 'get_dashboard', leaving ambiguity about what a 'summary' entails versus the full dashboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_dashboard'. There is no context about prerequisites or expected 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?
No annotations provided; the description does not disclose side effects (likely none), permissions, or other behavioral details beyond parameter constraints. It mentions caller_agent_id is required, but this is contradicted by the schema where it's optional with default null.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear docstring structure (Args/Returns). It is front-loaded with the purpose sentence and no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, but the description only says 'Returns profile settings details' without further context. Parameter coverage is minimal, and there's no usage example or error handling. The description does not fully compensate for the 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It provides basic meaning for 'profile' (name, optional, defaults to all) and 'caller_agent_id' (caller ID), but lacks format or allowed values. The description claims caller_agent_id is required, conflicting with schema (default null, no required array).
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 it retrieves model profile settings details, with the ability to specify one profile or all. It distinguishes from siblings like get_model_profile (likely gets a single profile) and switch_model_profile, but could be more explicit about the differences.
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 like get_model_profile or switch_model_profile. The description simply explains what it does without context on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return format (success, task, or error) but lacks details on read-only nature, permissions, or side effects. Annotations are absent, so description carries full burden but only partially fulfills it.
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 short and includes structured Args/Returns sections. It is efficient with minimal waste, though the contradiction undermines quality.
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 output schema exists, the description omits behavioral context like when to use the tool and fails to correct the parameter contradiction. Incomplete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description marks 'caller_agent_id' as required (必須) but the schema defines it as optional with default null. This contradiction misleads an AI agent about parameter requirements. Schema coverage is 0%, so description should compensate but instead introduces error.
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 task details with specific verb 'get' and resource 'task'. It is distinct from siblings like list_tasks which lists all tasks, though no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., list_tasks, get_task_queue). No context on 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 must disclose behavior. It mentions opening a terminal app with priority and ownership restriction, but it does not explain side effects (e.g., whether it creates a new window, affects existing sessions) or the exact behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and includes arg/return sections. However, it wastes space listing the priority and including a contradiction about required parameters, making it less efficient than it could be.
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?
Output schema exists (though not shown) and the description lists return fields, but it lacks context on parameter meaning, usage scenarios, and side effects. The 0% schema coverage makes the incomplete description a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions in the schema. The description provides only vague names for agent_id and caller_agent_id, and contradicts the schema by stating caller_agent_id is required when it is actually optional with a default null.
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 opens the agent's tmux session in a terminal app with a priority order. It uses specific verb and resource, distinguishing it from sibling tools like send_command or get_output which do not launch terminal windows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives, but the tool's purpose is intuitive. The restriction 'Only Owner can use' provides some usage constraint, but lacks when-not-to-use or alternative recommendations.
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 mentions it returns a result with success, agent_id, message, but does not detail side effects, permissions, or error conditions, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and uses a clear docstring format with Args and Returns sections. However, it could be slightly more compact and avoid the inconsistency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and no schema descriptions, the description provides basic information but omits important context about state dependencies, duplicates, or system readiness. The internal inconsistency further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It names the parameters and gives Japanese translations, but there is an inconsistency: the description marks caller_agent_id as required while the schema allows null with a default. This contradiction undermines clarity.
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 registers an agent to the IPC system. However, among many sibling tools like create_agent, initialize_agent, it lacks differentiation from those operations, reducing clarity slightly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates creation and mentions an overwrite flag, but contradicts the schema by stating caller_agent_id as required when it is optional. No annotations are provided, so the description should fully cover behavior but falls short.
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 short and uses bullet points for parameters and returns, but the contradiction and lack of differentiation reduce its effectiveness. It is front-loaded but not fully accurate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, the description should provide comprehensive behavioral context. It mentions return format but lacks details about the generated config, prerequisites, or side effects. The schema contradiction further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It describes project_path and overwrite, but incorrectly labels caller_agent_id as required, contradicting the schema. This misleads the agent.
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 'Automatically generate Gtrconfig' which is a clear verb+resource. However, it does not differentiate from sibling tools like check_gtrconfig or analyze_project_for_gtrconfig, so some ambiguity remains.
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 includes a usage constraint ('Only Owner can use'), which is helpful but does not provide guidance on when to use this tool versus alternatives like analyze_project_for_gtrconfig.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses return structure (success, summary) but does not mention side effects, authentication needs, rate limits, or scope (local vs global). Minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and to the point, using both Japanese and English. It covers the essential: what it does, arguments, and returns. Could be improved with more structure but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, output schema exists), the description is adequate but incomplete. It fails to clarify scope (local vs global memory) and has a parameter contradiction. Output schema covers returns, so no need for detailed return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions caller_agent_id as required, but schema marks it optional. This contradiction is misleading. No other parameter details are given.
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 states 'Get memory summary information.' The verb + resource is clear. However, it does not explicitly distinguish between local and global memory, though a sibling tool exist (get_global_memory_summary) implying this is for local memory. Purpose is clear but could be more specific.
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 like get_global_memory_summary. No when-not-to-use or prerequisites mentioned. The description only states what it does, not when to invoke it.
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 partly carries the burden. It discloses admin-only authorization and the reset_progress effect, but omits behavioral traits like status changes to the task or error conditions beyond the return format.
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 moderately concise but could be cleaner. It mixes Japanese and English, and the structure places the admin note before the argument list. The return line is helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 0% schema coverage, the description should be more thorough. It lacks explanation of what constitutes a terminal task, prerequisites, or error conditions. The output schema exists but is not provided, so the description's return summary is useful but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for all three parameters, clarifying task_id, reset_progress, and caller_agent_id. However, it falsely marks caller_agent_id as required (schema says optional), which could mislead the agent into providing it unnecessarily or omitting it incorrectly. Schema coverage is 0%, so description compensates partially but with a contradiction.
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 resumes a terminal task, which is a specific verb+resource. However, it does not differentiate from sibling tools like update_task_status or report_task_progress, which could also modify task state.
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. It implies admin-only access but does not state prerequisites like the task must be in a terminal state, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a read-only search but does not explicitly state it is safe, non-destructive, or mention any authentication or side effects. The return format (success, entries, count) is mentioned but not behavioral traits.
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 very concise with a clear front-loaded purpose statement followed by a parameter list. Every sentence serves a purpose, though it lacks usage guidelines.
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 need not detail return values further. It covers the main purpose, parameters, and return structure. However, it is incomplete regarding behavioral context and the inconsistency in caller_agent_id requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds brief meaning to parameters (query, tags, limit, caller_agent_id) beyond the schema's empty descriptions. However, it incorrectly marks caller_agent_id as required, contradicting the schema (schema shows it as optional with default null). The limit default is correctly implied but not stated.
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 retrieves knowledge from memory, using the verb 'retrieve' and resource 'memory'. It distinguishes from siblings like 'save_to_memory' and 'delete_memory_entry' but lacks differentiation from 'retrieve_from_global_memory' or 'search_memory_archive'.
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. While siblings imply different operations, there is no statement of when to choose retrieve over get_memory_entry or list_memory_entries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden for behavioral disclosure. It only states the basic operation and return values, omitting key traits such as whether existing entries are overwritten, idempotency, failure scenarios, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear Args/Returns structure, listing all parameters compactly. It avoids verbosity, though the return section could provide more detail on the 'entry' object.
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 0% schema coverage and missing annotations, the description provides a basic understanding but lacks completeness. It covers parameter roles but does not explain behavior like duplicate handling or the structure of the returned 'entry', which would benefit an agent given the sparse context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds descriptions for parameters beyond the minimal schema, but note: the description marks 'caller_agent_id' as required (must), while the schema defines it as optional with a default null. This contradiction reduces reliability and adds confusion.
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 saves knowledge to memory, specifying parameters for key, content, tags, and caller_agent_id. It distinguishes from siblings like retrieve_from_memory and save_to_global_memory by name, but the description itself does not explicitly differentiate between local and global memory, missing a clear sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., save_to_global_memory or retrieve_from_memory). There is no mention of prerequisites or context, leaving the agent without direction for tool selection.
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 access restriction and return format. However, does not explicitly state whether the operation is read-only or has side effects. With no annotations, more behavioral detail would be helpful. Also, description claims caller_agent_id is required while schema says optional, causing inconsistency.
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?
Description is relatively concise with main purpose and param list, but mixes Japanese and English. The param descriptions are brief. Could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, access, params, returns. Missing prerequisites or behavior details. With an output schema present, return description is acceptable but could be more specific.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must fully explain parameters. It provides brief descriptions for both params, but incorrectly states caller_agent_id as required, contradicting the schema. This could confuse the agent.
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 it analyzes project structure and suggests recommended settings. However, it does not differentiate from sibling tools like 'generate_gtrconfig' or 'check_gtrconfig', so the purpose is clear but not uniquely positioned.
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?
Only states access restriction (Owner/Admin), but provides no guidance on when to use this tool versus alternatives. No explicit context for when to invoke or not.
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 mentions the return format but omits side effects, prerequisites beyond role, or behavior under failure. Additionally, it contradicts the schema by marking 'caller_agent_id' as required when it is optional.
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 very concise, using a few sentences to convey purpose, usage restriction, arguments, and return format. It is well-structured but could benefit from more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (recovery operation) and lack of annotations, the description is incomplete. It does not explain what recovery entails, whether it is idempotent, or what happens on success/failure beyond returning a message. An output schema exists but is not detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides brief explanations for both parameters, but the claim that 'caller_agent_id' is required is misleading and contradicts the schema, reducing reliability.
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 attempts to recover an agent, using a specific verb and resource. It is distinct from siblings like 'full_recovery' in name, but does not explicitly differentiate its scope or behavior.
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 specifies that only Owner and Admin can use the tool, providing some usage context. However, it does not indicate when this tool is preferable over alternatives like 'full_recovery' or 'monitor_and_recover_workers'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the access restriction and the return structure (success, gtr_available, message), adding some transparency. However, it does not mention side effects, error behavior, or permission-related consequences when unauthorized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single-purpose line, a restriction note, and a structured Args/Returns section. It is front-loaded and efficient, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no schema descriptions, the description should provide parameter details. It does cover the return structure, but the lack of parameter explanations and missing output schema (though reported present) leaves the description incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning no parameter descriptions exist. The description only lists parameter names ('repo_path', 'caller_agent_id') without any explanation of their meaning, format, or expected values. This fails to add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if 'gtr (git-worktree-runner)' is available. The verb '確認する' (confirm/check) is specific and matches the tool name. However, it does not differentiate from sibling tools like 'check_gtrconfig' or 'healthcheck_agent', which also perform checks but on different resources.
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 explicitly states 'Owner と Admin のみ使用可能' (Only Owner and Admin can use it), which provides a clear access restriction. However, it offers no guidance on when to prefer this tool over alternatives, nor does it describe prerequisites or context for 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, so the description should fully describe behavior. It mentions the deletion action, role restriction, and returns (success, key, message), but does not disclose side effects, irreversibility, or required permissions beyond roles. The behavioral disclosure 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with distinct sections for description, args, and returns. However, the inclusion of a contradictory requirement statement reduces clarity. The structure is adequate but flawed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and 0% schema coverage, the description should compensate with comprehensive details. It provides a basic purpose and role constraint, but misses usage guidance, example scenarios, and behavioral nuances. The error in parameter semantics further undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description states that 'caller_agent_id' is required ('必須'), but the input schema shows it is optional (default: null) and only 'key' is required. This is a factual error that misleads the agent. With 0% schema coverage, the description should clarify parameters but instead provides incorrect information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a memory entry.' and specifies the operation by key. Among memory-related siblings (e.g., get_memory_entry, list_memory_entries), this tool is uniquely identified as the deletion function. The role restriction ('only Owner and Admin can use') further clarifies scope.
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 the role restriction, which is helpful for authorization awareness. However, it does not compare this tool to similar deletion tools like 'delete_global_memory_entry' or provide context on when to use local vs global deletion. The guidance is partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It fails to mention side effects, auth needs, or error conditions. Moreover, it contradicts the input schema by stating caller_agent_id is required when schema marks it optional.
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?
Short and structured with Args/Returns sections, no extra fluff. Could be slightly more informative while maintaining conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's context (cost estimation, single optional param, output schema exists), the description omits important details like caching behavior, response fields beyond names, and when warnings occur. Incomplete for reliable 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 0%, so description adds meaning by naming the parameter and stating it's required (though contradictory). However, it lacks details like format or purpose beyond its name.
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 'get current cost estimate', a specific verb and resource. Differentiates from cost-related siblings like get_cost_summary and set_cost_warning_threshold.
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. Does not mention prerequisites 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?
No annotations provided. The description does not disclose any behavioral traits such as side effects, authentication needs, rate limits, or whether the operation is read-only. It only states the action and return structure.
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 very short and front-loaded with the main purpose. The Args/Returns structure is clear. However, it omits important details, making it slightly too terse.
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 a simple tool with one parameter and an output schema, the description covers the basic action and return fields. However, it lacks parameter explanation and usage context, which is needed for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description claims 'caller_agent_id' is required, but the schema shows it has a default of null and is not in a required list. This contradiction is misleading. The description adds no semantic value beyond restating the parameter name.
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 'Get the entire dashboard' (ダッシュボード全体を取得する), which is a specific verb and resource. It distinguishes from the sibling 'get_dashboard_summary' tool. Purpose is unmistakable.
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 sibling 'get_dashboard_summary' exists but is not mentioned. No context on prerequisites or use cases.
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 disclose behavioral traits. It states 'get' implying a read-only operation, which is acceptable. However, it does not mention side effects, permissions, or whether the returned data is fresh. The description is minimally transparent but adequate for a simple retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single-line purpose followed by structured Args/Returns sections. It includes both Japanese and English. The Returns section is vague but present. No unnecessary content, though it could be more compact.
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 low complexity (1 parameter, output schema exists), the description lacks completeness. It omits details about what constitutes a model profile and how the returned fields (success, active_profile, settings) are structured. The param description contradicts the schema, reducing trust. An output schema exists but is not described in the tool definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The Args section labels 'caller_agent_id' as required ('必須'), but the input schema shows it not in the required array and with a default of null. This contradiction degrades reliability. No additional semantic meaning beyond a name is provided for the parameter.
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 the current model profile ('現在のモデルプロファイルを取得する。'). This verb+resource combination distinguishes it from sibling tools like 'switch_model_profile' (alters profile) and 'get_model_profile_settings' (maybe more specific). However, it does not define 'model profile', leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as 'get_model_profile_settings'. No context provided about prerequisites or exclusion criteria. The description lacks explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. However, it contradicts the input schema: the description marks 'caller_agent_id' as required ('必須'), while the schema lists it as optional (default null) and not in required array. This inconsistency misleads the agent about invocation 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 brief and structured with clear 'Args' and 'Returns' sections. However, the inclusion of both Japanese and English is slightly redundant, and the required field mismatch wastes space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and an output schema (implied by 'Returns'), the description covers basic return fields. However, it lacks edge case behavior (e.g., what happens if directory doesn't exist) and usage context. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the sole parameter by labeling it as 'caller_agent_id' (caller agent ID) but misstates its required status. Schema coverage is 0%, so description must compensate; it partially does but the error reduces clarity.
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 screenshot directory ('スクリーンショットディレクトリを取得する'), which is a specific verb-resource combination. Among sibling tools like list_screenshots, read_screenshot, and read_latest_screenshot, this tool uniquely provides the directory path, distinguishing its purpose well.
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, no prerequisites, and no exclusions. It simply states what the tool does without contextualizing its usage in the broader workflow.
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 returns success/status/error, but does not disclose read-only nature, authorization needs, or any side effects. Minimal transparency.
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?
Description is short and lists parameters, but the contradiction reduces effectiveness. It is front-loaded with the purpose, but not all sentences earn their place due to inaccuracy.
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?
Tool is simple but description lacks details on return structure (e.g., what fields in 'status'). Output schema exists but is not provided in description. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must add meaning. However, description states caller_agent_id is '必須' (required) while schema shows it as optional with default null, creating a direct contradiction. This misleads the AI agent.
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 gets git status of a specified worktree. Verb 'get' and resource 'worktree status' are specific, and the tool is distinct from sibling tools like create_worktree or list_worktrees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. Usage is implied as checking worktree status, but there is no discussion of alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It mentions a return structure (success, entries, count) but does not state whether the operation is read-only, safe, or has any side effects. The scope 'common to all projects' is noted, but other important behaviors are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and uses clear bullet-point structure for Args and Returns. However, the inaccuracy about caller_agent_id being required detracts from its reliability.
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 and sibling tools, the description lacks details on pagination, sorting, or how tags interact. The difference from list_memory_entries is not explained, leaving the agent to infer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds only minimal meaning: tags for filtering and caller_agent_id as caller. The description claims caller_agent_id is required, contradicting the input schema which marks it optional with default null. This inconsistency reduces utility.
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 list of global memory entries, emphasizing it is common to all projects. This distinguishes it from sibling tools like list_memory_entries which likely operate on per-project memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_memory_entries or search_global_memory_archive. The description does not mention prerequisites or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It describes return structure but contradicts the schema by marking caller_agent_id as required (description) versus optional (schema default null). This inconsistency harms transparency.
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 short, listing parameters and return values in a structured way (Args/Returns). It is front-loaded with the core action. Could omit 'Args' header since schema already indicates parameter structure.
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 sibling tools (get_screenshot_dir, read_screenshot, read_latest_screenshot), this tool's role as a lister is clear. It includes limit parameter for pagination and describes return fields, which is sufficient for a list tool. However, no example or further details on ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains limit (max count) and caller_agent_id (caller agent ID), but incorrectly states the latter is required, contradicting the schema's optional default. This adds confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists screenshots in latest order. It implicitly distinguishes from sibling screenshot tools like read_screenshot and read_latest_screenshot, but does not explicitly differentiate.
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., read_latest_screenshot for a single latest). The description only lists parameters and return values, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits like read-only nature, idempotency, or side effects. The simple action statement lacks behavioral context beyond listing.
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 short and includes Args/Returns sections, but an inaccuracy about parameter requiredness reduces clarity. It is reasonably concise but not flawless.
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 an output schema, the return format summary is adequate, but the description lacks context among many sibling worktree tools (e.g., create_worktree, get_worktree_status), missing completeness about its role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides brief explanations for parameters ('caller_agent_id: 呼び出し元エージェントID') but misstates 'caller_agent_id' as required (schema shows optional with default null). This inaccuracy and minimal detail fail to fully compensate for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'リポジトリのworktree一覧を取得する' (list worktrees of a repository), identifying the specific action and resource, and distinguishing from sibling tools like create_worktree or remove_worktree.
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, such as when to list vs create or remove worktrees. The description only explains what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. However, it only states the return format and fails to mention any important traits such as whether the operation is destructive, permission requirements, error conditions, or side effects like file system access.
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 short and front-loaded with the primary action. The Args and Returns sections are clearly delineated. However, the contradiction regarding the required parameter and the mix of languages slightly reduce 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 that the tool has no annotations, one parameter, and an output schema (not fully shown), the description should provide a more complete picture. It lacks mention of any prerequisites, error handling, or how this tool fits into the broader set of screenshot-related tools (e.g., 'get_screenshot_dir', 'list_screenshots', 'read_screenshot').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description claims 'caller_agent_id' is required, but the input schema lists it as optional (default null), creating a contradiction. Additionally, schema description coverage is 0%, and the description only provides a label in Japanese without explaining the parameter's purpose or usage beyond being an agent ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'read' and resource 'latest screenshot' with Base64 encoding, leaving no ambiguity. While there is a sibling 'read_screenshot', the 'latest' qualifier in the name and description distinguishes it as the tool for the most recent screenshot.
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 'read_screenshot' or 'list_screenshots'. It lacks explicit context about prerequisites or the appropriate scenario for calling 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?
Without annotations, the description carries full burden. It mentions permissions (Owner/Admin only) and returns (success, summary), but does not disclose other behavioral traits like authorization failures, side effects, or rate limits. More detail is needed for a read operation with access controls.
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, uses a structured format (purpose, permissions, Args, Returns), and is appropriately sized for a simple tool. No wasted words, but it could be slightly more organized (e.g., clear separation of sections).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers the basic purpose, permissions, parameter, and return structure. However, it lacks details on the nature of the archive summary and how it differs from similar tools, leaving some informational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by explaining 'caller_agent_id' as the caller agent ID and stating it is required. However, the schema marks it as optional with a default null, creating a contradiction. Schema description coverage is 0%, so the description partially compensates but with inaccuracy.
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 'Get archive summary information' with a specific verb and resource. However, it does not differentiate from sibling tools like 'get_memory_summary' or 'get_global_memory_archive_summary', which could cause 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 specifies that only Owner and Admin can use the tool, providing a usage constraint. However, it lacks guidance on when to use this tool versus alternatives, and the stated requirement for 'caller_agent_id' contradicts the schema (optional).
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. The description only lists arguments and return shape, failing to disclose behavioral traits such as read-only nature, authorization needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary action, and uses a clear docstring format. However, it could be structured more clearly with bullet points.
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 covers basic task listing functionality but omits details like pagination, sorting, or allowed status values. Adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds minimal meaning: status and agent_id are filters, caller_agent_id is required. It lacks details on valid values or parameter relationships.
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 retrieves a list of tasks with optional filters. It uses specific verbs and resources, but does not explicitly differentiate from sibling list functions like get_task_queue.
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 retrieving filtered task lists but provides no guidance on when not to use it or alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source. It discloses the storage path and return values, but does not clarify mutation behavior like overwrites or uniqueness enforcement. The contradiction about caller_agent_id being required vs optional reduces clarity.
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 short, front-loaded with purpose, and wastes no words. It includes a storage path which is extra but not harmful. Could be slightly more structured but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers basic purpose and returns. However, the caller_agent_id contradiction and lack of details on parameter constraints leave gaps. Output schema is implied but not detailed enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It briefly explains key, content, tags, and caller_agent_id, but adds little beyond the schema. The description says caller_agent_id is required while the schema shows it as optional, causing confusion. No format or constraints for tags or content.
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 saves knowledge to global memory shared across projects, distinguishing it from local memory tools like save_to_memory. It uses specific verbs and resources, but could be more explicit about when to use global vs local.
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. It does not mention prerequisites, exclusions, or context for using global memory over local memory.
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 description must disclose all behavioral traits. It mentions grid layout behavior and auth, but fails to describe side effects, idempotency, or resource cleanup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with main purpose, then structured with Args/Returns. Minor waste due to redundancy in parameter documentation.
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?
Lacks completeness for a termination tool: no mention of prerequisites, idempotency, or what happens to agent's tasks. With no annotations and no output schema visible, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. However, it contradicts the schema by stating caller_agent_id is required when schema marks it optional, 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 it terminates an agent, using specific verb+resource. It distinguishes from sibling tools like create_agent or initialize_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions Owner/Admin only usage restriction, but lacks guidance on when to use versus alternatives like healthcheck_agent or attempt_recovery.
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 mentions permission and return format, but omits side effects, error conditions, and idempotency. There is a contradiction: description marks caller_agent_id as required (必須) while schema marks it optional with default null.
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 relatively short but includes unnecessary line breaks and a bullet list that could be more structured. The contradiction adds confusion, reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and an output schema, the description is incomplete. It does not explain prerequisites (e.g., worktree must exist), how assignment affects the worktree, or error scenarios. The return format is vaguely described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It lists parameter names and brief translations (e.g., 'エージェントID'), adding minimal value. The misleading 'required' note for caller_agent_id contradicts the schema and harms clarity.
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 'assign worktree to an agent' with a specific verb and resource. It distinguishes from sibling tools like create_worktree, list_worktrees, etc., 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that only Owner and Admin can use the tool, providing a usage restriction. However, it lacks guidance on when to use this tool versus alternatives like create_worktree or get_worktree_status.
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 bears the full burden. It discloses the layout behavior and role restrictions, but does not detail side effects, idempotency, or error conditions. For a creation tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and includes an Args section, but the layout details (40:60 split, pane numbers) are verbose and may not be necessary for tool invocation. It could be more concise.
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 covers purpose, parameters, and return values. However, it lacks context on prerequisites (e.g., whether a workspace must exist) and potential errors. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It provides descriptions for all parameters and indicates allowed values for 'role' and 'ai_cli'. However, it contradicts the schema by marking 'caller_agent_id' as required ('必須') while the schema lists it as optional. This inconsistency reduces reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '新しいエージェントを作成する' (create a new agent) and provides specific layout details, making the purpose clear. However, it does not explicitly distinguish from sibling tools like 'initialize_agent', though the layout details imply a specific type of agent creation.
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 creating a new agent with specific roles, and notes 'Owner と Admin のみ使用可能' (only Owner and Admin can use). However, it does not provide guidance on when not to use or mention alternatives like 'initialize_agent'.
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?
Description states caller_agent_id is required, but schema marks it as optional with default null, creating a contradiction. No annotations provided. Discloses admin restriction and return format, but the contradiction undermines reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a purpose sentence, admin note, and structured Args/Returns section. No extraneous text, but the contradiction about required parameter reduces clarity.
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 moderate complexity and no output schema structure, description covers most aspects but misses sibling differentiation and lacks detail on queue behavior. The contradiction further detracts from completeness.
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 has 0% coverage, so description bears full burden. It explains each parameter's meaning and provides example values for priority. However, it does not clarify allowed values for dependencies or that priority defaults to medium in 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?
Description clearly states the verb ('追加する' = add) and resource ('スケジューラーキュー' = scheduler queue). Among siblings like create_task and remove_task, it differentiates by focusing on queue addition. However, explicit distinction from create_task is not provided.
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?
Only mentions admin-only usage. No guidance on when to use enqueue_task vs alternatives, prerequisites, or when not to use. Lacks context for decision-making.
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. The description mentions return structure (success, entry or error), which is helpful, but lacks details on side effects, permissions, or rate limits expected from a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with front-loaded purpose and structured Args/Returns. Every sentence adds value, though the return format could be omitted given an output schema exists.
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 simplicity (2 parameters, read operation) and existence of output schema, the description adequately covers functionality. It explains parameters and return format, though caller_agent_id purpose could be expanded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes brief parameter explanations, but incorrectly marks caller_agent_id as required (schema shows optional). Schema coverage is 0%, so description must compensate; the error undermines reliability.
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 'get a memory entry by key', clearly indicating the action (get) and resource (memory entry). It distinguishes from sibling tools like list_memory_entries and delete_memory_entry, but does not explicitly differentiate from retrieve_from_memory.
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 others. The description does not mention alternatives, prerequisites, or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it returns a count and mentions a success field, but does not disclose whether this is a pure read operation, any side effects, authentication needs, or rate limits. The behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, with the main purpose stated upfront followed by structured Args and Returns sections. It avoids unnecessary words, though the inclusion of familiar docstring formatting is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple getter with two parameters and an output schema exists (though not shown), the description covers the basic return structure. However, the error about a required parameter and lack of usage context reduce completeness for an adequate understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description attempts to explain parameters but contains a factual error: it marks 'caller_agent_id' as required while the input schema declares it optional with a default of null. This contradiction undermines reliability. Schema coverage is 0% so the description partially compensates but with an inaccuracy.
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 the number of unread messages for an agent. The verb 'get' and resource 'unread count' are specific and unambiguous. It distinguishes itself from related tools like 'read_messages' which read actual messages rather than a count.
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 conditions. It does not mention when to prefer this tool over other messaging tools among the siblings.
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?
Annotations are absent, so description must fully disclose behavior. It only states the operation and return format, missing details on side effects, error handling, file existence checks, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and structured with Args and Returns, making key info easy to find. However, the misleading required tag on caller_agent_id adds a minor clarity issue.
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?
Covers main purpose, arguments, and return fields. Lacks details on error responses, prerequisites (e.g., file must exist), and output schema specifics. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions are minimal (e.g., 'filename: ファイル名') and misleadingly mark 'caller_agent_id' as required while schema allows null. Schema description coverage is 0%, and description fails to compensate with detailed semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reads a specified screenshot and outputs Base64 data. Verb 'read' and resource 'screenshot' are unambiguous, and the tool is distinguished from siblings like 'list_screenshots' and 'read_latest_screenshot'.
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., read_latest_screenshot). Does not specify context or exclude conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions 'allow_dangerous: allow dangerous commands explicitly' which hints at safety behavior, but contradicts schema regarding caller_agent_id requirement. Lacks details on authentication, side effects, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: one-line summary, usage note, Args section, Returns. Efficient but a bit verbose due to Japanese. Each part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complex tool with 4 params, no annotations, 0% schema coverage. Description lacks full explanation of return format, missing output schema details, and has a contradiction about required parameter. Incomplete for reliable 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?
With 0% schema coverage, description provides brief explanations for each parameter (target agent, command, dangerous flag, caller agent). Adds some value but is minimal and in Japanese. Does not fully compensate for lack of schema descriptions.
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 'Send a command to a specified agent.' The verb 'send' and resource 'agent' are specific. However, it does not distinguish from sibling 'broadcast_command' which sends to all agents, missing differentiation.
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?
Provides access control info: 'Only Owner and Admin can use.' This is a usage guideline but does not specify when to use this tool vs alternatives like broadcast_command.
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 behavioral traits. It mentions file-based sending and access restrictions, but it doesn't describe side effects, idempotency, error behavior, or whether the operation is synchronous. The description adds some context but is insufficient for a tool that sends tasks.
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 short paragraph followed by a concise parameter list. It front-loads the main purpose and access constraint. The parameter descriptions are efficient, though the list is relatively long. Overall, it's well-structured without unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no annotations, the description covers purpose, parameters, and access control. However, it lacks info on prerequisites (e.g., agent must exist), return values (output schema exists but not explained), and differentiation from similar sibling tools. Some gaps remain for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must add meaning. The description provides explanations for all 7 parameters, including examples (e.g., report_template: 'e.g., "security", "general"') and behavior (e.g., injection into Worker's task instructions). This adds significant value beyond schema titles.
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 sends task instructions via file to an agent and specifies access control (only Owner/Admin). It uses a specific verb and resource, which distinguishes it from some siblings like send_command or create_task, but it doesn't explicitly contrast with 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?
The description mentions that only Owner and Admin can use the tool, providing a constraint, but it gives no guidance on when to use this tool versus alternatives like enqueue_task, send_command, or create_task. No when-to-use or when-not-to-use information is 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 description carries full burden. It discloses authorization constraints and the return structure (success, summary). However, it does not state whether the operation is read-only, has side effects, or what happens if permissions are insufficient. Some behavioral context is added, but depth is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief (one sentence plus bullet-style Args/Returns). It is front-loaded with the core purpose and authorization note. The structure is clean, though the Args/Returns format is slightly verbose for a single parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one optional parameter, an output schema exists, and it is a simple retrieval, the description covers key points: purpose, access control, and return shape. However, it does not clarify what the 'summary' contains or when this tool is preferred over similar memory summary tools (e.g., get_global_memory_summary).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, caller_agent_id. Schema description coverage is 0%, so description must compensate. The Args section states it is required, but the input schema shows default null and no required constraint, creating a contradiction about requiredness. No explanation of the parameter's purpose or usage beyond 'caller agent 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?
Description clearly states the tool retrieves global archive summary information common to all projects. Verb '取得する' (get) and resource 'グローバルアーカイブのサマリー情報' are specific. However, no explicit comparison to sibling tools like 'get_global_memory_summary' or 'get_memory_archive_summary', though the name and 'global' + 'archive' combination help distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly restricts usage to Owner and Admin roles only, providing a clear prerequisite. However, it does not specify when to use this tool over similar siblings or what scenarios are appropriate. The guidelines are basic but present.
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. The description states it returns 'success, template or error', which implies a read operation, but lacks details on error handling, authentication, or side effects. Not contradictory with any annotations, but minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear Args/Returns structure. However, the parameter contradiction reduces its effectiveness. Otherwise, it is front-loaded and efficient.
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 output schema exists, reducing the need for return value details, but the description fails to provide parameter semantics (e.g., format of template_name) and contains a contradiction. This leaves gaps for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It lists names and Japanese translations, but claims 'caller_agent_id' is required, contradicting the schema which shows it as optional with default null. This misleading info harms 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 verb 'get' and the resource 'workspace template', specifying that it retrieves details of a specific template. This distinguishes it from sibling tools like 'list_workspace_templates' which lists all templates.
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 (retrieve one template by name) but does not explicitly differentiate from alternatives. No guidance on when to use this tool versus 'list_workspace_templates' or other getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that only Owner/Admin can use and returns a health status. However, it contains a contradiction: it states 'caller_agent_id' is required (必須) while the schema marks it as optional with a default null. This inconsistency reduces transparency.
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 short but includes unnecessary docstring formatting (Args/Returns) and line breaks. It conveys essential information but could be more streamlined.
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 output is described ('success, health_status'), and the permission constraint is given. However, it lacks details about error handling, what happens if the agent doesn't exist, and does not differentiate from many sibling tools. Adequate for a simple tool but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It provides basic labels for 'agent_id' and 'caller_agent_id' and incorrectly marks the latter as required. It adds minimal meaning beyond the parameter names and contradicts 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 'Execute health check for a specific agent' (特定エージェントのヘルスチェックを実行する), using a specific verb and resource. It distinguishes itself from sibling tools like 'healthcheck_all' which checks all agents.
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 that only Owner and Admin can use this tool, providing a usage constraint. However, it does not explicitly compare to alternatives or state when to use this tool versus other health-check-related tools like 'get_unhealthy_agents' or 'attempt_recovery'.
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 inform about side effects and behavior. It states that it returns health statuses, but does not disclose whether the operation is read-only, whether it can fail partially, or if there are rate limits. The authorization requirement is mentioned, which is a positive.
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 relatively concise with clear sections for Args and Returns. It front-loads the main purpose. However, the mixed language (Japanese and English) and the contradiction add unnecessary noise. Still, it is well structured for a short description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and an output schema, the description covers the core functionality and authorization. However, the parameter contradiction and lack of explanation about the return structure (beyond field names) leave gaps. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds only a label 'caller_agent_id' with no explanation of its purpose or format. Worse, it claims the parameter is required while the schema marks it as optional with a default null, creating a contradiction. This undermines the agent's ability to use it correctly.
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 performs a health check for all agents. The verb 'execute' and resource 'health check for all agents' are specific. It distinguishes from sibling 'healthcheck_agent' which is for individual agents. However, the contradiction between description (required parameter) and schema (optional) slightly reduces clarity.
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 a usage constraint: 'Owner and Admin only'. This tells the agent when authorization is needed. However, it does not explicitly state when to prefer this over alternatives like 'healthcheck_agent', nor does it give conditions for 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?
The description partially discloses behavior through parameter listings (e.g., mark_as_read indicates mutation). However, it does not explicitly state side effects, authorization needs, or rate limits, and lacks clarity on read-only nature when mark_as_read is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-line summary and a bulleted argument list. It avoids unnecessary words and is well-structured, though slightly more context on usage could be added without bloat.
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?
While the return shape is specified, the description misses important behavioral details, such as the actual role of caller_agent_id (claimed required but schema says optional). With no annotations, more context is needed for a tool with 5 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning by listing and briefly explaining each parameter's purpose in Japanese. This compensates for the schema deficiency, though it lacks constraints or formats.
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 reads agent messages, providing a verb and resource. However, it does not distinguish it from sibling tools like send_message or get_unread_count, missing differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer 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?
No annotations are provided, so the description carries the burden. It discloses that the tool returns search results with success, entries, and count, but does not mention side effects or authentication needs. For a read operation, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. Every sentence adds value, including the args list. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and an output schema, the description provides a basic understanding but lacks context on when to use this tool versus other global memory tools, and does not explain the behavior of tags or limit parameters beyond their names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to explain parameters. It lists all 4 parameters with brief descriptions, but contradicts the schema by marking 'caller_agent_id' as required when it is actually optional with a default null. This contradiction reduces clarity.
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 knowledge from global memory, common across all projects. It distinguishes it from project-specific memory tools like 'retrieve_from_memory' in the sibling list, but does not explicitly contrast them.
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 mentions 'common across all projects', implying use for cross-project data, but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like 'retrieve_from_memory'.
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 permission constraint (Owner only) and the return format, but does not explain side effects, such as whether the threshold replaces an existing one or if there are limits. For a mutation tool, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with clear sections for args and returns. It is front-loaded with the purpose and permission note. Every sentence adds value, though the args section could be more compact.
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 output schema exists, the description's return section is redundant but harmless. It covers parameters and permissions but lacks context on the scope of the threshold (e.g., global vs per workspace) and how it interacts with cost monitoring. Siblings suggest cost management context, but this tool's description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to both parameters beyond the schema (which lacks descriptions). However, it incorrectly states that caller_agent_id is required, contradicting the schema which marks it as optional. This misleads the agent.
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 and resource: 'Set cost warning threshold'. It is specific among siblings, which include other cost tools like get_cost_estimate and reset_cost_counter, but none that set a threshold. However, it does not explicitly differentiate from them, so a slight deduction.
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 that only the Owner can use this tool, providing usage context. However, it does not give guidance on when to use this tool versus alternatives or when not to use it. The note is helpful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions creation and return format, but it contradicts the input schema by stating caller_agent_id is 'required' when schema marks it as optional with default null. This inconsistency undermines trust and does not disclose other behaviors like idempotency, side effects, or error states.
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 short purpose statement, a permission note, a parameter list, and a returns section. It is concise and front-loads essential information. However, the inaccuracy about caller_agent_id detracts from overall clarity.
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 covers the basic purpose, permissions, parameters, and return format. An output schema exists (not shown), potentially reducing the need to detail returns, yet the description still provides a summary. However, the contradiction with the schema leaves gaps, and the description does not address potential edge cases or error conditions beyond a generic 'error'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides brief explanations for each parameter, but the description incorrectly marks caller_agent_id as required while schema shows it as optional. This inaccuracy reduces the usefulness of the parameter descriptions. Additionally, terms like 'metadata' lack specification on allowed structure.
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 task' (新しいタスクを作成する), which is a specific verb+resource. It distinguishes from sibling tools like update_task_status, assign_task_to_agent, etc., which modify or query tasks rather than create them.
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 includes a permission restriction ('Only Owner and Admin can use'), which provides context on when the tool is available. However, it does not explicitly contrast with alternative tools or specify when to use this tool vs. other task-related tools. The guideline is helpful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions return fields (success, agent, session_active, error) but lacks details on side effects, prerequisites, or error handling. Critically, it describes caller_agent_id as '必須' (required) while the schema marks it optional with a default of null, creating a contradiction. This misleads the agent about parameter requirements.
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 short and directly states the purpose and parameters. It is front-loaded with the action statement. However, it includes a structured docstring format (Args:/Returns:) which, while clear, takes up space that could be more concise prose. Overall, it is efficient with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values are documented elsewhere) and the relatively simple tool (2 params), the description is adequate but lacks important context such as when the tool is needed (e.g., before sending commands to an agent), error conditions, or preconditions (e.g., agent must exist). It does not address potential error responses beyond mentioning 'error' in returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning. It provides Japanese labels for both parameters, but agent_id is just 'エージェントID' (agent ID) and caller_agent_id is '呼び出し元エージェントID' (caller agent ID) with a misleading requirement tag. The description adds minimal semantics beyond the parameter names and contains a factual error about requiredness.
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 '指定エージェントの詳細ステータスを取得する' (Get detailed status of specified agent), which uses a specific verb and resource. It distinguishes from siblings like list_agents (listing all agents) and get_task (retrieving a specific task), though not explicitly.
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 does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. Usage is implied by the tool name and purpose, but no context or exclusions are 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. Description mentions admin-only authorization and returns success/persona. Does not disclose side effects or state changes; acceptable for a retrieval 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?
Short and to the point, with key sections: purpose, admin note, args, returns. Slight redundancy with line breaks but overall efficient.
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?
Covers purpose, admin restriction, arg meanings, and return shape. However, the arg description error (caller_agent_id required) indicates incompleteness. Output schema exists so return details are less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds minimal meaning: task_description as 'description of the task'. But for caller_agent_id, it says 'required' which contradicts the schema where it's optional with default null. This is misleading and reduces value.
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 states 'Get the optimal persona for the task' with a specific verb and resource, and the parameter 'task_description' indicates input. It distinguishes from sibling 'list_personas' which lists all personas, implying this selects one.
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?
Informs that only Admin can use it, providing a usage condition. Does not explicitly state when to use versus alternatives like list_personas, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool retrieves data ('取得する') and returns fields: success, unhealthy_agents, count. It also notes authorization requirements. However, there is a contradiction with the input schema: the parameter caller_agent_id is marked as required in the description but is optional (anyOf string/null, default null) in the schema. This inconsistency undermines reliability. No annotations are provided, so the description carries full burden but fails to clarify side effects, pagination, or the meaning of 'unhealthy'.
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 four lines: a one-line purpose, an authorization note, and structured Args/Returns sections. It is well-organized and front-loaded with the main action. No unnecessary words are present, though some detail is sacrificed for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema (not detailed in description). The description covers the main purpose, authorization, and return fields. However, it lacks specifics about the output structure (beyond field names), what constitutes 'unhealthy', and whether the list is paginated. The contradiction regarding the parameter's requiredness also creates a completeness gap. Overall, it is adequate for a simple tool but has clear areas for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to explain the parameter. It states 'caller_agent_id: 呼び出し元エージェントID（必須）', which adds meaning by specifying the parameter's purpose and claiming it is required. However, this contradicts the schema which defines it as optional with a default null. The added meaning is partially offset by this contradiction.
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: 'Get list of unhealthy agents' (異常なエージェント一覧を取得する). It uses a specific verb and resource, and additionally specifies that only Owner and Admin can use it, which helps distinguish it from related tools like healthcheck_agent or healthcheck_all.
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 includes an important usage restriction ('※ Owner と Admin のみ使用可能'), indicating who can invoke the tool. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., healthcheck_agent vs. get_unhealthy_agents). The usage is implied but lacks comprehensive 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 description carries full burden. It only states 'manually unlock' without disclosing effects, preconditions, or side effects. Lacks details on what happens after unlock, permissions needed, or reversibility.
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 sentences covering purpose and arguments. No wasted words, appropriate length for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no required fields, output schema exists), the description is minimally adequate but lacks usage context and behavioral details. Insufficient for an agent to correctly assess 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 description coverage is 0%, so description adds some meaning: reason defaults to 'manual_unlock' and caller_agent_id is called required. However, the requirement contradicts the schema, reducing trust. Adds marginal value but not comprehensive.
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 manually releases the owner's waiting lock ('Owner の待機ロックを手動解除する'), which is a specific verb+resource. It distinguishes from sibling tools, none of which mention lock 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?
No guidance on when to use this tool versus alternatives. The description claims caller_agent_id is required ('必須') but the schema sets it as optional with a null default, creating a contradiction that misleads 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 provided, the description carries the burden of behavioral disclosure. It mentions an Admin-only restriction and notes that 'caller_agent_id' is used for role checking. However, it does not disclose whether the tool is idempotent, what happens if the agent already has a task, or 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: a single-line purpose, an admin note, and structured Arg/Returns sections. It is front-loaded and efficient, though the Args section repeats parameter names without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no annotations, the description provides the basic operation and return format. However, it does not explain how optional parameters impact behavior, nor does it help differentiate from many related task-management sibling tools. The output schema exists but is not described, though that is acceptable per rules.
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 0%, so the description must add meaning. It lists parameters with brief labels like 'タスクID' and 'エージェントID', but these are essentially the parameter names repeated. Optional parameters 'branch' and 'worktree_path' are described as 'optional' without explaining their purpose. This adds minimal value over 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 verb ('assign') and resource ('task to an agent'), making the tool's purpose unambiguous. It is distinct from sibling tools like 'auto_assign_tasks' which imply automated assignment, but the description does not explicitly differentiate them.
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 specifies that only Admin can use this tool, which is a clear prerequisite. However, it does not provide guidance on when to use this tool over alternatives like 'enqueue_task' or 'auto_assign_tasks', leaving the agent to infer appropriate usage from 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?
No annotations are provided, so the description carries the full burden. It discloses that only Owner and Admin can access the tool, which is a behavioral constraint. However, it does not explicitly state whether the tool is read-only, whether it modifies anything, or any other side effects. It mentions returning a state (success, status), but not the full 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 reasonably structured with a title line, a note, argument list, and return section. It is relatively short and to the point, though the formatting includes line breaks and special characters that could be streamlined. Overall, it earns every sentence without much waste.
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 mentions returned values as 'Gtrconfig状態（success, status）' but does not explain what 'success' and 'status' mean, nor does it clarify whether the actual content of Gtrconfig is returned. There is ambiguity about the tool's behavior when the configuration does not exist or on errors. Given the presence of an output schema (not shown), the description should complement it but falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. It explains project_path as 'プロジェクトのルートパス' (root path of project) and caller_agent_id as '呼び出し元エージェントID（必須）' (caller agent ID, required). However, the schema marks caller_agent_id as optional (default null), contradicting the description that says it is required. This inconsistency reduces clarity.
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 'Gtrconfigの存在確認と内容取得' which translates to 'Check existence and get contents of Gtrconfig'. It specifies a specific verb and resource, and distinguishes from siblings like check_gtr_available (which likely only checks availability) and analyze_project_for_gtrconfig (which analyzes/generates).
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 includes a usage restriction: '※ Owner と Admin のみ使用可能' (Only Owner and Admin can use). However, it does not provide guidance on when to use this tool versus alternatives (e.g., check_gtr_available) or when not to use it. The sibling tools list includes similar tools, but no differentiation 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?
With no annotations, the description must cover behavioral traits. It notes the access restriction and return shape (success, queue), which is adequate for a simple read operation. However, it could mention whether the queue is read-only or if it locks anything.
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 relatively concise with a clear structure using sections. However, the parameter requiredness contradiction is a structural flaw. The title is null but not part of description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, output schema exists), the description covers basic purpose and restrictions. However, the parameter error and lack of usage guidance make it less complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a Japanese explanation for the caller_agent_id parameter, but it incorrectly states it as required (必須) while the schema defines it as optional with default null. This contradiction reduces value. Schema coverage is 0%, so the description should compensate, but the error undermines its utility.
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 '取得する' (get) and the resource 'タスクキュー' (task queue). It is distinct from sibling tools like enqueue_task or auto_assign_tasks.
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 mentions that the tool is only available for Owner and Admin, which provides some access context. However, it does not specify when to use this tool over other queue-related tools or provide alternatives.
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; description adds only an admin restriction. It contradicts the schema by marking caller_agent_id as required when schema shows it's optional. No mention of read-only behavior or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and structured with Args and Returns. However, it mixes Japanese and English and could be more concise by removing 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?
For a simple list tool, description covers purpose, admin constraint, and return fields (success, personas, count). No output schema provided, but return structure is described sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It describes caller_agent_id as 'required' but schema shows optional, creating confusion. No additional semantics beyond the name.
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 'Get list of available personas' and specifies admin-only use. It uses a specific verb and resource, distinguishing it from sibling tools like get_optimal_persona.
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 mentions 'Admin only' which provides a usage condition, but lacks explicit when-not-to-use or alternative tools. No guidance on whether this should be called before other operations.
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; the description lacks information on side effects, destructive nature, or system changes beyond opening. The return format is given, but behavioral context 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 relatively short and front-loaded with purpose. The mixed Japanese/English may reduce clarity, but overall it's efficient with bullet-style Arg/Returns sections.
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 zero schema coverage and no annotations, the description should provide more context about behavior, error cases, and required permissions. The existing prereqs and return format help but are insufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It lists three parameters with brief meanings, but contradicts the schema by marking 'caller_agent_id' as required when schema allows null. This misinformation reduces reliability.
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 opens a worktree with an AI tool using the 'gtr ai' command. It specifies prerequisites (gtr installed, owner/admin) and distinguishes from sibling worktree tools that create or list worktrees.
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 (with gtr installed and owner/admin role) but does not explicitly state when not to use or mention alternative tools like 'create_worktree' or 'open_session'.
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; description only mentions force parameter and return format. Lacks details on irreversibility, side effects, or prerequisites for a destructive 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?
Description is well-structured with purpose, note, args, and returns. Two sentences are efficient, but could be shortened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, description covers input and output but misses behavioral context like error conditions, cleanup requirements, or impact on repository state. Adequate but not comprehensive.
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 0% schema coverage, description adds meaning by naming and describing each parameter in Args section, but incorrectly states caller_agent_id as required while schema allows null. Provides basic semantics but incomplete.
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 'git worktreeを削除する' (delete git worktree), with a clear verb and resource. It distinguishes from sibling tools like create_worktree, list_worktrees, etc.
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 note '※ Owner と Admin のみ使用可能' provides a usage restriction but no explicit guidance on when to use versus alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the return structure (success, entries, count) and permission requirement. Since annotations are absent, the description carries the full burden; it covers key behavioral aspects for a read-only search 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?
Well-structured with Args and Returns sections, no fluff. Could be slightly more concise, but all sentences add 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?
Covers basic purpose, permissions, and return format. With 4 parameters and no annotations, it adequately explains the tool but lacks mention of pagination or behavior for large result sets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Lists all four parameters with brief descriptions, compensating for 0% schema coverage. However, it claims caller_agent_id is required, conflicting with the schema where it's optional with a default of null. Also lacks details on tag format and limit default (10).
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?
Clearly states it searches the global archive across all projects. The verb 'search' and resource 'global memory archive' are specific. However, it does not explicitly distinguish from 'search_memory_archive', which likely searches per-project archives.
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?
Provides a permission constraint (Owner/Admin only) and a required parameter caller_agent_id, but offers no guidance on when to use this tool versus similar siblings like list_global_memory_archive or restore_from_global_memory_archive.
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 key behaviors: broadcast via receiver_id=None, priority levels, message type examples, and return value structure. Lacks info on authentication or error details but sufficient for a simple messaging tool given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and well-structured. Purpose and parameter list are front-loaded. Every sentence serves a clear purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters and return structure. Output schema is referenced in description (though not inline). Missing usage context but adequate for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning to parameters (e.g., priority levels, message_type examples, broadcast). However, it incorrectly marks caller_agent_id as required (must) while schema allows null, creating a contradiction that reduces reliability.
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 'Send messages between agents' (specific verb+resource). However, it does not explicitly differentiate from sibling tools like send_command or broadcast_command, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., send_command, broadcast_command). Missing context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool is admin-only and returns success, assignments, and count, but omits critical details such as behavior when no workers are available, whether the operation is synchronous, prerequisites, or error handling. The description is insufficient for safe 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 with the core purpose front-loaded, followed by a usage note and simple arg/return list. It wastes no words, though the mixed language (Japanese and English) slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description provides basic context. However, the contradiction regarding the required parameter and the lack of behavioral details (e.g., what happens if called without proper permissions or with invalid agent ID) make it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains that caller_agent_id is required (must), but the schema marks it optional with a default of null, creating a contradiction. Beyond that, no additional parameter context is provided. The description adds some meaning but is undermined by the contradiction.
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: 'Automatically assign tasks to available workers.' This is a specific verb+resource combination that distinguishes it from sibling tools like assign_task_to_agent (manual assignment) and create_task (creation only).
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 mentions 'Admin only' as a usage restriction, providing clear context for when the tool can be used. However, it does not explicitly contrast with alternative tools or specify when not to use it.
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 provides some behavioral traits: returns error if tasks incomplete, force flag overrides, owner-only restriction, and repo_path used for worktree deletion. However, it lacks details on side effects, destructive nature, or exact cleanup behavior, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a brief summary line followed by a clear bullet-style argument list. Every sentence adds value, and the structure is easy to parse.
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 3 parameters and an output schema, the description covers the main behavior, conditions, and key parameters. However, it omits details about the output format, error types, and whether the operation is reversible, leaving some contextual gaps.
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 description explains all three parameters in plain language, adding context beyond the bare schema (which has 0% coverage). Notably, it marks caller_agent_id as required despite schema default null, a critical semantic addition.
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 'Clean up workspace when all tasks are completed,' specifying the condition and action. It also mentions error behavior and force flag, differentiating it from siblings like cleanup_workspace, though lacking explicit sibling comparison.
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 gives clear conditions: use when all tasks are complete, otherwise error unless force=True. It also notes owner-only usage. However, it does not compare with alternative tools like cleanup_workspace or check_all_tasks_completed, leaving usage decision partially ambiguous.
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 discloses the destructive nature (delete) and user restrictions, and mentions the return structure. However, it lacks detail on side effects, reversibility, or constraints beyond user roles.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with clear sections (description, args, returns). Front-loaded with purpose and important restrictions. One extra sentence could explain the scope further, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, destructive operation) and many sibling memory tools, the description covers basics but lacks differentiation from delete_memory_entry and has an error in parameter requiredness. Output schema exists, so return details are less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description adds meaning to parameters. It explains 'key' and 'caller_agent_id', but incorrectly marks caller_agent_id as required while the schema lists it as optional with default null. This contradiction reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it deletes a global memory entry across all projects, with specific verb 'delete' and resource 'global memory entry'. It also distinguishes from siblings by noting the global scope and user restrictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies that only Owner and Admin can use this tool, but does not provide guidance on when to use this versus alternatives (e.g., delete_memory_entry) or when not to use it. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns summary information (success, summary) and implies a read-only operation. However, with no annotations provided, it fails to mention any access requirements, rate limits, or potential side effects, which would be expected for a tool operating on shared global state.
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 brief and includes structured Args/Returns sections. However, it mixes Japanese and English, and the required flag conflict adds unnecessary noise. Overall, no wasted sentences, but minor redundancy could be trimmed.
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 a single parameter, no annotations, and an existing output schema, the description covers the basic functionality and return shape. However, it omits context about safe invocation, concurrency, or prerequisites, leaving some gaps for a tool that accesses shared global memory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the parameter 'caller_agent_id' as the calling agent ID and marks it as required. However, the input schema shows a default null and allows null, making it optional. This contradiction between description and schema undermines clarity and could mislead an agent.
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 global memory summary common to all projects. The verb '取得する' and resource 'グローバルメモリのサマリー情報' are specific, and the context of being common across projects distinguishes it from per-project memory summary tools like get_memory_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?
No explicit when-to-use or when-not-to-use guidance is given. The phrase '全プロジェクト共通' implies it is for global scope, but it does not contrast with alternatives such as get_memory_summary or global archive summaries, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates the return fields (success, agents, count, synced_from_file) and implies a read operation (取得する). However, it does not disclose whether the operation is safe, idempotent, or requires any special permissions. No contradiction with annotations as none are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose front-loaded. The Args/Returns structure is clear, though it uses Japanese (still appropriate for the tool's audience). 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?
For a simple list tool with one parameter and an existing output schema, the description gives a useful summary including the notable 'synced_from_file' field. It lacks details on ordering or filtering but is fairly complete for its complexity. The parameter-contradiction reduces completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description identifies the single parameter 'caller_agent_id' as required (必須), but the schema marks it as optional with default null, creating a conflict. Beyond naming, it adds limited meaning. Schema coverage is 0%, so the description should compensate more, but it only provides a brief label.
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 'gets a list of all agents' (全エージェントの一覧を取得する), specifying the verb and resource. It distinguishes itself from sibling tools like create_agent or get_agent_status by focusing on listing all agents, including those saved to file.
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., before creating an agent or checking status). There is no mention of prerequisites, context, or when not to use it.
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 mentions return structure but incorrectly states caller_agent_id as required (schema shows optional), which is misleading. Does not disclose side effects, idempotency, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines for purpose, two lines for args, one line for returns. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, description need not detail return fields, but it does so sufficiently. Missing details like pagination, default sorting, and behavior when no tags are provided. The contradiction about required parameter also reduces completeness.
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 description adds meaning beyond the schema by stating tags are for filtering and caller_agent_id is required. However, the required claim contradicts the schema (both are optional), which slightly undermines reliability.
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 'Retrieve a list of memory entries', specifying the verb (list) and resource (memory entries). This distinguishes it from siblings like get_memory_entry (single), save_to_memory, and search_memory_archive.
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 parameter guidance but no explicit when-to-use or when-not-to-use instructions. It does not compare to alternatives like search_memory_archive or note limitations (e.g., pagination).
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 states the action (reset) and return fields but does not disclose side effects, irreversibility, or impact on other agents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief with clear sections (purpose, restriction, args, returns). No superfluous content, though Japanese-only may limit accessibility.
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?
Provides return fields and parameter description, but lacks details on effects, prerequisites, and fails to resolve the parameter requirement mismatch for a simple reset tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning to the parameter 'caller_agent_id' by stating it is required (must), but the schema marks it optional. This inconsistency reduces reliability.
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 'reset cost counter' with a specific verb and resource. It distinguishes from sibling cost tools like get_cost_summary and set_cost_warning_threshold.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description notes 'Owner only' usage restriction but provides no guidance on when to use this tool versus alternatives, nor when not to use it.
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 cover behavioral traits. It mentions the action and access restrictions but fails to disclose side effects, error handling, or idempotency. The contradiction about caller_agent_id requirement undermines trust.
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 short and to the point, including an access note and parameter descriptions. The 'Args' section is somewhat redundant with the schema but provides Japanese translations. It could be more formalized.
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 nature of the tool (2 parameters), the description covers the basic purpose and access restrictions. However, it lacks details on prerequisites, recovery behavior, and error outcomes. The output schema exists but is not used to reduce burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to parameters by translating and clarifying their purpose (e.g., 'key of entry to restore'). However, it contradicts the schema by stating caller_agent_id is required when it is optional with a default null, reducing accuracy.
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 'restore entry from global archive' and distinguishes from the non-global sibling tool by specifying 'global' and 'common to all projects'. The verb 'restore' and resource 'global archive' 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 explicitly states 'Only Owner and Admin can use', providing a clear access restriction. However, it does not specify when to use this tool versus alternatives like restore_from_memory_archive or other archive operations.
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?
The description contradicts the input schema by marking caller_agent_id as required when it is not in the schema's required array. This is a factual inaccuracy that undermines trust. While it mentions authorization and dangerous commands, the contradiction is a significant flaw.
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 statement, then a usage note, followed by a structured argument list and return format. It is well-organized and easy to scan, though the return description could be slightly trimmed.
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 no annotations and an output schema present, the description covers authorization, parameter details, and return structure. However, it lacks explanations of error cases, side effects, or behavior when commands are invalid, leaving some gaps for a complex broadcast 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 description adds meaning to all four parameters (command, role, allow_dangerous, caller_agent_id) with brief explanations and role valid values, which is helpful given 0% schema coverage. However, the incorrect claim that caller_agent_id is required reduces clarity and utility.
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: broadcasting a command to all agents or specific roles. It distinguishes from sibling tools like `send_command` which likely targets a single agent, making the purpose distinct 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 specifies that only Owner and Admin roles can use the tool, and explains the role parameter with valid values. It provides context on when to use it but lacks explicit alternatives or when-not-to-use 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 bears full responsibility for behavioral disclosure. It indicates this is a read operation (listing entries) and specifies the caller_agent_id is required. However, it does not mention any side effects, performance implications, or details about the archived state, leaving some gaps for a tool that might have subtle behaviors.
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, using a short Japanese sentence followed by structured Args/Returns. It avoids fluff and clearly separates parameter details and return structure, making it easy 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 tool's simplicity (2 parameters, list operation) and the presence of an output schema (mentioned in context), the description adequately covers the necessary information: purpose, usage constraint, parameter explanations, and return format. The sibling tools context shows many memory-related tools, but this one's purpose is sufficiently unique.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no parameter descriptions), so the description must compensate. It does so by explaining limit as 'max number of results with default 50' and caller_agent_id as 'required'. This adds meaningful context beyond the schema's raw types and defaults.
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 retrieves archived memory entries ('アーカイブされたメモリエントリ一覧を取得する'). While it doesn't explicitly differentiate from siblings like list_memory_entries (likely non-archived) or search_memory_archive, the term 'archive' in the tool name and description provides sufficient distinction.
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 includes an important usage constraint: only Owner and Admin can use this tool. However, it does not provide guidance on when to use this tool versus alternatives like list_memory_entries or search_memory_archive, nor does it mention when not to use it.
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 mentions the return structure (success, templates, categories) but does not state whether the tool is read-only, any authentication requirements, rate limits, or side effects. The read-only nature is implied by the name but not 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?
The description is concise and well-structured, with clear sections for the overall purpose and Args/Returns. Every sentence adds value; 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?
Given the tool's simplicity (1 parameter, optional, has output schema), the description provides adequate context: lists the three categories and output fields. It does not explain how to use the output further or reference the sibling tool for individual templates, but is largely complete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a Japanese explanation for the sole parameter 'caller_agent_id' as '呼び出し元エージェントID（必須）', adding meaning beyond the schema which only shows type and default. However, it claims the parameter is required while the schema shows it is not (default null, no required list), creating a contradiction. The schema description coverage is 0%, so description partially compensates but the contradiction reduces reliability.
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: retrieving a list of available report templates. It also mentions the three categories (code survey, integrated report, general survey), which adds specificity. The tool name 'list_report_templates' distinguishes it from sibling 'get_report_template' (singular).
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 when a list of templates is needed, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any 'when not to use' guidance. The sibling tool 'get_report_template' exists, but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It states it creates a worktree but does not disclose any behavioral traits such as side effects, prerequisites (e.g., existence of repo), or whether it is safe to re-run. It also claims caller_agent_id is required, contradicting the schema where it is optional with a default of null.
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: two lines of purpose, then well-structured Args and Returns sections. Every sentence adds value, and it is front-loaded with the main action. The authorization note is an important addition without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the return format and lists arguments, but lacks preconditions (e.g., must have an existing git repository) and error handling details. Given the complexity (6 params, no annotations, output schema exists), it is somewhat incomplete but still usable.
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 0%, so the description must compensate. It provides brief descriptions for parameters: repo_path, worktree_path, branch, etc. It adds condition for base_branch ('only valid when create_branch=True') and default for create_branch, but does not provide format, constraints, or examples for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '新しいgit worktreeを作成する' (Create a new git worktree). This is a specific verb and resource, and it distinguishes from sibling tools like list_worktrees and remove_worktree which have different actions.
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 notes that only Owner and Admin can use this tool, providing important authorization guidance. It does not explicitly mention when to use alternatives, but the 'create' verb implies its use case, and sibling tools cover other operations like listing or removing worktrees.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses it reads from a template and returns a guide, implying read-only behavior. However, it incorrectly marks caller_agent_id as required in text while schema says optional, and does not explain error conditions. No side effects are mentioned.
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 short, well-structured with sections for Args and Returns, and uses bullet points. It is efficient with 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?
For a simple retrieval tool, the description covers the purpose, parameters, and return type. The presence of an output schema reduces the need to detail the return structure. Minor gaps like error handling are acceptable given the tool's simplicity.
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 0%, so the description must add meaning. It adds valid values for role ('owner, admin, worker'), which is helpful. For caller_agent_id, it says 'required' contradicting the schema (optional with default null). This adds some value but with inaccuracy.
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 role-specific behavior guide from a template file. It specifies the resource (role guide) and action (get), distinguishing it from siblings like list_role_guides which lists guides.
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 basic usage context by listing arguments and return type, but does not explicitly state when to use this tool versus alternatives (e.g., list_role_guides for listing). 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?
Discloses authorization requirement and return format (success, entries, count), but does not mention potential side effects (none likely) or pagination behavior. With no annotations, description partially covers transparency but lacks detail on rate limits or data scope.
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: one sentence for purpose, a note, then clearly labeled args and returns. 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?
For a 2-parameter list operation, description covers purpose, access, parameters, and return fields. Lacks explanation of 'archive' distinction from current memory, but output schema (not shown) likely provides additional structure. Adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Provides descriptions for both parameters (limit max results default 50, caller_agent_id required) despite 0% schema coverage. However, there is a contradiction: schema marks caller_agent_id as optional with default null, but description says it's required (必須). This undermines reliability.
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 retrieves a list of global archive entries common to all projects, and distinguishes from siblings like 'list_global_memory_entries' (which lists current global memory) by using 'archive' and noting owner/admin restriction.
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 access restriction (Owner and Admin only) but does not explicitly guide when to use this vs alternatives like 'search_global_memory_archive' or 'list_global_memory_entries'. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool launches a terminal CLI and requires Owner/Admin role. However, it does not mention side effects, reversibility, or potential environment requirements. More behavioral context 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 well-structured with a clear one-line summary, detail paragraph, and formatted Args list. It is front-loaded. Minor redundancy: the first two sentences convey similar information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, constraints, parameters, and return structure (including key fields). Given moderate complexity and output schema presence, it is fairly complete. Could add error scenarios or more explicit prerequisites.
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 has no descriptions (0% coverage), but the description's Args block fully explains each parameter's purpose, valid values, defaults, and dependencies (e.g., custom_prompt only relevant for custom/file types). This adds significant 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 initializes an agent and launches AI CLI with a role template. It mentions the prerequisite (agent created with create_agent) and the action. However, it does not explicitly differentiate from sibling tools like create_agent or terminate_agent, though the purpose is distinct.
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 usage context: only Owner and Admin can use, and it details prompt_type options (auto, custom, file). It implies usage after create_agent but does not explicitly state when not to use this tool or compare with alternatives. No exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the deletion action and the return format (success, task_id, message or error), and mentions the user role restriction. However, it does not describe potential side effects (e.g., cascading deletions) or irreversibility, leaving some ambiguity.
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, front-loaded with the core action, then provides permission info and a structured argument/return list. It mixes Japanese and English but remains clear. A minor deduction for not fully explaining the contradiction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool, the description covers the essential: what it does, who can use it, parameters, and return format. An output schema exists (though not shown), which complements the description. It could elaborate on post-deletion effects, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning by labeling parameters in Japanese. However, there is a contradiction: the description marks 'caller_agent_id' as required, but the input schema lists it as optional with a default of null. This misleads the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'タスクを削除する' (Delete a task), using a specific verb and resource. Among sibling tools, it uniquely identifies the deletion action, distinguishing it from create, reopen, update, etc.
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 includes a permission note 'Owner と Admin のみ使用可能' (Only Owner and Admin can use), providing a clear usage constraint. However, it does not explicitly state when to use this tool versus alternatives or mention when not to use it.
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, but the description discloses the tool's behavior: checks task counts, treats failed tasks as incomplete, and is restricted to the owner. It also lists return fields, providing good transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for purpose, conditions, access, arguments, and returns. It is reasonably concise, though the Japanese and English mix could be streamlined.
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, the description covers purpose, behavioral conditions, access control, parameter meaning, and return fields. An output schema exists, but the description adequately explains return values. The tool is simple and the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter caller_agent_id is described as '必須' (required) but the input schema allows null and has no required list, creating a contradiction. The description adds no additional semantic context beyond the schema's name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if all tasks are completed, defines completion conditions (pending=0, in_progress=0, failed=0), and excludes tasks with failed status. This distinguishes it from sibling tools like get_task_queue or list_tasks.
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 mentions 'Owner のみ使用可能' (owner only), providing a usage condition. However, it does not specify when to use this tool versus alternatives like check_gtr_available or get_task_status, leaving the context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the search location (templates/ directory) and file type (.md), which is sufficient for a simple read-only tool. However, it does not explicitly state that the operation is non-destructive or mention any permissions.
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, front-loading the purpose, and uses a clear structure with Args/Returns sections. 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?
For a simple list tool with an output schema (not shown), the description covers functionality well. It does not mention error cases or assumptions, but overall is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides context for the sole parameter (caller agent ID) and marks it as required. However, the schema allows null default (optional), creating a contradiction. This misguidance reduces the usefulness.
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 retrieves a list of available role guides and explains the mechanism (searches for .md files in templates/ directory). This distinguishes it from siblings like get_role_guide.
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 when a list of role guides is needed, but does not provide explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses authorization constraints and return fields. However, it does not explicitly state that the operation is non-destructive or that it has no side effects, but the 'get' verb implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear structure: purpose, note, then Args/Returns sections. 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 that an output schema exists (not shown), the description adequately covers the tool's purpose and basic parameters. It could include more context like that it retrieves recent output or is used for monitoring, but 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?
Description adds meaning to parameters, specifying default for lines and roles for agent_id and caller_agent_id. However, it inaccurately marks caller_agent_id as required while schema lists it as optional with default null, reducing reliability.
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 gets the tmux output of an agent, using specific verb and resource. It is easily distinguishable from sibling tools like read_screenshot or read_messages.
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 mentions that only Owner and Admin can use, providing authorization guidelines. However, it does not explain when to use this tool versus alternatives or when not to use it.
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 terminates all agents and releases resources, and specifies the return structure. However, it does not detail side effects (e.g., impact on ongoing sessions), reversibility, or authorization beyond the Owner note.
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, covering purpose, effects, usage note, arguments, and returns in a compact form. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is destructive and has an output schema, which is described. However, the description omits details like validation of caller_agent_id, effects on partially completed tasks, and error handling. The contradiction between required in description and optional in schema also indicates incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the only parameter 'caller_agent_id' by calling it required, but the schema marks it as optional (default null). This inconsistency reduces reliability. Schema coverage is 0%, so the description compensates partially, but the contradiction undermines clarity.
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 clean up the workspace by terminating all agents and freeing resources. It distinguishes from siblings like 'terminate_agent' which handles individual agents, and 'cleanup_on_completion' which likely cleans up after a single task.
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 includes a crucial usage note: only the Owner can use this tool. However, it does not explicitly state when to use it versus alternatives like 'terminate_agent' or 'cleanup_on_completion', nor does it mention prerequisites or when not to use it.
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 the recovery process: terminating the old agent, removing worktree, creating new ones, and reassigning tasks. This gives the agent complete behavioral understanding.
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 steps and front-loaded purpose. It is concise but could be slightly shorter without losing 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 complexity and presence of an output schema, the description adequately explains the tool's behavior and prerequisites (admin). Missing comparison to 'attempt_recovery' or side effects, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists 'caller_agent_id' as required, but the input schema shows it is optional (default null). This contradiction misleads the agent. Schema description coverage is 0%, so the description should compensate but instead adds incorrect information.
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 performs 'complete recovery of an abnormal agent' with a list of steps (terminate, remove, create, reassign), distinguishing it from siblings like 'attempt_recovery' by its comprehensive nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Admin only' usage, providing clear authorization context. It does not explicitly state when not to use it or alternatives, but the steps imply it's for abnormal agents needing full recreation.
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 clearly indicates this is a read operation (retrieving template content) and describes the return value structure (success, template_name, category, content, or error). No hidden behaviors are mentioned, but the description is adequate for a simple retrieval.
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 main purpose and uses a structured docstring format. It is fairly concise, though it repeats argument descriptions that are already in the input schema. The line breaks and separate sections (Args, Returns) make it easy to parse.
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 the contradiction regarding caller_agent_id, the description covers all essential aspects: purpose, parameters (with format guidance for template_name), usage instructions, and return value structure. Since an output schema exists, the Returns section provides additional clarity. The description is complete for this 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 0%, so the description must compensate. It adds value for 'template_name' by specifying format (no extension) and examples. However, it incorrectly states that 'caller_agent_id' is required, while the schema shows it is optional with a default of null. This inconsistency reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'レポートテンプレートの内容を取得する' (get content of a report template) and explains it returns the full template text. This distinguishes it from sibling tools like 'list_report_templates' which only list templates, not retrieve content.
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 instructions on how to use the template (copy and replace placeholders) and lists the arguments. However, it does not explicitly state when to use this tool versus alternatives like 'list_report_templates', though the context implies it.
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 that the tool searches entries moved by prune and specifies the access restriction. It also summarizes the return structure (success, entries, count). However, it does not mention whether the operation is read-only or any other behavioral traits like rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sections: purpose, note about prune, access, Args, and Returns. Every sentence adds value, and the structure is clear and easy to scan.
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 (4 params, 1 required, no enums) and the existence of an output schema, the description adequately covers purpose, access, and parameter meanings. However, it lacks examples or edge-case guidance, and the caller_agent_id contradiction slightly undermines 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 0%, so the description must compensate. It provides brief explanations for each parameter: query (search query), tags (optional filter), limit (max results), caller_agent_id (caller agent ID). However, it incorrectly states that caller_agent_id is required (must), while the schema shows it as optional with default null. This contradiction reduces clarity.
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 searches archived memory entries, specifically those moved by prune. This distinguishes it from sibling tools like list_memory_archive (list all) and restore_from_memory_archive (restore). The verb 'search' and resource 'archived memory' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that only Owner and Admin can use this tool, providing a clear access guideline. However, it does not discuss when to use this tool versus alternatives (e.g., when to search vs list), nor does it mention when not to use it.
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 reveals that persistence is limited to `.multi-agent-mcp/.env` file's `MCP_MODEL_PROFILE_ACTIVE` and does not affect `config.json`, which is non-obvious and helpful for understanding side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concisely structured with labeled sections (Args, Returns, Notes). Each sentence provides necessary information without redundancy or superfluous 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?
The description covers the essential aspects: purpose, ownership, parameters, return format, and persistence behavior. The presence of an output schema (not provided in context) reduces the need to detail return values. Minor gaps include lack of error handling details and the parameter requirement mismatch.
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 coverage is 0%, so the description must compensate. It lists each parameter with a description, including possible values for profile ('standard/performance'). However, it erroneously marks caller_agent_id as required ('必須'), while the schema shows it is optional with a default of null, which could mislead the agent.
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 ('Switch model profile') and specifies that only the Owner can use it. Among siblings like get_model_profile and get_model_profile_settings, this stands out as the mutation counterpart, making its purpose distinct.
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 usage context by noting the 'Owner only' restriction and listing required arguments. However, it does not explicitly differentiate when to use this tool versus alternative tools (e.g., get_model_profile to read the current profile).
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; description discloses automatic memory saving and metrics update as side effects. It also mentions dashboard update. Lacks detail on error conditions or reversibility, but overall transparent about key behaviors.
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 adequately structured with a purpose statement and an Args list, but somewhat verbose. Could be more concise by trimming redundant phrasing while retaining necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool has moderate complexity, the description covers main behavior, side effects, and usage constraint. Missing details on error handling or exact dashboard update mechanics, but sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds full semantic meaning for all 5 parameters: explains task_id, status (with enum values), message, summary (defaults to message), and caller_agent_id. This compensates completely for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for Workers to report task completion to Admin, with a specific verb ('報告する') and resource ('タスク完了'). It distinguishes from siblings like 'report_task_progress' by focusing on final completion.
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 'Worker のみ使用可能' (only Worker can use), providing a clear usage constraint. Implicitly differentiates from progress reporting via sibling context, but does not explicitly list 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?
No annotations provided, so description carries full burden. Discloses that progress reports are sent to Admin/Owner, and progress can be auto-calculated with checklist. Does not mention side effects or permissions beyond 'Worker only', but tool is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a brief purpose statement, usage guidance, and an Args section. While somewhat lengthy, each sentence adds value. Front-loaded with primary function.
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 5 parameters (1 required) and no output schema, the description covers all needed context: purpose, who can use, when to report, parameter details, and return format. Also distinguishes from sibling tools implicitly.
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 has 0% coverage (no parameter descriptions), but description provides detailed meaning for all 5 parameters: progress range (0-100, recommended 10% increments), checklist structure (array of objects with text/completed), message purpose, and caller_agent_id as Worker ID. Adds crucial constraints and formatting.
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?
Title and description clearly state 'report_task_progress' and 'Worker がタスクの進捗を報告する' (Worker reports task progress). Distinguishes from sibling report_task_completion by focusing on progress updates rather than final completion. Also specifies that only Worker can use.
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?
Clearly indicates when to use: Worker reports progress every 10%. Mentions that Admin and Owner can monitor in real time. Recommends 10% increments and notes auto-calculation with checklist. Lacks explicit 'when not to use' but context is clear enough.
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 admin-only access, the expected status values, and the return format. It does not mention side effects or idempotency, but it adds significant behavioral context beyond the bare minimum.
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 header, a usage note, and separate Args/Returns sections. It is efficient but could be slightly more concise by removing redundant labels. Overall, it front-loads key info and is easy 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 5 parameters, 2 required, and an output schema, the description covers the tool's purpose, access restrictions, parameter meanings, and return values. It is nearly complete, though it could add more detail on error handling or edge cases. The output schema is described in plain text, which is helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides one-line descriptions for each parameter (e.g., progress range 0-100, error_message for failed). This adds meaning beyond the schema, but the descriptions are minimal and do not explain optionality or dependencies in depth.
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 updates task status and explicitly distinguishes it from the sibling 'report_task_completion' by noting that Workers should use that instead. The verb 'update' and resource 'task status' are 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that only Admin can use this tool and that Workers should use 'report_task_completion' instead. It also provides parameter descriptions that clarify when each parameter is applicable (e.g., 'error_message' for failed status). This leaves no ambiguity about usage context.
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: terminal opening, session creation, pane splitting, conditional attach, gtr auto-configuration, role checks, and return values. This provides comprehensive transparency.
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 Japanese summary, English parameter list, and ASCII art. While slightly lengthy, every section adds value and it is front-loaded with the main 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?
Given the tool's complexity (tmux grid, session management, gtr integration), the description covers inputs, outputs, restrictions, and edge cases (existing sessions). The output schema exists, so return values are adequately described.
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 schema coverage is 0%, but the description's 'Args' section explains each of the 6 parameters in detail (working_dir, open_terminal, auto_setup_gtr, session_id, enable_git, caller_agent_id), adding meaning 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 clearly states the tool's purpose: 'ターミナルを開いてtmuxワークスペース（グリッドレイアウト）を構築する' (open terminal and build tmux workspace with grid layout). It distinguishes itself from siblings like 'cleanup_workspace' by focusing on initialization.
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 usage context: it attaches to existing sessions, auto-configures gtr if available, and restricts usage to 'Owner only'. However, it does not explicitly compare to alternative tools or state when not to use it.
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:

[![multi-agent-mcp MCP server](https://glama.ai/mcp/servers/shiiman/multi-agent-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shiiman/multi-agent-mcp)

Score Badge

Copy to your README.md:

[![multi-agent-mcp MCP server](https://glama.ai/mcp/servers/shiiman/multi-agent-mcp/badges/score.svg)](https://glama.ai/mcp/servers/shiiman/multi-agent-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shiiman/multi-agent-mcp'

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