Remember Me Collections

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

The description adds valuable context beyond annotations by specifying that it browses 'published' collections (implying there may be unpublished ones), and mentions pagination behavior through limit/offset parameters. While annotations cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true), the description adds practical usage context about what kind of data is accessible.

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 with the core purpose, followed by detailed parameter explanations. Every sentence earns its place - the first sentence establishes purpose and capabilities, and the Args section efficiently documents all parameters with clear examples and constraints.

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 this is a read-only browsing tool with comprehensive annotations, 0% schema description coverage compensated by excellent parameter documentation in the description, and the existence of an output schema (which means return values don't need explanation), the description is complete enough. It covers purpose, usage context, and all parameter semantics thoroughly.

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% schema description coverage, the description carries the full burden of explaining parameters and does so comprehensively. It provides clear semantics for all 5 parameters: search term scope, language code format, ordering options with defaults, limit range, and offset purpose for pagination. This adds significant value beyond the bare 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 the verb ('browse') and resource ('published Bible verse collections'), and distinguishes this tool from its siblings by specifying it's for browsing/searching collections rather than getting detailed information (get_collection_detail) or metrics (get_collection_metrics). The description explicitly mentions search, filter, and sort capabilities.

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 clear context about when to use this tool ('browse published Bible verse collections'), but doesn't explicitly state when NOT to use it or directly compare it to the sibling tools. The mention of search/filter/sort capabilities implies usage scenarios, but lacks explicit 'use this when X, use sibling Y when Z' guidance.

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 provide safety and behavior hints (readOnly, non-destructive, idempotent, closed-world). The description adds valuable context by specifying it retrieves 'full details' including specific content types (verse text, references, topics), which helps the agent understand the depth and nature of the returned data beyond what annotations indicate.

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 efficiently structured with a clear purpose statement followed by a concise parameter explanation. Every sentence adds value: the first defines the tool's scope, and the second clarifies the parameter's usage. No wasted words 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?

Given the tool's low complexity (1 parameter), rich annotations covering safety and behavior, and the presence of an output schema (which handles return values), the description is complete. It provides purpose, parameter guidance, and content details, leaving no significant gaps for the agent to operate effectively.

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% schema description coverage, the description fully compensates by clearly explaining the single parameter's purpose and source ('collection_id: The collection ID (from browse_collections results)'). This adds essential meaning beyond the bare schema, making the parameter's role and origin clear.

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 specific action ('Get full details') and resource ('published collection'), with explicit scope ('including all verse text, references, and topics'). It distinguishes from sibling tools (browse_collections, get_collection_metrics) by focusing on detailed content rather than listing or 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 provides clear context by specifying it's for 'published collection' details and referencing the source of collection_id ('from browse_collections results'), which helps guide usage. However, it doesn't explicitly state when not to use it or name alternatives like get_collection_metrics for different purposes.

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 provide key behavioral hints (readOnlyHint: true, destructiveHint: false, etc.), so the description's burden is lower. It adds useful context by specifying the types of metrics retrieved (e.g., memorization progress, activity stats), which isn't covered by annotations. No contradictions with annotations are present, and it offers additional operational insight.

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 appropriately sized and front-loaded, starting with the core purpose in the first sentence and following with parameter details. Every sentence adds value, with no wasted words, though the structure could be slightly more polished (e.g., bullet points for metrics).

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 operation with one parameter), rich annotations (covering safety and idempotency), and the presence of an output schema (which handles return values), the description is sufficiently complete. It explains what metrics are retrieved and parameter semantics, addressing key gaps without overloading with redundant information.

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 0%, so the description must compensate. It explains that 'collection_id' is 'The collection ID (from browse_collections results)', adding semantic meaning about the parameter's source and purpose beyond the schema's basic type and title. This effectively clarifies the parameter, though it could be more detailed (e.g., 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 clearly states the tool's purpose with specific verbs ('Get community engagement metrics') and resources ('memorization progress, verse mastery, difficult verses, and activity stats'), making it easy to understand what data is retrieved. However, it doesn't explicitly differentiate from sibling tools like 'get_collection_detail', which might also provide collection-related information, so it falls short of a perfect score.

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 by referencing 'collection_id (from browse_collections results)', suggesting a workflow where this tool follows browsing, but it doesn't explicitly state when to use this tool versus alternatives like 'get_collection_detail' or provide clear exclusions. This gives some context but lacks detailed guidance on tool selection.

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