SysControl MCP

by ks6573

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.16.0
Disambiguation2/5
Many tools overlap in purpose: multiple system-info tools (get_cpu_usage, get_system_alerts, get_full_snapshot, get_hardware_profile), several disk/file analysis tools (find_large_files, summarize_directory, list_directory), and many file-reading variants (read_file, read_file_lines, tail_file, read_document, read_pdf, read_spreadsheet). While descriptions help, the boundaries are blurry and an agent could easily select the wrong tool.
Naming Consistency4/5
The vast majority of tools follow a clear verb_noun snake_case pattern (get_cpu_usage, list_reminders, write_file, create_automation). A few exceptions like 'process_tree' and 'deep_research' break the pattern, but they are minor and do not cause confusion.
Tool Count1/5
With 84 tools, this server is extremely oversized. It expands far beyond system control to include web search, image generation, file editing, reminders, and more. The sheer number makes it difficult for an agent to discover and select among so many options, and many tools could be consolidated or removed.
Completeness3/5
The server aims for broad coverage and mostly achieves it: process lifecycle, file CRUD, automations, connectors, memory, and web search are present. However, there are notable gaps such as no update_reminder, no delete_memory_note, and no process-start tool, leaving some workflows incomplete.
Average 4.2/5 across 84 of 84 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on May 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations: the annotation `destructiveHint: false` indicates the tool is not destructive, but the description says 'Always confirm with the user before running destructive commands,' implying it can be destructive. This is an annotation contradiction, so score is 1 per the rubric.
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 four sentences, each contributing useful information (purpose, enablement, timeout, safety). It is front-loaded with the core purpose and avoids unnecessary filler, though slightly longer than strictly needed.
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 an arbitrary shell execution tool, the description covers key operational details: output fields, safety enablement, timeout range, and destructive-command confirmation. It lacks working-directory or environment context but is generally complete for typical usage. The contradiction slightly detracts from overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it restates the timeout default and max, which the schema already covers, and does not offer new semantic details for the `command` parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute an arbitrary shell (bash) command' with a specific verb and resource, and mentions stdout, stderr, and exit code. This unambiguously differentiates it from sibling tools that focus on specific system metrics.
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 arbitrary shell commands, but does not explicitly provide when/not-to-use guidance or mention alternatives. The context of being disabled by default and the need for user confirmation for destructive commands are useful, but there is no direct comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds valuable context about privacy-preservation and the specific data retention policy, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and a key constraint. Every word adds value, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the annotations cover safety, but the description omits parameter semantics and return format. It is minimally adequate for a read-only getter but lacks detail for full comprehension.
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?
Param schema has 0% description coverage, and the description does not explain either parameter ('tool' filter or 'limit'). Without any compensation, the agent has no information about how to set or use these 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 uses a specific verb ('Return') and resource ('local privacy-preserving tool audit log'), and clearly distinguishes this from sibling resource-monitoring tools by detailing what is recorded (argument names, risk, status, errors) and what is not (argument/result values).
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 explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only states what the tool returns, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present but all false, so the description carries a moderate burden. It adds valuable behavioral context beyond the annotations: process launched without a shell, minimal environment, namespaced tools as <connector>__<tool>, and the allow_connectors prerequisite. These details help the agent predict side effects and operational 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?
Three short sentences, front-loaded with the primary purpose, and no filler. Every clause adds meaningful information 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?
Covers the core purpose, a prerequisite, and important operational details (no shell, minimal env, namespacing). However, it omits parameter behavior and explicit usage distinctions, and with no output schema, the agent has limited understanding of what will be returned or how to handle failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40% (command and inherit_env have descriptions) and the description does not compensate. It provides high-level context about the process environment but never explains key parameters like name, args, or enabled. The agent must rely on sparse schema descriptions 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?
States a specific action ('Configure') on a specific resource ('external stdio MCP server'). Differentiates from sibling tools that list/remove/refresh connectors by clearly implying this creates/configures 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?
Implies usage via 'Configure an external stdio MCP server' and mentions a prerequisite ('Requires allow_connectors'), but does not explicitly state when to use this over sibling tools like list_connectors, remove_connector, or refresh_connectors. No exclusions 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?
Annotations include destructiveHint=true, and the description's 'Delete' aligns with that. The description adds the permission requirement (allow_automations), providing extra context beyond annotations. However, it does not disclose other potential behavioral traits like irreversibility or cascading effects on related runs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences: 'Delete a scheduled automation.' and 'Requires allow_automations.' Every word is purposeful, with no wasted text.
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 one-parameter destructive tool, the description plus annotations (destructiveHint=true) cover the essentials: what it does and a key prerequisite. It could add details about permanence or effects on associated runs, but the tool's simplicity and context make it adequately 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 does not explicitly explain the 'id' parameter, but the phrase 'Delete a scheduled automation' implies the id refers to the automation to be deleted. With schema description coverage at 0%, the description provides minimal parameter guidance, though the single parameter's meaning is easily inferred.
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 'Delete a scheduled automation' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_automation, update_automation, and list_automations.
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 prerequisite ('Requires allow_automations') but does not explicitly discuss when to use this tool versus alternatives, such as using update_automation to disable instead. The intended use is clear from the name and description, but no explicit when/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it reports byte counts and interface status, but does not clarify whether 'total' is since boot, session, or a cumulative counter, nor what interface status entails.
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?
One concise sentence that front-loads the purpose. No wasted words, 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 there is no output schema, the description does a decent job stating what is returned. However, 'total bytes' and 'interface status' are underspecified—could benefit from defining the time period or exact status values. Still, for a simple read-only getter, it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty schema). Baseline for 0 parameters is 4; the description doesn't need to elaborate on 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 it returns total bytes sent/received and network interface status, using the specific verb 'returns' and a clear resource. This distinguishes it from sibling tools like get_network_connections (which covers connections) and network_latency_check (which covers latency).
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_network_connections or network_latency_check. The description simply states what it does without implying a specific context or exclusions.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds useful context about the return content but does not disclose potential edge cases such as behavior for nonexistent PIDs or permission requirements. This adds some value beyond annotations but lacks rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main action and includes a concrete list of return fields. There is no filler or redundancy, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple interface (one parameter, well-annotated as read-only) and the schema covering the only parameter, the description is nearly complete. It lists many return fields but uses 'and more' without enumerating everything, and there is no output schema to fill that gap. Minor incompleteness, but still sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single pid parameter, with a clear description including type, constraints, and source guidance. The tool description adds nothing beyond restating 'by PID'. Since the schema handles the parameter semantics completely, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns detailed information about a specific process by PID, listing concrete details like executable path, command line, and memory breakdown. This distinguishes it from sibling tools like get_top_processes and search_process, which operate at a process-list level rather than a single process detail level.
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 main description does not explicitly state when to prefer this tool over alternatives. However, the input schema's pid parameter description notes to obtain the PID from get_top_processes or search_process, implying a sequential workflow. This is helpful but not an explicit 'use this tool when' guideline, so it remains implied rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that it focuses on 'scheduled' runs and 'recent' results, but doesn't define 'recent' or describe the return format, so additional context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb, object, and purpose without any redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the tool's primary purpose but leaves out important context such as the return value structure (no output schema present) and the definition of 'recent'. It is adequate but not fully complete for agent decision-making.
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, and the description does not mention the 'limit' parameter at all. It fails to compensate for the lack of schema descriptions, despite the parameter being straightforward.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recent scheduled automation results, using a specific verb ('Return') and resource ('scheduled automation results'). It distinguishes from the sibling 'list_automations' (which likely lists automation definitions) by specifying 'runs' and 'scheduled'.
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 phrase 'for audit and diagnosis' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it, so it falls short of the highest rating.
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?
Annotations provide no safety hints (all false). The description adds platform coverage and permission requirement, but does not clarify side effects such as launching a GUI application or whether the call blocks. It does not contradict 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?
Two sentences with the primary action front-loaded. The second sentence provides a critical permission note. No redundant wording or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple open-file operation, the description covers the action, platform scope, and permission requirement. It does not describe return values or error behavior (no output schema), but the low complexity makes this less critical. Still, a note on return type could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning to 'with_app' via 'or in a specific desktop application', but 'path' remains self-explanatory. No format, examples, or constraints are provided for either parameter, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('a file'), and specifies the action context: opening in the default application or a specific desktop application across OSes. This clearly distinguishes it from siblings like read_file (which reads content) and edit_file (which modifies).
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 you want to open a file externally) but does not explicitly contrast with alternatives like read_file or edit_file. It does mention a prerequisite ('Requires allow_file_read'), but there is no explicit when-to-use 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?
Annotations already declare destructiveHint=true, so the description is not required to restate destructiveness. It adds the permission constraint ('Requires allow_connectors') and clarifies the scope is 'external' connectors. However, it doesn't mention reversibility, impact on active connections, or any 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 extremely concise: two short sentences, front-loaded with the action and object. Every word earns its place, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers the core purpose and a key prerequisite. It lacks details about effects or reversibility, but the annotations provide destructive context, and the absence of an output schema means return values don't need explanation. Overall, it is adequately complete for its 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?
The schema has only one parameter, 'name', with no description. The tool description does not explicitly explain the parameter, but the tool name and description make it clear that 'name' refers to the connector to remove. Thus, the description adds contextual meaning beyond the raw schema, though it could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the object ('an external MCP connector'), which distinguishes it from sibling tools like add_connector, list_connectors, and refresh_connectors. The verb+resource structure leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when removing an external MCP connector, but does not explicitly state when to use it over alternatives or mention any exclusions. The permission requirement ('Requires allow_connectors') is a useful but minimal guideline.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't repeat safety traits. It adds context about data provenance (scheduled automations), but doesn't disclose behavior such as time ranges, empty results, or how many trends are summarized.
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?
One concise sentence that front-loads the verb and resource, with no wasted words. It efficiently conveys the tool's function and data source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only summarization tool with one optional parameter and good annotations, the description adequately explains the core purpose and data source. It doesn't describe the output format, but for this simple case it's 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?
The single 'limit' parameter is not mentioned in the description, and schema description coverage is 0%. With low coverage, the description should compensate but fails to explain what the limit applies to (e.g., number of data points, days). The schema's default/min/max help but don't fully clarify semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Summarize' and clearly identifies the resource as 'CPU, RAM, disk, and alert trends.' It also names the source data (scheduled get_full_snapshot or get_system_alerts automations), which distinguishes it from sibling tools that report real-time usage.
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 phrase 'captured by scheduled automations' implies this is for historical trend summaries rather than real-time queries, giving clear context relative to siblings like get_cpu_usage and get_ram_usage. It doesn't explicitly state when not to use it, but the intended scenario is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the permission requirement and notes that it records the result, providing some behavioral context. However, it does not disclose potential side effects of running the automation or any execution details. Annotations already indicate non-read-only, so this is a modest addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys purpose, behavior, and permission in a compact way. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple trigger tool with one parameter and no output schema, the description covers the core purpose and permission. However, it does not mention what the caller should expect after invocation (e.g., a run ID, status), nor does it warn about side effects, which could be significant since running an automation may perform arbitrary actions.
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 only parameter 'id' is a string with no schema-level description. The description implies that this id identifies the automation to run, which is useful, but it does not explicitly explain the id's format, source, or how it relates to 'configured automation.' With 0% schema description coverage, the description only partially compensates.
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 'Run a configured automation immediately and record the result,' using a specific verb and target resource. It distinguishes this tool from siblings like list_automations or run_agent by focusing on executing an already-configured automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (to run a configured automation now) and mentions the required permission (allow_automations). It does not explicitly name alternatives or when-not-to-use scenarios, but the phrase 'configured automation' helps differentiate from similar 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?
Annotations already indicate this is a mutating operation (readOnlyHint=false). The description adds the permission requirement 'Requires allow_automations', which is context beyond the annotations. However, it does not disclose other behavioral details such as whether the change takes effect immediately, whether it is reversible, or what happens to a currently running automation. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence plus a permission note. It contains no filler or redundant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update operation with only two parameters and no output schema, the description covers the essential action and a key prerequisite. It could benefit from mentioning the return value or any side effects, but given the low complexity, it 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 description coverage is 0%, so the description must compensate for explaining the parameters. The description does not explain that 'id' is the automation identifier or that 'enabled' determines whether the automation is active (true) or inactive (false). The parameter names are somewhat self-explanatory but lack the clarity needed for an agent to confidently invoke the tool without additional inference.
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: enabling or pausing a scheduled automation. The verb 'Enable or pause' is specific and the resource 'scheduled automation' is well-defined, distinguishing it from sibling tools like create_automation, delete_automation, or run_automation_now.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you want to change the enabled state of an existing scheduled automation. It also notes the required permission 'allow_automations', which is useful. However, it does not explicitly name alternative tools or explain when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses important behavioral traits: default recoverability on macOS (Trash), a permanent deletion flag, a safety scope limited to home directory, and an authorization prerequisite (requires allow_file_write). This adds significant context about consequences, permissions, and constraints that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear first sentence ('Delete a file or directory.'), followed by two compact sentences providing platform-specific behavior and safety/permission context. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the core behavior, platform nuance, a safety limitation, and an authorization requirement. The only notable gap is that non-macOS behavior is not addressed (it says 'On macOS' but doesn't state default behavior on other operating systems). Overall, it is sufficiently complete given the tool's simplicity and existing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with descriptions: 'path' and 'permanent' (including its default false and meaning). The description repeats the permanent/Trash behavior but adds no new semantic detail beyond what the schema provides. Since schema coverage is 100%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a file or directory') with the specific resource and additional scope ('only allows deletion within the home directory'). While it does not explicitly name sibling tools or contrast with alternatives, the verb+resource combination is unambiguous and effectively distinguishes this from move/copy operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the core function and provides useful context (macOS Trash behavior, safety restriction to home directory, and the require allow_file_write permission). However, it does not explicitly state when to choose this tool over alternatives or list exclusions (e.g., when to prefer move_file). The safety and config notes offer implied conditions, but no direct 'use this when...' 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the scope of the snapshot (which subsystems are included) but does not disclose potential performance impact or the point-in-time nature beyond the word 'snapshot'. It adds some context but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and lists components with no wasted words. Perfectly structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description adequately explains what the tool returns. It is complete enough for a simple snapshot tool, though it could optionally mention the output format or note that it is a combined call. The annotations cover safety, making this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Baseline for 0 params is 4, and the description does not need to explain parameters. No additional semantic value is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns a full system snapshot' and explicitly lists the included components (CPU, RAM, GPU, disk, network, top processes). This distinguishes it from sibling tools like get_cpu_usage and get_ram_usage, which are individual metric getters.
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 use for a comprehensive overview but does not explicitly state when to prefer this over individual getter tools. No alternatives or exclusions are mentioned, so guidance is only implied by the 'full system snapshot' wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read-only operation. The description adds useful behavioral detail: defaulting to unstaged changes, the staged flag, and file path scoping, which goes beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with no wasted words. Each sentence adds meaningful information: purpose, default mode, and optional scoping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only git command, the description is complete. Both parameters are covered, no output schema is needed, and annotations cover the safety profile. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra clarity by explaining the default for staged (false) and the meaning of path scoping, which enriches the parameter semantics beyond the schema's own 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?
The description clearly states the tool shows git diff output for a repository, with a specific verb and resource. It distinguishes from generic system tools but does not explicitly contrast with the sibling git_status, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default behavior (unstaged changes) and how to switch to staged changes, plus path scoping. However, it does not provide explicit guidance on when to use this over git_status or other alternatives, only implying 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that automations are 'persisted' and that next run times are returned, but provides no extra side-effect, permission, or rate-limit context. With strong annotation coverage, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence with no redundant content. It clearly states the action, target, and what information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description partially explains return values by mentioning next run times. For a simple zero-parameter list operation with strong annotations, this is sufficient context, though it could be more explicit about the full list structure (e.g., IDs, names, schedules).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Since there are no parameters, the description cannot add parameter semantics, and the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource ('persisted scheduled automations') and includes return details ('next run times'). It distinguishes itself from sibling list_automation_runs by focusing on automation definitions rather than run history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing all scheduled automations but provides no explicit when-to-use or when-not-to-use guidance. There is no mention of alternatives like list_automation_runs or relationship to create_automation, so the agent must infer context from the name.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns 'latest connection state', which is a useful output detail, but it does not disclose any additional behavioral traits (e.g., network calls, freshness of state). With annotations present, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and object. It is front-loaded, contains no filler, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, robust annotations, and no output schema, the description is nearly complete. It specifies the resource and the kind of state returned, though it could optionally elaborate on the structure of the 'connection state' data, but this is not required for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and covers 100% of the inputs. Per the baseline for 0 params, the description need not add parameter details; however, it adds context about what is being listed (configuration and connection state), which is meaningful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('configured external MCP connectors') and adds 'their latest connection state' to clarify the scope. It clearly distinguishes from sibling tools like add_connector, remove_connector, and refresh_connectors, which are mutations.
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 as a read-only listing operation, but it does not explicitly state when to use it vs alternatives or mention that add/remove/refresh are for modifications. With sibling tools present, more explicit guidance would improve this.
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 annotations present (readOnlyHint=false, destructiveHint=false), the description adds value by disclosing the configuration requirement and clarifying behavior when dst is a directory. It does not mention overwrite behavior details, but annotations already signal non-read-only and non-destructive, so this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and every sentence provides relevant information without fluff.
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 no output schema and the description does not mention what happens on success, errors, or the default overwrite behavior when dst exists. Given the low complexity and good annotations, this is a clear gap but not severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented. The description adds extra meaning for dst by explaining that if it's a directory, the source filename is preserved, which goes beyond the schema's simple type/description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Copy a file to a new location') with the resource (file). It distinguishes from sibling tools like move_file by explicitly using 'copy' rather than 'move', and from write_file by implying an existing source.
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 useful context about destination behavior and a prerequisite (allow_file_write), but it does not explicitly mention when to prefer this tool over alternatives like move_file. The usage context is implied rather than explicitly contrasted.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds the 'static' characteristic, suggesting stable data, but provides no other behavioral context such as permission requirements or potential platform differences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence concisely lists all returned content with no filler or redundancy. Information is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, static, read-only tool with no parameters and no output schema, the description fully enumerates what is returned. No further context is needed; annotations cover safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly indicates no inputs are needed by not mentioning any, and the empty schema is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns static hardware specifications' and enumerates the exact attributes (CPU model, core count, RAM, GPU, disk, OS). This verb+resource phrasing distinguishes it from dynamic usage tools like get_cpu_usage or get_ram_usage.
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 word 'static' implies use for one-time hardware queries rather than real-time metrics, but the description does not explicitly mention alternatives or when to prefer this tool over similar siblings like get_hardware_profile. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context about sorting by CPU or memory and the top-N concept, which goes beyond the annotations without contradicting them. It does not disclose return format, but that is low risk for a read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and valuable details. It is concise with no unnecessary words or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only query tool with full schema annotations and no output schema, the description is complete enough. It clearly conveys what the tool returns and the key options, and the annotations cover safety and idempotency. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (n and sort_by) fully documented including defaults and constraints. The description adds minimal extra meaning beyond the schema, essentially restating the sorting behavior. Baseline 3 is appropriate since schema carries the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the top N resource-hungry processes sorted by CPU or memory usage, which is specific and distinct from sibling tools like get_cpu_usage or get_ram_usage that report system-wide usage rather than per-process lists. It uses a specific verb ("Returns") and names the resource and sorting criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing top resource-consuming processes but does not explicitly mention alternatives or when not to use it. Given the sibling tools include get_process_details, search_process, and process_tree, the lack of explicit guidance leaves room for ambiguity, though the purpose is fairly self-evident.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety profile is covered. The description adds no additional behavioral context such as return format, ordering, or performance characteristics, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded, containing no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and strong annotations, the description is complete for a simple listing operation. It unambiguously states what is listed and how those tools were installed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There are no parameter semantics to elaborate on, and the schema correctly represents an empty object.
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 specific verb 'Lists' and the resource 'all custom tools installed via create_tool', distinguishing it from other list_* siblings by focusing on custom tools created via a specific mechanism.
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 (to list custom tools created via create_tool) but does not explicitly mention when to use it vs alternatives or provide any exclusions. No alternative tool is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, open-world, and non-idempotent behavior. The description adds valuable context beyond these by disclosing the authentication prerequisite and the underlying OS-specific commands, which could affect failure modes. It does not contradict annotations and enriches the behavioral picture, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both information-dense. The first sentence states the primary action and permission requirement; the second adds platform-specific commands. Every clause contributes to understanding the tool, and there is no repetitive or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set (1 param), no output schema, and existing annotations, the description covers the essential operational aspects: action, permission prerequisite, and platform behavior. It could mention potential error handling or return status, but for a straightforward browser-opening tool, the context is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, 'url', already has a thorough description including the https:// default assumption. The tool description adds no additional parameter semantics beyond referencing 'URL' in the action. With full schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action with a specific verb and resource: "Open a URL in the user's default browser as a new tab/window." This distinguishes it from siblings like web_fetch (which retrieves content) and open_file_at_path (which opens local files), leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool by noting the prerequisite: "Requires prior browser permission (grant_browser_access)." It also adds platform-specific implementation details (macOS `open` vs. webbrowser module), but does not explicitly contrast it with alternatives or state when not to use it. This is clear usage context without formal exclusions, fitting a 4.
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?
Annotations already indicate the operation is not read-only and not destructive. The description adds the context that it targets a pending reminder and requires an ID, but it doesn't disclose potential side effects, error behavior, or idempotency. This is sufficient for a simple cancel operation but lacks deeper behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately communicates the purpose and the key procedural detail (where to get the ID). No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, and annotations provided), the description covers the essential aspects: what it does and how to obtain the required ID. It doesn't mention return values or edge cases (e.g., reminder not found), but these are less critical for a straightforward cancel operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a complete description of the 'id' parameter (8-character hex string). The description adds significant value by explicitly telling the user to get the ID from set_reminder or list_reminders, which clarifies the parameter's origin and format beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Cancel), the resource (a pending reminder), and the mode of identification (by its ID). It also distinguishes itself from sibling tools like set_reminder and list_reminders by indicating the ID can be obtained from those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that the tool is for canceling a pending reminder and instructs how to acquire the necessary ID. While it doesn't explicitly discuss when not to use it or alternatives, the guidance is specific and actionable, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds critical safety context: it defaults to dry_run so nothing is removed without explicit opt-in, and it requires allow_file_write when dry_run is false. This discloses auth needs and default behavior, going beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word earns its place. It avoids fluff while conveying purpose, safety, and permissions.
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 tool with only two simple parameters, an existing output schema is not necessary. However, the description doesn't explicitly state what the dry-run output looks like (e.g., list of files). Still, it covers safety and permission, making it adequately complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names 'dry_run' and implies 'older_than_days' via 'N days', but doesn't fully explain the parameters or their constraints. The defaults are already in the schema, but the description adds some meaning by explaining the effect of dry_run.
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 function: 'Find or delete files in ~/Downloads older than N days.' It specifies a specific verb (find/delete), a resource (files in ~/Downloads), and a condition (older than N days), making it distinct from sibling tools like delete_file or find_large_files.
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 batch cleanup of old downloads but does not explicitly contrast with alternatives or define when not to use it. The dry-run default and permission requirement provide context, but there's no mention of when to prefer this over delete_file or find_large_files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, which aligns with a creation operation. The description adds valuable context beyond annotations: the need for allow_automations, the restriction to read-only tools, and the local and recurring nature of the automation. This enriches the behavioral profile without contradicting the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and purpose, followed by essential constraints. Every sentence carries meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and moderate annotations, the description covers the core behavior, permission, and restrictions. It does not explain return values or edge cases, but the presence of sibling automation tools and the clarity of the creation task make this sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (name, tool, interval_minutes all have descriptions; arguments lacks one). The description adds context about the tool parameter being read-only but does not elaborate on the arguments object or other parameters. At 75% coverage, the baseline of 3 is appropriate; the description contributes only marginal additional meaning.
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 begins with a specific verb and resource: 'Create a recurring local automation that runs a read-only SysControl tool.' It clearly distinguishes this from sibling tools like list_automations, update_automation, and delete_automation by focusing on creation and adding constraints (recurring, local, read-only tool).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the permission requirement 'Requires allow_automations' and specifies what cannot be scheduled ('Mutating, destructive, extension, and automation tools cannot be scheduled'). This gives clear boundaries on when to use the tool, though it does not name alternative tools for retrieval or updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the recursive creation of parent directories and the permit requirement, adding value beyond annotations. However, it does not mention behavior when the directory already exists or error handling, but the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the primary action, then adds the parent-directory nuance and permission requirement 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?
For a simple tool with one parameter and no output schema, the description covers purpose, permissions, and recursive behavior adequately. It does not specify return values or existence-handling, but these are not critical for a basic directory creation 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 input schema already fully describes the path parameter as 'Absolute or home-relative path for the new directory.' The description adds no additional parameter context beyond this, so the schema carries the semantic load, matching the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Create a new directory' with the additional detail of creating missing parent directories, clearly distinguishing it from sibling file tools like list_directory or delete_file. The verb+resource is explicit 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 clearly indicates this tool is for creating directories and notes the prerequisite allow_file_write permission, providing clear context. It doesn't explicitly state when not to use it or name alternatives, but for a directory creation tool this is sufficient context given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only, not idempotent, and not destructive. The description adds valuable context beyond annotations by noting the permanent installation, the required config flag, and the need to restart the agent. This is genuine behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding unique information: the core action, the prerequisite, and the post-condition. No redundant filler or repetition of schema details.
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 tool with five parameters, a nested schema, and no output schema, the description provides the key operational context: persistence, configuration prerequisite, and restart requirement. It does not explicitly describe error behavior or return values, but the absence of an output schema reduces the need. Overall adequate and well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter meanings are fully documented in the schema itself. The description does not add extra parameter-specific guidance, but the high coverage means the schema carries the burden. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Generates, validates, and installs a new MCP tool permanently into the server.' This is unique among siblings, none of which create tools. No ambiguity or tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by stating the prerequisite configuration ('Requires allow_tool_creation: true in ~/.syscontrol/config.json') and the post-condition (tool available after restart). It does not explicitly name alternatives or exclusions, but no sibling tool offers equivalent functionality, making the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the burden of behavioral disclosure. It explains the three edit operations, the input structures, and the prerequisite 'Requires allow_file_write in ~/.syscontrol/config.json'. It does not mention in-place modification or error handling, but the provided details are adequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise four-sentence block. It leads with the purpose, then explains each parameter group in a structured manner, and ends with the configuration requirement. No useless words or repetition.
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 purpose, all operation modes, parameter shapes, and the configuration prerequisite. It does not explain return values, but no output schema is provided and the tool is a simple mutation, so the description is reasonably complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed descriptions and examples for all four parameters. The tool description merely restates these parameter formats in prose, adding no new semantic meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Edit a Word document (.docx)' with three specific operations: find-and-replace, overwrite a paragraph by index, and append new paragraphs. This precise verb-resource pair and the enumerated operations distinguish it from sibling tools like edit_file and read_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by specifying the .docx file type and the available operations. It does not explicitly exclude plain-text editing (which edit_file might handle) or contrast with read_document, but the context is clear enough for an agent to select this tool for Word documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds beyond annotations by listing skipped directory types (e.g., .git, node_modules), which is useful behavioral context. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core function, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 optional params and no output schema, the description is complete: it states the purpose, default behavior, exclusions, and usage scenario. Could mention output format, but not critical given no schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with detailed descriptions, including defaults and ranges. The description adds little beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Finds' with a clear resource ('top N largest files under a directory'). It distinguishes from siblings like get_disk_usage and search_files by specifying the exact scope and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when the user asks what is using disk space or wants to free up storage,' providing clear context. Lacks discussion of alternatives or when not to use, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds valuable context: the platform dependency (macOS only) and the underlying command (pbpaste), which are not inferable from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It conveys the action, resource, and platform constraint efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and robust annotations, the description covers the essential behavior: return type (text), platform (macOS), and implementation (pbpaste). It does not mention error cases (e.g., non-text clipboard), but that is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds semantic clarity by specifying the content type as 'text', which clarifies what the clipboard returns beyond an empty 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 returns the current text content of the system clipboard, using a specific verb ('Return') and resource. It also distinguishes itself from the sibling 'set_clipboard' by being a read operation, and mentions platform (macOS).
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 clipboard text is needed, but does not provide explicit when-to-use vs alternatives or exclusions beyond the macOS-only constraint. No alternative tools are named, so guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful context about what the tool returns, including 'live pressure' and 'overclocking capability (where supported),' which helps set expectations. It does not contradict 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?
Two sentences, front-loaded with the main verb and resource, then a useful usage directive. No filler or redundant information. 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?
The tool is complex and has no output schema, but the description covers the key return categories and usage scenarios. It doesn't explain nuances like whether the profile is real-time or cached, but given the annotations and simple schema, it is sufficiently complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter 'use_case' is fully described in the schema with examples. The description adds slight context by linking the parameter to user intents like upgrading or overclocking, but it doesn't substantially enrich beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'full hardware profile' for a use-case, listing specific contents (specs, live pressure, overclocking capability, upgrade feasibility, bottleneck analysis). This distinguishes it from sibling tools like get_cpu_usage or get_device_specs, which cover narrower or different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'when the user asks about speeding up a specific task, upgrading their machine, or overclocking.' This gives clear contextual guidance, though it does not name alternatives or explicitly 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds a valuable permission requirement ('Requires allow_file_read in ~/.syscontrol/config.json') and lists the exact return fields, providing context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the primary action. It includes essential return fields, use case, and permission requirement without any redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no required parameters and no output schema, the description covers return fields, permission needs, and a use case. It does not explicitly state that listing is non-recursive, which could be ambiguous, but sibling tools like search_files cover recursive cases, making this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for both parameters (path defaults to home directory, show_hidden includes dotfiles). The description does not add parameter-specific detail, but the schema already handles it, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource ('List the contents of a directory') and specifies the returned fields. It is easily distinguished from sibling tools like read_file or search_files by its focus on directory browsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'Use to browse the filesystem or verify file presence.' However, it does not mention when to use an alternative tool (e.g., search_files for recursive searches) or any exclusions, so it lacks full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a critical behavioral constraint—the require allow_file_write permission—beyond the annotations, which provide no safety hints. It does not detail overwrite behavior or failure modes, but the permission requirement is valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action, and adds only essential use cases and permissions. 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?
For a simple two-parameter file operation, the description covers purpose, when to use, and a key prerequisite. It does not mention return values or overwrite behavior, but the tool is simple enough that this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both src and dst already documented in the schema. The description does not add further parameter semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool moves or renames files/directories, and lists concrete use cases (renaming, moving, reorganizing). This clearly distinguishes it from sibling tools like copy_file or delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use the tool ('Use for renaming files, moving files to different folders, or reorganising directories'). It does not explicitly exclude alternatives like copy_file, but the scope 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?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the bar is lower. The description adds valuable behavioral details about the max_chars limit, default value, and truncation behavior, which go beyond the annotations and help the agent understand output boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word earns its place. It avoids fluff while including key constraints and use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters, high schema coverage, and strong annotations, the description covers the essential information: what it reads, what it returns, and size limits. It doesn't explain error cases or binary file handling, but that is not critical for this tool's complexity. The description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the schema already explains path (absolute/home-relative) and max_chars (range/default). The description merely restates the default and max values without adding new semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('file at the given path'), clearly stating it returns text contents. This distinguishes it well from sibling tools like read_file_lines, tail_file, and write_file, even without naming alternatives.
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 use-case context: 'Useful for reading config files, logs, scripts, notes, etc.' This implies when to use the tool, though it does not explicitly mention alternatives or when not to use it. Given the broad utility of a file reader, this is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, setting a safe-read baseline. The description adds valuable context beyond annotations: the output format ('like cat -n') and the permission requirement (allow_file_read). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: stating the core function, providing usage differentiation, and noting a prerequisite. No fluff, and the main action is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by stating the return format ('cat -n'). It covers purpose, usage guidance, and a prerequisite, making it reasonably complete for a simple file read tool. Edge cases like file-not-found are not mentioned, but these are not essential given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all three parameters (path, limit, offset) with types, defaults, ranges, and meaning, so schema coverage is 100%. The description only restates the offset/limit navigation concept, adding no new semantics beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a file with line numbers and supports offset/limit navigation, explicitly distinguishing it from read_file by prescribing use when line numbers or specific sections are needed. This is a specific verb+resource+scope that differentiates it from the sibling read_file tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use guidance: 'Use this instead of read_file when you need line numbers or want to read a specific section.' It also notes the require allow_file_read prerequisite. However, it does not mention alternatives like tail_file or when-not conditions, so it is not exhaustive but still practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by stating it returns headers and row data, enforces a max_rows cap, and requires the allow_file_read config flag—useful behavioral context beyond the safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence adds relevant detail (format, output, options, config requirement). No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description adequately explains the return format (headers and row data). It covers the main options, limits, and prerequisites. Minor gaps remain (error handling, CSV behavior specifics), but for a simple read tool it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a small amount of meaning (e.g., example cell range, default max_rows) but mostly repeats what the schema already documents. It does not significantly enhance parameter understanding beyond structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads rows and cells from spreadsheet files (.xlsx or .csv), distinguishing it from siblings like read_document or read_pdf. It specifies the resource (spreadsheet) and the action (read), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context by specifying supported file types and optional parameters (sheet, cell range), and notes the config requirement. However, it does not explicitly mention when to prefer this tool over alternatives like read_file_lines or read_document, though the file type limitation implies the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explicitly stating that external MCP processes are restarted and their tools rediscovered. It also discloses the permission requirement ('Requires allow_connectors'). This adds meaningful behavioral context, though it does not detail potential side effects like temporary downtime or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and then the consequence. Every phrase adds value—'Restart external MCP connector processes' and 'rediscover their namespaced tools'—with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately covers the purpose, the effect (restart and rediscovery), and a key prerequisite (allow_connectors). It does not explain when to use this tool or possible error conditions, but these are not critical for such a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the schema trivially covers 100% of parameters. The description does not need to explain parameter semantics; the baseline for zero parameters is 4, and the description appropriately focuses on the tool's action and requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Restart' and specifies the resource 'external MCP connector processes' and the additional action 'rediscover their namespaced tools.' This distinguishes it from sibling tools like list_connectors, add_connector, and remove_connector, which perform different operations.
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 refreshing connectors after external MCP processes change, and it mentions the 'allow_connectors' requirement. However, it does not explicitly state when to use this tool versus alternatives such as add_connector or remove_connector, nor does it provide any 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and provide little safety information. The description adds key behavioral context: the tool only returns the skill body for the LLM to execute, rather than executing it directly. It also clarifies that the task is optional, which goes beyond the raw schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences. The first states the action, the second explains the result and how the LLM uses it, and the third points to the sibling discovery tool. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two parameters and no output schema, the description sufficiently explains what it returns (the skill body) and how to find skill names. It does not detail the structure of the playbook, but that is not essential for invoking the tool correctly. Overall, the description is complete enough for correct selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'name' and 'task' already described well in the input schema. The description adds slight semantic clarity by calling the task 'optionally' and saying it is applied to the skill, but it mostly mirrors the schema, so it does not meaningfully elevate understanding beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Fetch the playbook for a named skill' and clarifies the output: 'Returns the skill body for the LLM to execute step-by-step.' It clearly distinguishes from the sibling list_skills by pointing to it as a discovery tool, making the tool's own purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives usage context: it is for executing a named skill with an optional task, and it explicitly names list_skills to view available skills. This is helpful but does not state explicit when-not-to-use cases or mention any alternative execution tools, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar for added transparency is lower. The description adds meaningful behavioral context by revealing the underlying mechanism (Spotlight/mdfind), performance trait (much faster than find, instant system-wide search), and platform restriction (macOS only). This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a key advantage, usage directions, and platform constraint. Every sentence contributes value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with four well-documented parameters and safety annotations, the description is sufficiently complete for an agent to select and invoke it. It includes platform, usage scope, and the search mechanism. While the return format is not described, the tool's output is unambiguous (file paths), and no output schema exists so it is not mandatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (kind, limit, query, scope) already have detailed descriptions in the schema. The description reinforces that searches can be by name, content, or type, which maps to the query and kind parameters, but it does not add new parameter-level information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for files using macOS Spotlight (mdfind)' and specifies the resource (macOS files), the action (search), and the scope (by name, content keywords, or type). It differentiates from sibling tools like find_large_files and grep_files by emphasizing system-wide instant search and macOS-only availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Use for finding files by name, content keywords, or type' and notes 'macOS only'. It also implies a preference over 'find' due to speed. However, it does not explicitly mention when not to use it (e.g., if a non-indexed search is needed) or name alternative tools for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints, so the description carries the full burden. It discloses that it fires a notification, accepts natural-language time, and returns a cancelable ID. This covers the core behavior, though it omits prerequisites like macOS notification 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 three concise sentences: first states the core action, second gives time examples, third explains the return value. No redundant or unnecessary text; front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description provides essential context: what it does, how time is expressed, and what it returns. It lacks explicit error handling or permission details, but the schema and sibling references fill in most gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions and examples for both time and message (100% coverage). The tool description repeats these examples without adding new parameter-level meaning, so it does not exceed the baseline expected from 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 it schedules a macOS notification at a specified time, with specific examples of natural-language input. This directly distinguishes it from siblings like list_reminders and cancel_reminder by its action and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly provides workflow context by noting the returned ID can be used with cancel_reminder. However, it lacks explicit guidance on when to use this tool versus list_reminders or other alternatives, though the simplicity makes the usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds value by specifying the exact output shape (per-subdirectory sizes, file counts, top-N list) and the permission requirement 'allow_file_read', which goes beyond the structured 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?
Two concise sentences front-load the core functionality, add a practical benefit, and note a prerequisite. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with strong annotations, the description sufficiently covers purpose, output, and permissions. It lacks details on return format specifics or error handling, but the annotation safety profile and output description are enough for a typical agent to correctly 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?
With 0% schema description coverage, the description must clarify parameters. It explains 'configurable depth' for the depth parameter and 'top-N list' for top_n, but does not explicitly address the path parameter beyond the implied directory tree context. This partial compensation is adequate but not complete.
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 walks a directory tree and returns summary statistics (sizes, file counts, largest subdirs). It distinguishes itself from sibling list_directory by explicitly noting it saves many such calls.
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 phrase 'Saves many list_directory calls' implies when to use this tool over alternatives, providing clear context for its intended use case. However, it does not explicitly name alternatives or state when not to use it beyond that implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context by stating it auto-detects carriers, returns current status and recent tracking history, and warns about Amazon TBA numbers not being supported. This goes beyond the annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a note, front-loaded with the primary purpose. Every sentence is informative with no wasted words, covering action, behavior, output, and a limitation in a compact form.
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 one-parameter read-only tool, this is complete enough: it states the input, behavior, and output overview, and flags the important Amazon TBA limitation. Without an output schema, it could specify the return format in more detail, but it provides a reasonable high-level as-is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single 'tracking_number' parameter with carrier list, so schema coverage is 100%. The description's mention of auto-detection aligns with the schema but adds no extra parameter syntax or format details. A baseline 3 is appropriate since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Track' with resource 'a package' and clarifies scope 'by tracking number'. It clearly distinguishes from all sibling tools, which are system monitoring and file operations. Mentions carrier auto-detection and return of status/history, fully defining the tool's unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use (any package with a tracking number) and explicitly excludes Amazon TBA numbers, directing users to track those elsewhere. It does not name an alternative tool among siblings, but the Amazon note serves as a specific when-not-to-use condition, providing adequate usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses the configuration requirement (allow_file_write) and the .xlsx-only restriction for create_if_missing. It does not explicitly warn that updates overwrite existing cell values, but this is largely inferred from the word 'write'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently structure the description with the main action first and parameter details following. Every sentence provides useful information without any wasteful repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter write tool, the description covers the core workflows, parameter formats, configuration requirement, and format limitations. It is sufficiently complete for practical use, despite lacking an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all parameters, and the description adds concrete examples for updates and append_rows, clarifies A1 notation, and explains the create_if_missing behavior. This adds meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes cells or appends rows to spreadsheet files and specifies the supported formats (.xlsx or .csv). This distinguishes it from sibling file operations like write_file or edit_file.
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 spreadsheet modification but does not explicitly state when to prefer this tool over alternatives like edit_file or write_file. No exclusions or alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by specifying the exact data returned (partition usage and I/O counters), but does not disclose further behaviors such as permission requirements or output format. Given the rich annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler, front-loading the purpose immediately. Every word contributes to understanding the tool, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description is complete: it clearly states what the tool returns. There are no prerequisites, side effects, or return format details that need explanation, and the annotations cover safety. The description fully supports an agent in deciding when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the input schema provides no information, so the baseline is 4. The description adds meaning by explaining the tool's output, which helps the agent understand the tool's semantics despite the absence of parameters. It does not over-explain or repeat schema content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns' and identifies the resource clearly as 'disk partition usage and I/O counters'. This clearly distinguishes it from sibling monitoring tools like get_cpu_usage, get_ram_usage, and get_realtime_io, which focus on other system metrics.
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 disk-related queries but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. For example, it does not clarify the difference from get_realtime_io, leaving the agent to infer the appropriate context based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds valuable behavioral context by specifying the exact returned fields and, importantly, that it returns an actionable error if Docker is not installed or the daemon is not running. This goes beyond the structured annotations and provides practical expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no redundant information. Every sentence earns its place: the first states the core output, the second adds the count and error handling. There is no wasted text.
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 parameters, a simple read-only output, and the presence of rich annotations, the description is complete. It states exactly what is returned and how failures are reported. No output schema exists, but the description adequately covers the return content, so no further detail is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the schema confirms no parameters are required. No further parameter-specific detail is expected, so the score aligns with the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all running Docker containers with specified fields (CPU%, memory usage, image, status, ports) and total container count. This is a specific verb+resource combination that distinguishes it from sibling system metrics tools like get_cpu_usage or get_ram_usage, which cover host-level resources rather than Docker-specific data.
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 explicitly state when to use this tool versus alternatives or mention exclusions. However, the specific reference to Docker containers and the inclusion of an error for Docker-specific issues implies the intended use case. No explicit guidance on alternatives is provided, so it earns only the implied-usage score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable context beyond annotations: the dependency on nvidia-ml-py and NVIDIA hardware, and the fact that it returns an inline grouped bar chart. This gives the agent a better sense of prerequisites and output format without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose, then adds dependency and output details. It is concise with no redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description fully covers the necessary context: what is returned, the hardware/software requirements, and the format (chart). An agent can confidently invoke this tool based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and description coverage is 100%. The baseline for no parameters is 4, and the description adds meaning by specifying what metrics are returned (load, VRAM, temperature), which is relevant context even without 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 what the tool does: returns GPU load, VRAM usage, and temperature. It uses a specific verb and resource, and the mention of GPU-specific metrics distinguishes it from sibling system monitoring tools like get_cpu_usage and get_ram_usage.
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 context by naming GPU metrics, making it clear this is for GPU monitoring. However, it does not explicitly state when to use this tool instead of alternatives or mention any exclusions. The dependency note (requires nvidia-ml-py) gives a prerequisite but not explicit guidance on 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the specific data fields (local/remote addresses, status, owning process name), which is useful but does not reveal additional behavioral traits such as performance impact or permission requirements. This aligns with the calibration example where annotations cover safety and description adds some context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states what the tool returns with no filler. It is front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description covers the return contents clearly (connections, addresses, status, owning process). No output schema exists, but this description, combined with the safety annotations, is sufficient for an agent to know what to expect and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 is appropriate for a no-parameter tool, as there is no additional meaning to provide beyond what the empty schema shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and resource ('all active TCP/UDP connections') with details on addresses, status, and owning process. This clearly distinguishes it from sibling tools like get_network_usage, which focuses on bandwidth metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting network connections and the returned fields make the tool's purpose clear. However, it does not explicitly mention when to use this tool over alternatives like get_network_usage or get_process_details, so it lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly (readOnlyHint=true) and idempotent, but the description adds valuable behavioral detail beyond that: platform-specific behavior on macOS vs Linux/Windows, and the nature of returned data (groups with current, high, and critical thresholds). This goes beyond the annotations and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, then adds platform-specific nuances. Every sentence contributes meaning—no fluff, no redundancy with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no params, no output schema, clear annotations), the description fully covers what the agent needs: what it returns, platform differences, and the threshold information. There are no significant gaps for a read-only monitoring tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers everything trivially (100% coverage). Per the rubric, a baseline of 4 is appropriate since the description need not explain parameters that don't exist. The description focuses on behavior rather than irrelevant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's function: 'Returns CPU and motherboard temperature sensor readings.' The verb 'Returns' plus the specific resource (temperature sensors) makes the purpose unambiguous and distinguishes it from sibling tools like get_cpu_usage or get_gpu_usage.
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 implicitly conveys when to use the tool (for temperature readings) and explicitly notes platform limitations (macOS returns alternatives). However, it does not name any specific alternative tool or state explicit 'use this when / not when' guidance, leaving the agent to infer context from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description adds valuable behavioral context by noting that it auto-detects the repo root and limits output to the 5 most recent commits. It does not detail error behavior (e.g., when not in a repo), but the annotation coverage lowers the bar, and the added context justifies a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundancy. It front-loads the action and resource, then lists specific outputs, making it highly efficient and 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?
The tool is simple, has good annotations, and no output schema. The description clearly states what the tool returns (branch, file states, commits) and adds the auto-detection behavior. There are no obvious gaps that would prevent an agent from using or understanding the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'path', which is fully described. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Show' with a clear resource ('git repository status') and enumerates the exact contents: current branch, staged/unstaged/untracked files, and recent commits. This clearly distinguishes it from sibling tools like git_diff, which focuses on changes, and from system monitoring tools like get_cpu_usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies its use case: checking the overall state of a git repository. It does not explicitly name alternatives or mention when not to use it, but the context is unambiguous given the sibling list and the direct phrasing. A score of 4 is appropriate because there is clear context but no explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail beyond the annotations: it searches recursively and skips .git, node_modules, .venv, and __pycache__ directories. Since annotations already declare read-only and non-destructive, this is valuable complementary context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the action and examples. Each sentence provides necessary information—what the tool does and what it skips—with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only glob search tool, the description captures the primary use case, the recursive behavior, and directory exclusions. The schema fully documents parameters and annotations cover safety, making the definition complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'path' and 'pattern' already described. The description reinforces parameter meaning with examples and the phrase 'base path,' but does not add meaningful new semantic information beyond the schema, so it earns the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds files matching a glob pattern, with concrete examples. The verb 'Find' plus resource 'files' and the pattern syntax distinguish it from content-search tools like grep_files, though it does not explicitly name alternatives.
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 conveys clear usage context: use this for locating files by path pattern, with recursion and base path behavior. It does not explicitly state when not to use it or mention alternative tools, so it lacks the explicit exclusions needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds the return structure (description, tool allowlist, optional sub-agent) and the filesystem path, which is useful beyond the annotations and helps the agent anticipate response content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action and resource, the second describes the entry structure. No redundancy or fluff, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with rich annotations, the description is sufficient: it states the source, the scope, and the composition of each returned entry. No output schema exists, but the description covers the essential return information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema description coverage is trivially 100%. The baseline for no parameters is 4, and no additional parameter explanation is needed; the description's focus on what is listed is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists user-installed skills (workflows) from a specific path, and distinguishes this from sibling tools like list_user_tools or list_automations by specifying the resource type ('skills') and the source location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to see installed skills) but does not provide explicit guidance on when not to use it, nor does it mention alternatives. The context is clear but exclusions are nonexistent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds meaningful behavior beyond that: the inclusion of ancestors+descendants for a given pid and the system tree behavior without one. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, succinct, and front-loaded with the main action. Every clause adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While it covers the two core modes, it is ambiguous whether depth applies to the pid case or only to the system tree. It also does not describe the return structure despite the lack of an output schema, leaving some gaps for an agent relying solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers pid well but depth only has type/default constraints. The description compensates by explaining pid as root and depth as controlling the system tree depth, adding meaning to both parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns a process tree' with a specific verb and resource, then clarifies two modes (with/without pid). This distinguishes it from sibling tools like get_top_processes or get_process_details, which target different process information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context on when to use each mode: with a pid for ancestors+descendants, without a pid for the system tree at a depth. However, it does not explicitly mention alternatives or exclusions, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context beyond that: the requirement for allow_file_read in config, plus the behavior of returning non-empty paragraphs with indices and a word count. This enriches the agent's understanding of permissions and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the action and resource, the second describes return values and permission. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and a straightforward read operation, the description fully covers the tool's purpose, return format, and required permission. No gaps remain for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'path' parameter, so the baseline is 3. The description does not add parameter-specific meanings beyond what the schema already provides (e.g., it repeats the file types but does not elaborate on path format, errors, or edge cases).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads paragraphs from Word (.docx) or plain text (.txt, .md) files, and lists the return values (paragraph indices and word count). This specific verb and resource combination distinguishes it from siblings like read_pdf, read_file, and read_spreadsheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about applicable file types and the allow_file_read prerequisite, but it does not explicitly name alternatives or state when not to use this tool. Given the sibling set, the file-type restriction effectively guides selection, so this is solid but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds context about the memory file's content and usage triggers but does not disclose additional behavioral details like return format or empty-state behavior, so it stays at the baseline for annotation-supported transparent tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by concrete usage triggers. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters, no output schema, and robust annotations, the description fully covers purpose and usage context. The agent can select and invoke this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects this with 100% coverage. The description does not need to explain parameters, and baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a persistent memory file, defining its specific resource and action. It distinguishes itself from generic file reads (read_file) and the sibling append_memory_note, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to call the tool: when the user references past sessions, asks what the agent remembers, or when prior context is relevant. It lacks when-not-to-use or explicit alternative tool mentions, but the 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?
Annotations are all false, so they don't convey behavioral traits. The description adds valuable information: macOS-only (uses pbcopy), which implies platform restrictions and dependency. It also clearly indicates a write operation. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, followed by the platform restriction and a concrete use case. There is no fluff; every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter clipboard write with no output schema, the description covers the essential context: what it does, platform limitations, and when to use it. No missing information that would hinder correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter 'text' with 'Text to place on the clipboard.' The description adds no additional detail about format, length, or encoding, so it is exactly at the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Write' with the resource 'system clipboard', clearly stating the tool's function. The macOS-only note and pbcopy dependency further distinguish it from the sibling get_clipboard, which performs the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use to copy a result or command output so the user can paste it anywhere.' This makes the intended scenario clear, though it does not explicitly contrast with get_clipboard or mention any exclusions. Still, it gives strong practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it uses 'screencapture -x' with no shutter sound, returns the image inline, and optionally saves to a file path. These behaviors go beyond the annotations (all false) and give the agent a clear expectation of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core action and then add the macOS constraint and implementation detail. Every sentence earns its place with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the platform (macOS), behavior (entire screen, inline image, optional file save), and implementation nuance (no shutter sound). This is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a clear description for the single 'path' parameter (e.g., usage and default behavior). The tool description only repeats 'Optionally saves to a file path' without adding new semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Capture' and resource 'entire screen', and clarifies the result is an inline image. This distinguishes it from sibling tools like get_clipboard or generate_image, and any ambiguity is eliminated by the explicit macOS-only constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (to capture a full-screen screenshot) and provides an important exclusion (macOS only). While it doesn't explicitly mention alternatives, none of the sibling tools perform screenshots, so no further guidance is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and open-world hints. The description adds valuable context: HTML is stripped, no permission required, and pages must be public. This goes beyond annotation coverage, though it does not mention failure behavior or rate limits, which keeps it at a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence states the core function and key transformations (HTML stripped), the second gives usage cases and constraints. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with complete schema and annotations, the description covers purpose, usage, and behavioral traits. The return type (plain text) is implicit from the description, and no output schema is needed. It is fully adequate for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well documented (URL with https assumption, max_chars with range). The description adds no parameter-specific details beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the specific verb 'Fetch' and resource 'plain-text content of any public web page'. Distinguishes from siblings by noting no browser is needed, separating it from browser_open_url, and from web_search by focusing on fetching a specific URL versus searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use this to read articles, docs, pricing pages, or any URL the user mentions.' This implies when to use, and 'No browser needed' hints at an alternative. However, it does not explicitly name alternative tools or state when not to use, falling short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds useful behavioral context beyond this: it specifies the search engine (DuckDuckGo), the output fields (title, URL, snippet), and that no API key or browser permission is required. This exceeds the baseline for annotation-covered tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence immediately states the core function and output. The second sentence provides practical facts (no API key, no permission) and a pointer to web_fetch. Every sentence adds value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool, the description is complete: it tells what the tool returns (top N results with fields), notes the underlying engine, mentions constraints (no API key, no permission), and gives a follow-up action (combine with web_fetch). Despite no output schema, the description covers the return semantics adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to compensate. The description briefly touches on num_results via 'top N results' but does not add new meaning beyond what the schema already provides for query and num_results. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action verb ('Search') and identifies the resource ('the web'), plus specifies the engine (DuckDuckGo) and return format (title, URL, snippet). It clearly distinguishes itself from siblings like web_fetch by noting it returns search results rather than full 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 gives clear usage context ('Search the web', 'No API key', 'No browser permission required') and explicitly mentions combining with web_fetch for full content. However, it doesn't explicitly state when to prefer other tools (e.g., browser_open_url) or provide an exclusion criteria, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which provide no safety hints), the description discloses that old_string must be unique and the tool fails if ambiguous, that replace_all changes this, and that allow_file_write permission is required. It stops short of detailing error handling for not-found text or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the action, and every sentence earns its place by conveying usage, requirements, or failure modes. No redundant or fluff content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description covers the core editing workflow, prerequisites, and a key failure mode. Minor gaps remain around return values and what happens when old_string is not found, but it's sufficient for typical invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all four parameters, but the description adds meaningful nuance: 'fails if ambiguous' for old_string and 'By default' for uniqueness behavior. It also reinforces the role of replace_all, adding error behavior not present in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool performs targeted find-and-replace edits on files, distinguishing it from sibling tools like write_file or delete_file. The verb 'Make' plus 'targeted edits' and resource 'file' 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?
Provides explicit instruction to ALWAYS read the file first to get exact text, and explains the uniqueness requirement and replace_all behavior. Does not explicitly name alternative tools or exclusions, but the context makes the appropriate use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal behavioral context (readOnlyHint=false, idempotentHint=false). The description adds meaningful context beyond annotations: it states the return format ('inline PNG for the GUI/chat') and an auth requirement ('Requires an OpenAI image API key'). It does not contradict annotations, so no annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the purpose, followed by usage guidance, an alternative, and a requirement. Every sentence provides distinct value with no unnecessary fluff, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with a fully descriptive schema, the description covers the key contextual elements: what it does, when to use it, a critical alternative, an auth prerequisite, and the output format. It does not explain error handling or cost, but for a simple generative tool with rich schema, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all five parameters having descriptions. The description itself does not elaborate on parameter details but does mention 'text prompt' and 'return as PNG', adding slight context. Since the schema already documents parameters thoroughly, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Generate a new visual image artifact from a text prompt and return it as an inline PNG for the GUI/chat.' This is a specific verb+resource statement that clearly defines the tool's function. It also distinguishes itself from sibling system data tools by noting a preference for chart-returning metric tools for system data, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use when the user asks for an image or when a small visual artifact would clearly make the answer more useful.' It also provides an exclusion: 'Prefer built-in chart-returning metric tools for system data.' This gives clear guidance versus alternatives and includes a prerequisite (OpenAI API key).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is established. The description adds useful behavioral context by specifying the return values and the error case for desktops with no battery, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence front-loads the primary purpose and returned data, and the second covers the error condition. 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 read-only status tool with no parameters and no output schema, the description adequately covers the key return values and an important edge case. It lacks exact formatting details (e.g., units or response envelope), but this is minor for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters because there are none, and it correctly focuses on the output instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'returns' and clearly identifies the resource (battery status), listing the exact data items: percentage, charging state, and estimated time remaining. This distinguishes it from sibling tools like get_cpu_usage or get_ram_usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (when battery information is needed) and states an exclusion/error condition for desktops with no battery. However, it does not explicitly name alternative tools or elaborate on when not to use it beyond the no-battery limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing safety. The description adds value by specifying the return format (inline bar chart) and the exact data points (per-core and total percentage, core count, frequency), which is behavior beyond the 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?
A single, well-structured sentence front-loads the primary purpose ('Returns CPU usage percentage') and then lists additional details. Every phrase is informative and there is no redundancy or extraneous text.
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?
Without an output schema, the description bears responsibility for explaining return values. It covers the key elements: total and per-core usage, core count, frequency, and the bar chart. Minor ambiguities like frequency units and sampling methodology prevent a perfect score, but it is complete for a simple monitoring tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete (100% coverage). The description does not need to explain parameters, and it instead provides useful output details. Baseline for zero-parameter tools is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and identifies the resource ('CPU usage') with detailed scope: total and per-core percentage, core count, frequency, and inline bar chart. This clearly distinguishes it from sibling tools like get_ram_usage and get_gpu_usage.
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 intended use is evident from the description: it provides CPU metrics. While it doesn't explicitly name alternatives or exclusions, the context is clear within the system-monitoring tool family. The lack of explicit when-not-to-use is a minor gap, but the description is sufficient for a simple read-only metric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by specifying exact scan locations on each OS (macOS LaunchAgents/Daemons, Windows Run keys, Linux autostart), which is useful context beyond annotations. It does not mention potential permission concerns or output structure, but the extra platform details are solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the purpose stated first, then platform specifics, then usage guidance. Every sentence earns its place with no fluff or repetition.
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 parameterless read-only tool, the description covers purpose, platform locations, and usage context. It does not explicitly describe the return format, but given the tool's simplicity and the lack of an output schema, this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline 4 applies. The description correctly focuses on the platform-specific scanning behavior instead of parameter explanations, which is appropriate for a no-parameter tool.
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 function with a specific verb ('Lists') and resource ('applications and services configured to launch automatically at startup/login'). It also provides platform-specific details, making it immediately distinguishable from sibling monitoring tools like get_cpu_usage or get_process_details.
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?
Explicit usage guidance is given: 'Use when the user asks what runs at startup or wants to speed up boot times.' This tells the agent when to invoke the tool, but it does not mention alternatives or when not to use it, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-idempotent, and non-destructive behavior. The description adds that the notification appears immediately and natively, which clarifies the side effect and timing. It does not go into potential platform limitations, but for this simple tool it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no filler. The distinction from set_reminder is valuable and efficiently stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the absence of an output schema, and the annotations, the description covers purpose, usage, and differentiation. No additional context seems necessary for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 does not explain the three parameters (title, body, sound). The parameter names are somewhat self-explanatory for a notification, but the boolean 'sound' and the default for 'body' are not described. The description should have compensated for the low schema coverage but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('show') and resource ('native desktop notification'), and clearly distinguishes from the sibling tool 'set_reminder'. It states exactly what the tool does, so the agent knows its function immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is 'distinct from set_reminder, which schedules a reminder' and gives an example use case ('skill completion alerts'). This tells the agent when to use this tool over the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive. The description adds useful constraints (file size cap, line limit) and a permission requirement, going beyond annotation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no filler. The core function is front-loaded, and each sentence adds essential information (operation, limits, permission).
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 operation, constraints, and requirements sufficiently for a simple tail tool. No output schema is present, but the return behavior is obvious; minor gaps like error handling are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers path and filter_str, but 'lines' lacks a description. The description clarifies 'last N lines' and 'filtered by substring', adding meaning to lines and filter_str beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tails the last N lines of any text file with optional substring filtering. The verb 'tail' and resource 'text file' distinguish it from siblings like read_file or tail_system_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical context: caps at 50 MB, up to 5000 lines, and requires a specific permission. This helps the agent decide when to use it, although it does not explicitly exclude alternatives like read_file for small files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description does not contradict them. It adds useful behavioral context beyond annotations: macOS reads from the unified log for the last 5 minutes, Linux uses journalctl or /var/log/syslog, and filter_str narrows results. This is good but not exhaustive (e.g., no mention of permissions or what happens if no logs are found).
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 front-loaded, with two sentences covering core functionality, OS specifics, optional parameters, and use cases. Every sentence earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers OS-specific behavior, a time window on macOS, and intended use cases. No output schema exists, but the phrase 'Returns the last N lines' gives enough understanding of the return type. It could mention edge cases like empty logs or Linux time ranges, but overall it is sufficiently complete for a system log tail tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for both parameters. The description adds minimal extra semantics by mentioning that filter_str narrows results, but it does not go beyond what the schema already provides. Baseline 3 is appropriate because the schema fully documents the 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 function: returns the last N lines from the system log, with OS-specific details for macOS and Linux. It also distinguishes itself from sibling tools like tail_file by focusing on the system log and mentioning diagnostic use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool ('use to diagnose crashes, kernel panics, or application errors') and differentiates from file tailing by focusing on system logs. While it does not name alternative tools, the guidance is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds behavior not captured by annotations: creates parent directories, overwrites by default. It also implies that setting overwrite=false will error on existing files (matching the schema). This is valuable context. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, all of which provide distinct, useful information. It front-loads the core purpose in the first sentence, then adds creation behavior and use cases. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the relative simplicity of this tool (3 parameters, all documented, no output schema), the description covers the core purpose, key behavioral constraints (parent dir creation, overwrite default), and typical use cases. It lacks some details like error conditions or permissions, but this is sufficient for an AI agent to select and invoke the tool correctly in most contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for parameters, so the schema already documents path, content, and overwrite. The description adds semantic context beyond the schema: 'absolutely or home-relative path' clarifies path format, and 'overwrites by default' reinforces the overwrite behavior. 'Text content to write' is aligned with the content parameter but adds no new 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 states exactly what the tool does: 'Write text content to a file at the given path.' This clearly identifies the verb (write), resource (file), and key behavior (overwrites by default). It also indicates primary use cases ('saving notes, configs, scripts, or any text output'), distinguishing it from other file operations like read_file or delete_file.
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 it overwrites by default and creates parent directories as needed, which are important usage considerations. It also gives examples of when to use it (saving notes/configs/scripts). However, it doesn't explicitly mention alternatives like edit_file or run_shell_command for file writing, so it's missing explicit 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, but the description adds the important context of persistence ('future session') and the constraint of brevity. It does not contradict annotations and provides extra behavioral context beyond the raw flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, no fluff. Every sentence adds value: what it does, when to use it, and how to format the note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with annotations and complete schema coverage, the description fully explains the tool's purpose, usage trigger, and content constraints. No output schema is needed, and the description covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear param description. The tool description adds the specific guideline of '1-3 sentences', which goes beyond the schema's 'be concise' and provides additional semantic meaning for the note parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Append') and resource ('persistent memory file'), and distinguishes from sibling read_memory by focusing on writing. It also defines the type of content (concise notes, key facts).
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 when to use the tool ('when the user shares a preference, important system fact, or decision'). It does not mention alternatives, but no obvious alternative exists for writing memory besides this tool. Slight deduction for not stating 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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: the tools it uses (Homebrew, mas, system updates), the platform restriction, and the output format (lists with current vs available versions). This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences pack all essential information: platform, sources, dependencies, and return detail. Front-loaded with the most important scoping ('macOS only') and purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description fully covers platform, dependencies, sources, and output structure. It is enough for an agent to know exactly when to invoke it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4 per rubric. The description mentions the output format (lists of outdated apps with versions), which is useful even without parameters. No parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('checks for outdated applications') and clearly enumerates the resources covered (Homebrew formulae+casks, Mac App Store via mas, macoS system updates). It distinguishes itself from sibling tools like get_cpu_usage or get_system_alerts by focusing on application update status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear platform context ('macOS only') and notes the mas CLI dependency for Mac App Store checks. While not explicitly naming alternative tools, the scope is distinct enough from siblings that usage context is clear. No exclusions are given, but none are needed for a read-only check tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial context beyond the annotations: it discloses the multi-step process (planning subquestions, searching multiple sources, extracting claims, cross-verifying), the output format (citation-backed), the time cost, and a prerequisite (allow_deep_research in config). This is exactly the kind of behavioral detail that helps an agent understand the trade-offs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each earning its place: first explains what it does, second gives usage guidance, third states time and permission requirements. No fluff, front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex research tool with no output schema, the description covers the process, duration, return value (citation-backed answer), and prerequisites. It fully compensates for the lack of an output schema and gives the agent enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all three parameters, including defaults and ranges. The description does not add parameter-level semantics beyond what the schema provides, but it also doesn't need to. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('conduct deep, multi-step web research'), the resource (web/topic), and the output (citation-backed answer). It distinguishes itself from siblings like web_search and web_fetch by emphasizing multi-step planning, cross-verification, and synthesis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use it: 'for questions needing current information, evidence verification, or multiple perspectives.' It also gives a time expectation (1-3 minutes) which helps the agent decide if this heavy tool is appropriate. It does not explicitly name alternatives or exclusion criteria, but the contrast with simpler search tools is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations: it returns both RAM and swap metrics and includes a chart, which hints at visual formatting. It does not describe return structure or units, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It conveys the resource, the exact data points, and a visual feature in under 20 words, making it ideal for quick agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter, read-only tool, the description fully covers what the tool does and what it returns. No output schema exists, but the description lists the output contents (metrics and chart), making it self-sufficient. There are no missing operational prerequisites or complex edge cases to disclose.
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?
This tool has zero parameters, so the input schema is trivially complete (100% coverage). There are no parameter details to add; the description's mention of the metrics returned is additional context beyond parameter semantics. Baseline for 0 params is 4, and no further param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Returns') and resource ('RAM and swap memory usage'), including the exact metrics (total, used, available, percent) and a distinctive feature (inline stacked bar chart). It differentiates from sibling tools like get_cpu_usage and get_disk_usage by its resource focus.
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?
While no explicit 'when to use vs alternatives' is stated, the context is unambiguous: this tool is for RAM/swap information, and siblings cover other resources. For a simple read-only getter, the usage context is clear, though it stops short of explicitly naming alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive traits. The description adds value by disclosing that output is a prioritized list of critical/warning alerts and that it covers multiple metrics (CPU, RAM, swap, etc.), which is not implied by annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core purpose and usage. Every word earns its place—no fluff, no repetition of the tool name, and it adds essential guidance without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with no output schema, the description is complete. It explains what it does, what it returns, and when to use it. No additional details about return format or edge cases are necessary for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description doesn't need to explain parameter usage, and the schema is empty with 100% coverage. It appropriately focuses on the tool's scope of metrics scanned.
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 scans all key system metrics and returns a prioritized list of critical/warning alerts. It uses specific verbs ('scans', 'returns') and differentiates itself from sibling tools like get_cpu_usage by acting as a general triage tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Call this first for general why is my machine slow? questions as a quick triage tool', which gives clear when-to-use context. It does not explicitly mention when not to use or name alternative specific metric tools, but the guidance is unambiguous 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is established. The description adds value by specifying what data is returned (uptime duration, boot time, load averages), which is transparent about the tool's output without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and subject, then lists the three return components. Every word adds information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description fully conveys what the tool does and what it returns. The listed components (running time, last boot time, load averages) are sufficient for an agent to invoke it correctly without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it doesn't; it focuses on the return values instead, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' with a clear resource (system uptime) and enumerates the exact data returned (running time, last boot time, load averages). This distinguishes it from sibling tools like get_cpu_usage and get_ram_usage, which target different metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates that this tool is for retrieving uptime and load average information, making its usage context obvious. It does not explicitly exclude alternatives or mention when not to use it, but for a simple read-only system metric tool, the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers safety traits. The description adds valuable behavioral context beyond annotations: IP-based auto-detection of location and the inclusion of clothing suggestions, which are not inferable from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary function, then adds location handling details. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only weather tool with no output schema, the description adequately covers what the tool does, how location is determined, and what it returns (conditions and suggestions). No critical information is missing for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes both parameters with 100% coverage, including the enum for units and the default behavior for location. The description adds examples (e.g., 'Tokyo' or 'London, UK') and reinforces the auto-detect aspect, providing extra clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'returns current weather conditions and clothing suggestions,' using a specific verb and resource. It distinguishes itself from sibling tools like get_temperature_sensors (hardware temperature) by explicitly focusing on weather and clothing.
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 auto-detects location from IP if none is given, and instructs to pass a city name for a specific location. It does not explicitly rule out alternatives, but there are no weather-related sibling tools, making the context sufficient.
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?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses important behavioral traits: skips binary files and common exclude directories (.git, node_modules, .venv, __pycache__). It also explains the output format (matching lines with paths and line numbers) and the context-lines option. This adds substantial behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three purposeful sentences: what it does, what it returns, and how it filters/excludes. Every sentence adds value and the most core information comes first. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, a fully descriptive schema, and the absence of an output schema, the description is complete. It explains the search scope, return format, filtering, and skip behavior. Enough for an agent to select and invoke correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all five parameters with 100% description coverage, including defaults, ranges, and regex syntax. The description adds no extra parameter-specific meaning; it merely restates the glob and context-lines concepts already present in the schema. Per the baseline for high schema coverage, this scores a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Search file contents for a regex pattern, like grep/ripgrep', naming the resource (file contents) and the verb (search). It also distinguishes itself from sibling file tools by specifying output (matching lines with file paths and line numbers) and filtering options. This is a specific, non-tautological purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: searching file contents with regex, optionally filtering by glob and adding context lines. It does not explicitly name alternatives or state when not to use it, but the 'like grep/ripgrep' reference and included options provide strong usage guidance. No explicit exclusions, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark destructiveHint=true, but the description goes far beyond by explaining the signal behavior (SIGTERM vs SIGKILL), the critical process safelist, and the user-confirmation requirement. This adds significant behavioral context that is not present in 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?
Three sentences, each earning its place: purpose, signal behavior, and safety guardrails. Front-loaded with the core action, and no unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter destructive tool with no output schema, the description covers purpose, method, safety restrictions, and required user consent. It is complete for an AI agent to understand invocation and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both pid and force. The description reinforces the force semantics ('SIGKILL if force=True') but does not introduce new parameter-level details beyond the schema. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Terminates a process by PID', which is a specific verb+resource+method. It clearly distinguishes kill_process from sibling tools like get_process_details or process_tree, as it is the only one that performs termination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage guidance: confirms with user before calling, defaults to SIGTERM, and refuses to kill critical system processes. It does not explicitly reference alternatives, but the context is sufficient for an agent to decide 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context by specifying the 'pending (unfired)' filter and what data is returned, which is useful and beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource, and directly states the key output fields. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with strong annotations and no output schema, this description is sufficiently complete. It specifies the exact scope (pending) and the information returned, covering everything an agent needs to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially covered at 100%. The description does not need to explain parameters; instead it clarifies the return payload (IDs, messages, fire times), which adds 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?
The description uses a specific verb ('List') and clearly identifies the resource ('pending reminders') and the scope ('unfired'). It also states the return fields (IDs, messages, scheduled fire times), which fully distinguishes it from sibling tools like set_reminder and cancel_reminder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes its use case clear: when you want to see pending reminders. It does not explicitly name alternatives or exclusions, but siblings like set_reminder/cancel_reminder are obviously different actions, so there is no ambiguity about when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by noting concurrent pinging and the automatic diagnosis categories (router issue / ISP issue / congestion / normal). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first describes what the tool does and the diagnosis output, the second gives usage guidance. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers purpose, targets, behavior, and usage context. It also explains return values (latency, reachability, diagnosis) implicitly. 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds context about the fixed targets (gateway, Cloudflare DNS, Google DNS), which is useful even though there are no parameters to document.
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 pings three specific targets (local gateway, Cloudflare DNS, Google DNS) concurrently and returns per-target latency and reachability, with an automatic diagnosis. This specific verb+resource combination clearly distinguishes it from sibling tools like get_network_usage or get_network_connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use when the user asks if their internet is slow or to locate where latency is introduced.' It does not mention alternatives or when-not-to-use, but the usage context is clear and sufficient for a network diagnostic tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already mark the tool as read-only, idempotent, and non-destructive, the description adds substantial behavioral context beyond these hints. It discloses the page-by-page return structure, the 200-page hard limit, the default of 50 pages, unsupported encrypted PDFs, and the required configuration file setting. This is exactly the kind of context an agent needs for safe and correct invocation.
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?
Four sentences, each adding value: purpose, when-to-use, limits/default, and constraints/prerequisites. The most critical information is front-loaded, with no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage scenarios, limitations, and configuration requirements. With only two well-documented parameters, strong annotations, and no output schema, the description is fully sufficient for an agent to select and use this tool correctly. Sibling tools are clearly distinct.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both path and max_pages with descriptions and defaults. The description's mention of 'pass max_pages for larger documents' is a mild usage hint but does not add significant semantic meaning beyond the schema. Thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Extract text from a PDF file.' It further clarifies the page-by-page return format, which is a concrete behavioral detail. This clearly distinguishes it from sibling tools like read_file or read_document, which could also handle files.
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 an explicit 'Use this when' clause covering read, summarise, or answer questions scenarios. It also mentions the page limit and encrypted PDF limitation, giving clear context for when to use the tool. However, it does not explicitly name alternatives or state when NOT to use it, so it doesn't quite achieve a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety profile is clear. The description goes beyond annotations by specifying case-insensitive partial matching and the return fields (PID, CPU%, memory%, status), which are useful behavioral details. It does not mention any side effects, which is consistent with the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and purpose. It includes essential details without unnecessary fluff, and every clause contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter, no output schema, and robust annotations, the description is complete. It states what the tool does, how it matches, and what it returns, leaving no significant gaps. The presence of sibling tools does not create ambiguity for this clearly described operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'name' parameter with an example, achieving 100% coverage. The description adds value by explaining the search behavior (partial, case-insensitive), which enriches the parameter's semantics beyond the schema's basic type description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for running processes by name, with specific details on case-insensitivity and partial matching. It distinguishes itself from sibling tools like get_top_processes (which lists by resource usage) and get_process_details (which retrieves a specific process's details). The verb 'searches' and object 'running processes' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need to find processes by name and get basic metrics. It provides clear context for the tool's purpose, though it does not explicitly mention alternatives or exclusions. The name itself and description are sufficient for an agent to infer when to use this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate these. It adds valuable context about the sampling method (twice over an interval) and the output units, which aligns with the annotations and provides behavioral insight beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core function and output, and every sentence earns its place. It includes usage guidance without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter), the description fully covers the return values (units for both disk and network), the measurement methodology, and the usage context. No output schema exists, so the detailed output description compensates adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage (100%) for the single parameter 'interval', including a description. The tool description adds the nuance that sampling occurs 'twice over an interval', which enriches understanding of the parameter's behavior, so it goes beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Measures') and resource ('actual disk and network I/O throughput'). It explicitly differentiates from sibling tools by naming get_disk_usage and get_network_usage, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: 'Call this instead of get_disk_usage or get_network_usage when the user asks about current speed or throughput.' This clearly indicates the intended use case and excludes other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds that results include 'names and descriptions' and clarifies that only 'available' sub-agents are listed, which is useful contextual detail beyond the 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?
Two sentences, front-loaded with the primary purpose, followed by a specific usage directive. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no params and no output schema, the description is complete: it states what is returned (names and descriptions), the scope (all available sub-agents), and when to use it. No further explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter burden. Per rubric, baseline is 4, and the description appropriately omits parameter details, adding value through usage context instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available sub-agents with their names and descriptions'—a specific verb and resource. It distinguishes the tool from siblings like run_agent (execution) and list_skills (skills) by clarifying exactly what is listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Call this before run_agent if you are unsure which agent to delegate to,' providing a clear when-to-use scenario and naming the relevant sibling tool. This is direct, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and convey no behavioral safety profile, so the description carries the full burden. It discloses key behaviors: the sub-agent runs in an isolated context with restricted tools, completes the task independently, returns only the final answer, and requires the allow_agents config setting. This is significant context beyond the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding value: purpose, usage guidance/alternatives, and a configuration prerequisite. It is front-loaded and contains no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of output schema, the description sufficiently covers the return behavior (only final answer), execution context (isolated, restricted tools), prerequisites (allow_agents config), and boundary against direct delegation. This is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 100% and both parameters (agent_name and task) have detailed descriptions in the schema itself (e.g., task must be self-contained, no conversation history access). The tool description does not add additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delegate') and identifies the resource ('a named sub-agent') with clear scope ('focused task', 'isolated context', 'restricted tool set'). It distinguishes itself from sibling tools by positioning delegation as a separate pathway from direct tool use and referencing list_agents for discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use list_agents to discover available agents' and 'Do not delegate tasks you can complete directly with other tools.' This clearly states when to use the tool versus alternatives and provides an exclusion criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool writes a permission flag, which is a side effect not captured in the annotations. It also emphasizes the consent requirement, adding context about authorization. This is valuable transparency beyond the raw hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, and directly followed by the critical usage constraint. Every sentence earns its place—no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, this description is complete. It tells the agent what the tool does, when it may be called, what it does internally, and the resulting effect. No missing information is needed for correct and safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema is trivially covered. The description adds nothing about parameters because none exist. Baseline for 0 params is 4, and the description provides no unnecessary detail.
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: granting the agent permission to control the user's browser. This is a specific verb+resource combination that distinguishes it from all sibling tools, which are either system monitoring, file operations, or browser actions themselves (e.g., browser_open_url).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the only condition for use: after the user has explicitly said yes/granted/allow. It also explains the consequence of use (subsequent browser_* calls will then work), giving clear when-to-use guidance and implying it should precede any browser_* calls.
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:

[![SysControl MCP server](https://glama.ai/mcp/servers/ks6573/SysControl/badges/card.svg)](https://glama.ai/mcp/servers/ks6573/SysControl)

Score Badge

Copy to your README.md:

[![SysControl MCP server](https://glama.ai/mcp/servers/ks6573/SysControl/badges/score.svg)](https://glama.ai/mcp/servers/ks6573/SysControl)

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/ks6573/SysControl'

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