hmr

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

The annotations include readOnlyHint: true, indicating it's a safe read operation. The description adds that it 'provides information' and is a 'brief and concise explanation,' which aligns with read-only behavior. However, it doesn't disclose additional traits like potential rate limits, authentication needs, or what 'information' entails (e.g., format, depth), so it adds some context but not rich behavioral details beyond the annotation.

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 short and to the point, with three sentences that each serve a purpose: stating what it does, providing usage context, and giving a directive. It's front-loaded with the tool's function, but the last sentence could be more integrated, and there's minor redundancy in mentioning 'brief and concise.' Overall, it's efficient with minimal waste.

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, annotations cover read-only behavior, and no output schema exists, the description is somewhat complete but lacks depth. It explains the purpose and usage but doesn't detail what 'information' includes (e.g., examples, links, structured data) or how it relates to sibling tools, which could help an agent understand its role better in this context.

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 no parameters (parameter count: 0), with 100% schema description coverage. The description doesn't mention parameters, which is appropriate since none exist. This baseline is high because no parameters need explanation, and the description doesn't add or detract from parameter semantics.

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 tool provides 'information on how to use reactive programming or use hot module reloading in Python' and explains the `hmr` library, which gives a general purpose. However, it doesn't specify what exact information is provided (e.g., documentation, examples, API reference) or how it differs from its siblings 'view-hmr-core-sources' and 'view-hmr-unit-tests', making it somewhat vague rather than clearly distinct.

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 explicitly states 'As long as the user mentions HMR / Reactive Programming, this tool must be called first! Don't manually view the resource, call this tool instead.' This provides clear context on when to use it (for HMR/reactive programming topics) and a directive to prioritize it, but it doesn't specify when not to use it or name alternatives like the sibling tools, so it's not fully comprehensive.

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 the description aligns by not implying any mutation. It adds valuable context beyond annotations: the response is identical to an MCP resource, it should be used only once, and it's self-documented code. No contradictions with annotations are present.

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 moderately concise but includes some repetitive elements, such as reiterating that the code is self-documented and mentioning the MCP resource multiple times. It could be more front-loaded, but most sentences contribute to usage guidelines.

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 (simple read-only with no parameters) and the presence of annotations (readOnlyHint=true) but no output schema, the description is fairly complete. It covers purpose, usage prerequisites, behavioral notes, and alternatives, though it could better explain the output format or limitations.

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 description coverage, the baseline is 4. The description appropriately doesn't discuss parameters, as none exist, and instead focuses on usage context, which adds value without redundancy.

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 provides 'the full source code (core only) of the HMR library,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'view-hmr-unit-tests' beyond mentioning unit tests are for learning usage, leaving some ambiguity about scope distinctions.

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 explicit guidance on when to use this tool: always call 'learn-hmr-concepts' first, refer to 'hmr-docs://about' for a brief explanation, and read unit tests later for usage learning. It also states to 'prefer this tool to that resource if you can choose,' offering clear alternatives and prerequisites.

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 adds valuable behavioral context beyond the annotations. While annotations indicate readOnlyHint=true, the description clarifies that the response is 'identical to the MCP resource with the same name', provides usage frequency guidance ('Only use it once'), and explains the tool's role in demonstrating coding patterns. It does not contradict the read-only annotation, as viewing unit tests aligns with a read operation.

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

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

The description is well-structured and front-loaded, starting with the tool's purpose and immediately providing usage guidelines. Most sentences earn their place by adding value, such as prerequisites and behavioral details, though the last sentence could be slightly more concise. Overall, it efficiently conveys necessary information without unnecessary elaboration.

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 (simple read-only operation with no parameters), the description is complete. It covers purpose, usage guidelines, behavioral context, and sibling relationships. With annotations providing read-only context and no output schema needed for a view tool, the description adequately fills in all gaps, making it self-sufficient for an AI agent.

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 description coverage, the baseline is 4. The description adds no parameter-specific information, which is appropriate since there are no parameters to document, and it effectively compensates by explaining the tool's purpose and usage context.

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: to retrieve unit tests (code examples) for the HMR library. It specifies the resource ('unit tests for HMR'), distinguishes it from siblings by mentioning they are 'files' that 'demonstrate best practices and common coding patterns', and uses specific verbs like 'view' and 'use' to indicate its 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?

The description provides explicit guidance on when to use this tool: 'when you need to write some code using the HMR library'. It also specifies prerequisites ('Always call `learn-hmr-basics` and `view-hmr-core-sources` to learn the core functionality before calling this tool') and distinguishes it from alternatives by stating 'prefer this tool to that resource if you can choose', referring to a similar MCP resource.

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