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 covered. The description adds workflow context ('after discover_tools returns a compact match') but does not disclose additional behavioral traits such as session-related requirements or output behavior beyond what the schema and annotations already convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that communicates purpose and usage context with no filler or redundant wording. Every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity lookup tool, the description is sufficient: it has a clear trigger, full schema coverage, strong annotations, and an output schema, so return-value details do not need to be repeated in the description. The tool is fully usable as documented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters are already documented with meaningful descriptions. The tool description adds no new parameter-level semantics beyond aligning 'full description' with the 'full' boolean, but it does not need to compensate because the schema carries the burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Fetch') and a specific resource ('full description for one registered AirMCP tool'), and explicitly contrasts with discover_tools's 'compact match'. This clearly distinguishes the tool from its sibling discover_tools and makes 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'after discover_tools returns a compact match' clearly establishes when this tool should be used in relation to its main alternative. It does not explicitly state when not to use it or list alternative tools, but the contextual sequencing is strong enough for an agent to infer appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 that the tool returns 'matching tools with descriptions,' which clarifies the output nature but does not go deeper into ranking or other search behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action, and unencumbered by repetitive schema information. Every word provides value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a relatively simple keyword-search tool with comprehensive parameter descriptions, a complete annotations block, and an output schema present, the description conveys what the tool does and what it returns. There are no significant gaps that would hinder selection or invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all three parameters individually documented, including examples for query and a default for limit. The tool description itself adds no additional parameter semantics, so it sits at the baseline for high-schema-coverage tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Search available tools by keyword' and the return behavior: 'Returns matching tools with descriptions.' This distinguishes it from siblings like describe_tool (specific tool details) and run_tool (execution) by emphasizing keyword-based discovery.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys when to use it (when you need to find tools by keyword) but offers no explicit exclusions or alternatives, such as 'use describe_tool for detailed info' or 'use suggest_next_tools for recommendations.' Usage is implied, not fully mapped against siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already communicate that the operation is not read-only, is idempotent, and is not classed as destructive. The description adds the TTL context but does not disclose side effects, error behavior, or session invalidation details. Given the annotation coverage, this is adequate but not enriched.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one compact sentence, front-loaded with the action and followed by the relevant TTL condition. There is no filler or redundant explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with full annotation coverage, schema coverage, and an output schema, the description is nearly complete. It only omits minor behavioral details such as what happens when called with an already-expired or invalid session.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents sessionId as the session id returned by start_tool_session. The description adds no additional parameter-level meaning, so it stays at the schema-covered baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('End') on a specific resource ('a tool session') and adds the meaningful condition 'before its TTL expires'. This distinguishes it from associated tools like start_tool_session and tool_session_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the intended usage context reasonably clear: an active tool session should be ended before its TTL expires. It does not explicitly name alternatives or provide when-not-to-use guidance, but the relationship with start_tool_session makes the use case easy to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 well covered. The description adds value by specifying that it reads 'text content' specifically, distinguishing this from possible non-text clipboard formats.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence communicates the action and resource with no filler or repetition. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple, zero-parameter read operation with comprehensive annotations and an output schema present. The description captures the essential behavior completely for the tool's scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and schema description coverage is 100%, so the description does not need to explain parameter details. The stated behavior is consistent with a no-argument read operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Read' with a clear resource, 'the current text content of the system clipboard,' which precisely identifies the action and object. It also distinguishes itself from the sibling tool set_clipboard by making the read-vs-write difference obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied by the verb 'Read' and the clipboard resource, but the description provides no explicit guidance about when to use this tool versus alternatives. There are no stated exclusions or references to set_clipboard for write operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the agent knows this is a safe, non-mutating read. The description adds no extra behavioral context beyond repeating 'using coordinates', which is already in the schema. It does not disclose anything like data source, units, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that is concise and contains no filler. Every word contributes to the meaning, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with only two parameters, rich annotations, and an output schema, the description is complete enough. It does not need to explain return values because the output schema exists. The description adequately covers the tool's scope without requiring additional details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with each parameter having a clear description ('Latitude coordinate' and 'Longitude coordinate'). The description only says 'using coordinates', which adds no new meaning beyond schema. Since schema covers semantics fully, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get current weather conditions for a location using coordinates.' It specifies the verb (get), resource (weather conditions), and scope (current, location-based), making it unambiguous and distinguishable from forecast tools by the word 'current'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for current weather via 'current', but does not explicitly contrast with sibling tools like get_daily_forecast or provide when-to-use/not-use guidance. No alternatives are named, so the usage context is only implied, not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnly, idempotent, and non-destructive behavior, covering the safety profile. The description adds no additional behavioral context such as return format, units, or any constraints beyond what the schema already specifies. It is not misleading but adds minimal value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence that directly states the core purpose without any fluff or redundancy. It is perfectly sized and front-loaded, with every word earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple forecast tool with complete parameter schemas and robust annotations, the description is minimally adequate. However, it does not mention output structure or nuances like default days or range limits, relying entirely on the schema. Given the low complexity, this is acceptable but not exceptional.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for all parameters, and the description adds no extra explanation of latitude, longitude, or days beyond what the schema provides. Baseline 3 is appropriate since the schema fully documents parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a daily weather forecast for a location. The verb 'get' and resource 'daily weather forecast' are specific, and the name itself differentiates from sibling get_current_weather, though the description does not explicitly mention that distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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_current_weather, or any conditions for use. The description simply states the function without contextual direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it retrieves by name and returns text, which is some behavioral context but does not elaborate on error behavior or response format. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with no unnecessary words. It is front-loaded with the action and clearly communicates the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only retrieval tool with good annotations, the description covers the return type ('workflow instructions as text') and the name-based lookup. It does not discuss error handling, but that is not essential given the tool's simplicity and annotation coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters. The description only reiterates the 'name' parameter ('by name') and does not mention 'args'. It adds minimal value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Retrieve') and clearly identifies the resource ('registered MCP prompt') and the output ('workflow instructions as text'). This clearly distinguishes it from sibling tools like get_clipboard or workflow_readiness.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 workflow instructions for a registered prompt) but provides no explicit context, exclusions, or alternatives. There is no mention of when not to use it or how it compares to similar tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description adds value by highlighting the need for confirmation and the dryRun workflow. It also mentions 'repair, update, or uninstall' which implies mutating behavior, complementing the 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the action and key workflow guidance. No filler or redundancy; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 params, one required, destructive action) and the presence of an output schema, the description covers the core workflow (dryRun first, confirmation needed) and the package scope. It doesn't describe return values, but that is expected to be in the output schema. Overall, adequate for agent selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover all parameters (100% coverage) with clear explanations for pack, action, dryRun, and confirm. The description does not add extra parameter detail beyond what's in the schema; the baseline of 3 is appropriate since the schema already carries the burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Install, repair, update, or uninstall one AirMCP add-on package' – a specific verb-resource combination. It distinguishes from sibling tools like list_module_packs (listing) and preview_action (preview) by focusing on the mutating operations and explicit user confirmation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit guideline to 'Use dryRun first to preview the npm command' and emphasizes 'after explicit user confirmation', which sets expectations for prerequisites. However, it does not explicitly mention alternatives or when not to use the tool, relying on the action enum and sibling names to infer scope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds 'with metadata' which is return content, not additional behavioral context like pagination, sorting, or error handling. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes to the tool's purpose and output characteristics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a robust input schema (100% param coverage), clear annotations, and an output schema present, the description is sufficient for a simple list operation. It might lack explicit behavioral details, but the combination of structured data and description is complete enough for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning to the parameters beyond what the schema already provides (e.g., 'path' as absolute directory path, 'limit' with default).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'List files and folders in a directory' which is a specific verb+resource, and adds metadata details (kind, size, modification date). This clearly distinguishes it from sibling tools like list_notes or list_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when directory contents are needed but provides no explicit when-to-use/when-not-to-use guidance or alternatives. Unlike high-scoring examples, it does not mention when another tool would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate that this is a safe read operation. It adds value by mentioning pagination support (limit/offset) and the optional calendar filter. It does not describe potential performance implications or edge cases like empty results, but with the existing annotations this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the primary purpose. It avoids fluff and repeats no structural details. Every clause is informative: the date range requirement, the optional filter, and pagination support are all mentioned without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description doesn't need to explain return values. It covers the essential usage constraints (required date range, optional calendar, pagination) and is adequate for a read-only listing tool with strong annotations. It could mention inclusive/exclusive date boundaries or timezone handling, but these are minor and not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents all five parameters. The description reinforces that startDate and endDate are required and mentions the optional calendar filter and pagination, but adds little beyond the schema. It does highlight the required fields, which is helpful, but the incremental value is marginal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List events within a date range.' It specifies the resource (events) and the core scope (date range), which distinguishes it from sibling tools like list_notes or list_reminders. The verb 'list' is direct and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides implicit usage guidance by stating required parameters (startDate and endDate) and optional filters (calendar) and pagination. However, it does not explicitly mention when to use this tool instead of alternatives like today_events, nor does it describe when not to use it. It could benefit from naming a specific alternative for narrower queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the behavioral detail that the list includes availability status in the current runtime, which is a meaningful piece of information not present in annotations. This meets the lower bar set by strong annotations and adds a useful nuance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly states the tool's function and one key behavioral nuance. It is concise and free of fluff. The only minor downside is the potentially ambiguous 'DLC-like' jargon, but this does not detract significantly from clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with zero parameters, a robust set of annotations, and an output schema provided, the description is sufficiently complete. It covers both the primary action (list) and the key return detail (availability). No extra configuration or side effects require explanation, so this is adequate for the low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters in the schema, so per the rubric, the baseline is 4. The description does not need to explain parameter behavior, and no further details are required for the agent to invoke the tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'List' and a specific resource 'DLC-like AirMCP module packs', and adds the availability check dimension, distinguishing it from sibling list tools like list_shortcuts, list_notes, and list_directory. The phrase 'whether each pack is available in the current runtime configuration' adds a unique scope that clarifies the tool's purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. Sibling tools such as list_shortcuts and list_notes exist, but no differentiation or explicit exclusions are given. The phrase 'current runtime configuration' hints at context but does not direct an agent on when to select this tool over another.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds details on filtering and pagination, which are behavioral traits not in annotations. It does not specify return format or edge cases, but with an output schema present and the provided context, the description adds moderate value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose, then details. Every sentence earns its place, with no fluff or redundancy. It is suitably concise for a simple listing operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the presence of an output schema, and comprehensive parameter descriptions in the schema, the description is complete enough. It covers the key behavior (list, filter, paginate) without needing to restate return structure or error handling, which are expected to be in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: each parameter (limit, offset, folder) is described with default values and constraints. The description mentions pagination and folder filter but adds no new semantic detail beyond what the schema already provides. The baseline of 3 applies since the schema carries the full parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list), resource (all notes), and the specific data returned (title, folder, dates). It distinguishes from siblings like read_note (single note) and search_notes (search for specific criteria) by indicating a full listing operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives context about optional folder filtering and pagination, implying this tool is for broad enumeration. However, it does not explicitly instruct when to use this versus search_notes or read_note, nor does it mention exclusions. The usage is implied rather than explicitly guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 covered. The description adds conceptual context about profiles and toolExposure, but no additional behavioral details like return format or ordering. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with the core purpose front-loaded. The second sentence adds meaningful conceptual information without padding or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only listing tool with an output schema and strong annotations, the description is fully sufficient. It explains what is listed and why profiles matter, and the structured metadata covers the remaining operational details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no schema description to enrich. The description does not need to explain parameters, and the baseline of 4 is appropriate for the no-parameter case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the specific action 'List' and resource 'AirMCP runtime profiles', making the tool's purpose immediately clear. It also differentiates the concept by explaining that profiles select which modules load, which helps distinguish it from listing other resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful context about how profiles relate to module loading and the tools/list surface, implying when profile listing matters. However, it does not explicitly compare this tool to alternatives like profile_status or suggest 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.

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 clear. The description adds behavioral details about optional filters and pagination via limit/offset, which are not fully stated in the annotations but align with them. It does not contradict annotations and provides enough transparency for this read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise at two sentences, front-loads the core action, and includes only essential details about filters and pagination. No redundant or irrelevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, comprehensive parameter documentation, and safety annotations, the description adequately covers the tool's functionality. It mentions filters and pagination but does not explicitly state default behavior for no filters, though this is implied and covered by schema defaults. Overall, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameters are well documented. The description adds minimal value by paraphrasing the filter and pagination behavior, but it does not provide additional semantics beyond the schema. Baseline of 3 is appropriate given high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists reminders, a specific resource, and distinguishes it from siblings like list_notes or list_events by name. It also mentions optional filters and pagination, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving reminders and mentions filtering options, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., list_notes, list_events). No exclusions or alternative tool references are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 description does not need to repeat these. It adds the scope 'on this Mac' which is useful context. However, it does not disclose details like whether the list is sorted, whether it includes hidden shortcuts, or any rate limits. Given annotations, the bar is lower, so a 3 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no fluff. It is front-loaded and immediately conveys the tool's purpose. It is an excellent example of economy of language.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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, an output schema, and comprehensive annotations, the description is complete. It tells the user exactly what is returned (all shortcuts) and the context (this Mac). There is no missing information that would hinder usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is nothing to explain. The schema coverage is trivially 100%. The description does not add parameter information because none exists, which is acceptable. The baseline for zero parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action (list) and resource (Siri Shortcuts on this Mac). It is specific and distinct from siblings like run_shortcut, which runs a shortcut rather than listing them. The scope 'on this Mac' adds useful context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that run_shortcut is needed to execute shortcuts, nor any prerequisites or exclusions. A user must infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the 'dry-run' and validation-against-schema behavior, which is beyond the annotations and provides useful context about the tool's non-executing nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that conveys the essential purpose and behavior without any filler. Every word adds value and it is front-loaded with the key concept.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, annotations cover the safety profile, and there is an output schema (not shown but present). The description adequately covers the main behavioral trait (no execution) and validation, making it complete for an agent to understand usage without needing more detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides for the 'tool' and 'args' parameters. No extra insight is given about parameter format or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('preview') and resource ('a tool call'), and clearly distinguishes it from execution with 'WITHOUT executing it.' This differentiates from sibling tools like run_tool and describe_tool effectively.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies a governance/preview use case but does not explicitly state when to use this tool versus alternatives such as run_tool or describe_tool. No explicit exclusions or 'when not to use' guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 valuable context beyond these by disclosing the deterministic, time/usage-based nature of the heuristic and the install-specific perspective, which are not evident from the structured fields alone. The absence of side effects (matching idempotency) is reinforced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the action, defines the resource, and provides the key ranking criteria. Every phrase earns its place with zero redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (0 params), strong annotations, and presence of an output schema, the description provides sufficient context for an agent to use the tool correctly. The deterministic heuristic is well-specified, though a brief note on the default behavior when usage counts are unavailable could make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0 parameters and 100% schema coverage, the baseline is 4 per the rubric. The description adds behavioral context about how rankings are computed, though no parameter-specific clarification is needed since there are no parameters to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Return' with a clear resource (tool/workflow candidates) and distinguishes itself through a unique ranking mechanism ('deterministic heuristic over the current time of day, day of week, and this install's tallied usage counts'). This clearly differentiates it from siblings like suggest_next_tools or get_workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by the name and description (proactive suggestion), but there is no explicit guidance on when to prefer this tool over alternatives like suggest_next_tools or get_workflow. No exclusion criteria or alternative references are provided, so the agent must infer when the tool should be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which fully cover the safety profile,Skip The description adds context about what specific data points are returned (profile, module set, exposure mode, counts), which complements the annotations by specifying the scope of the read operation. No contradiction exists between the description 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the primary action ('Show the active AirMCP profile') and then lists the specific details returned. There are no redundant or unnecessary words, and every element earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 nested objects, and a simple read-only purpose, the description is complete. It lists all the relevant output fields, and with an output schema already present, the agent can infer the exact return format. The description leaves no ambiguity about what the tool does.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero parameters, so the description doesn't need to explain parameter usage. The baseline for zero parameters is 4, and the description appropriately focuses on what the tool returns rather than inputs. It fully compensates for the absence of parameter documentation by describing the output structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: displaying the active AirMCP profile, module set, tool exposure mode, exposed tool count, and total registered tool count. It uses specific verbs and resource types, distinguishing it from potentially similar status-like tools like 'tool_session_status' or 'workflow_readiness' by focusing on profile/module configuration metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly clarifies its use as a read-only status/inspection command, useful for checking the current profile configuration)Skip The description clearly states the tool is a read-only inspection command for viewing configuration details)Skip It doesn't explicitly state when not to use it or name alternative tools, but the purpose is clear enough that an agent can infer when this status check is appropriate. The sibling list includes other status tools, but no explicit guidance for choosing between them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 return includes HTML body and plaintext, which is useful but not deeply behavioral. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that immediately states the verb and resource, followed by return type. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one required parameter), has full annotations, and an output schema. The description sufficiently covers the tool's purpose and return format without needing extra detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description ('Note ID (x-coredata:// format)') and maxLength. The tool description does not add additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (read), the resource (a specific note), and the selection criterion (by its ID). It also distinguishes from siblings like list_notes and search_notes by focusing on a single note's full content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool: when you have a specific note ID and need the full content. It does not explicitly mention alternatives or exclusions, but the context 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint and non-idempotency, and the description adds a valuable specific warning about UI prompts and system actions. It also discloses that the shortcut's output is returned. This goes beyond the annotations, though the phrase 'system actions' is slightly generic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is composed of four short, information-dense sentences with zero fluff. The primary action is front-loaded, and each additional sentence adds a distinct detail (input, output, side-effect warning).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even without an output schema, the description covers all essential aspects: what it does, how to invoke it (by name), optional input, return value, and potential side effects. For a 2-parameter tool with rich annotations, this is complete and sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters ('exact match' and 'Optional text input'). The description merely echoes the input parameter with 'Optionally provide text input' and adds no new semantic meaning, 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.

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: 'Run a Siri Shortcut by name.' It clearly distinguishes from siblings like list_shortcuts and specifies optional input and return value, leaving no ambiguity about the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context: run a shortcut by name with optional text input. It doesn't explicitly state when to avoid this tool or name alternatives, but the purpose is self-evident and aligned with the sibling list (e.g., list_shortcuts for listing, run_shortcut for executing).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations provide no safety hints because all flags are false, and the description does not add important behavioral context. A generic runner that invokes arbitrary tools should disclose potential side effects, execution behavior, or return flow, but the description only says 'Run', which is under-specified for a dynamic dispatch tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the primary action and enriched with one practical discovery tip. No wasted words or redundancy with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generic tool runner, the description covers the core runtime action and the important discover-first fallback. The absence of an output schema is somewhat mitigated by the dynamic nature of the tool, but a note on what the response contains would have been helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameter meaning already comes from the schema. The description adds only the generic phrase 'by name with JSON arguments', which does not materially improve parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: run an AirMCP tool by name with JSON arguments. It also distinguishes this from sibling tools by mentioning discover_tools as the complementary discovery step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance to use discover_tools first when the tool is not visible in tools/list. It does not list exhaustive when-not-to-use scenarios, but the main alternative discovery flow is clearly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the search scope and preview length, but no behavioral side-effects, auth requirements, rate limits, or pagination caveats beyond what the schema provides. It adds some context 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the action, and contains no redundant words. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only search tool with comprehensive schema and annotations, the description adequately covers purpose, scope, and return preview. It could mention pagination (offset/limit) but those are already in the schema, so overall it is complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and all parameters have descriptions, so the description does not add meaning beyond the schema. The baseline score of 3 applies because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Search') with a clear resource ('notes') and defines scope ('by keyword in title and body'), distinguishing it from sibling tools like list_notes (list all) and read_note (read a single note). It also states what is returned (matching notes with a preview).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for finding notes by keyword, but it does not explicitly state when to use it over alternatives like list_notes or read_note, nor does it provide exclusions or conditions. The usage context is clear but not directly compared to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds the 'replacing its current content' detail, which is useful and goes beyond annotations, but overall disclosure is minimal, and no permission or side-effect details are given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with no redundancy; it states the action and effect efficiently. Each word contributes to meaning, and the description is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with a single well-documented parameter and an existing output schema (per context signals). The description covers the essential behavior, including replacement, and no significant gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema fully documents the single parameter with 'Text to copy to the clipboard'. The tool description repeats this meaning without adding new format, constraints, or usage nuances, so it adds negligible value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Write text to the system clipboard, replacing its current content' is a specific verb-resource pair (write + clipboard) with a clear scope. It also distinguishes from the sibling get_clipboard, which reads the clipboard.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the description's clarity, but no explicit when-to-use or alternatives are mentioned. It does not contrast with get_clipboard or other sibling tools, offering only implicit context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that it creates a session with a time limit ('short-lived') and mentions the scoping behavior, which is the key side effect. It does not fully detail all consequences (e.g., what happens upon expiry), but the annotations (all false) are not contradicted, and the description provides a reasonable understanding of the tool's non-readonly nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two short sentences with no redundant information. It efficiently conveys the core functionality and use case without any fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool of this complexity, the description covers the essential aspects: creation of a scoped session, its temporary nature, and the intended use. It does not delve into lifecycle details (e.g., how to end or extend), but these are not critical for basic understanding and are partially covered by the parameter descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds minimal meaning to the parameters beyond what the schema already provides. It indirectly references the 'tools' parameter via 'allowlist' and hints at 'ttlSeconds' with 'short-lived,' but does not elaborate on 'label' or default behaviors. Since the schema descriptions are complete, the description's contribution is marginal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states that the tool creates a short-lived allowlist for specific tools, providing a clear and unambiguous purpose. It also explains the intended use case (scoping a task to only needed tools), making the function obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a direct instruction on when to use the tool: 'Use this to keep a task scoped to the tools it actually needs.' This clearly conveys the appropriate context and differentiates it from broader tool access, even without explicitly naming alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate a read-only, idempotent operation. The description adds that it ranks by frequency in local call history, which is behavioral context not captured by annotations. It doesn't explain edge cases but the output schema covers return structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, efficiently conveys purpose and context. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-param tool with full schema descriptions and output schema, the description fully covers the tool's behavior and data source. No notable gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters are fully described in the schema, and the description reinforces that 'after' is the tool name. No additional semantics needed beyond schema, so baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (rank), the resource (tools that followed a given tool), and the context (local call history). This distinguishes it from sibling discovery tools like discover_tools or describe_tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case: when you need to know which tools are commonly used after a specific tool, based on local history. It doesn't mention alternatives or exclusions, but the context is clear enough for an agent to choose this over generic discovery tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description only adds the time scope ('today'). It does not disclose potential behavioral details such as timezone handling, ordering, or whether only certain calendar types are included, but this is acceptable given annotations cover the safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence: 'Get all calendar events for today.' Every word adds meaning and there is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 an output schema, the description is complete enough. It states exactly what will be returned (all calendar events) and the time scope (today), and the structured annotations and output schema cover remaining details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema coverage is trivially complete, so no parameter explanation is needed. The description appropriately focuses on scope rather than parameter syntax.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('all calendar events for today'), clearly stating scope. It differentiates from sibling 'list_events' by narrowing to today's calendar events, eliminating ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for retrieving today's calendar events but provides no explicit guidance about when to choose this over sibling tools like 'list_events' or whether it excludes other date ranges. Context is clear but no alternatives or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish that the tool is read-only, idempotent, and non-destructive, which significantly lowers the burden on the description. The description adds context about inspecting only one active session and not viewing other clients' sessions, but it does not provide deeper behavioral details like error conditions, auth requirements, or what happens when a session is not found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence, front-loaded with the core action, and contains no filler or redundant wording. Every word contributes to understanding the tool's purpose and scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple one-parameter, read-only inspection tool with full annotations and an output schema present. The description covers the object and scope adequately; nothing important is missing 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the sessionId property already explains it is returned by start_tool_session. The tool description only says 'by id,' which adds no additional semantic value beyond what the input schema already provides, so the baseline score is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Inspect one active tool session by id') and explicitly differentiates its behavior from listing ('without checking other clients' sessions'). This clearly distinguishes it from session lifecycle siblings like start_tool_session and end_tool_session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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: when you need to inspect a specific active session by its ID. It also conveys a scope boundary by noting it does not list other clients' sessions, but it does not explicitly name alternatives or say 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only operation. The description adds behavioral detail beyond these flags by specifying what readiness includes (missing modules, add-ons, tools, write opt-ins) and the 'active runtime' scope, giving the agent a clearer picture of the tool's output focus.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly states the tool's purpose without filler. Every element (workflows, readiness, specific dimensions) earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 one optional parameter and an output schema, the description provides sufficient context. It explains the scope ('curated AirMCP workflows', 'active runtime') and the key readiness factors. It does not specify return format, but the existence of an output schema covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage: the only parameter 'id' is already described with examples in the schema. The description does not add any extra parameter-level meaning, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Explain' and clearly identifies the resource as 'curated AirMCP workflows' and their readiness in the active runtime. It enumerates the readiness dimensions (missing modules, add-ons, tools, write opt-ins), which distinguishes it from sibling tools like get_workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied: use this tool to check if workflows are ready. However, the description does not explicitly mention when to use this tool versus alternatives such as profile_status or get_workflow, nor does it provide 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.