MemeStack

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

Annotations already provide excellent coverage (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), so the bar is lower. The description adds valuable context by explaining what categories are and providing examples, which helps the agent understand the domain semantics beyond the structured annotations.

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

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

The description is perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second provides helpful context about categories with concrete examples. 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 simplicity (1 parameter, good annotations, no output schema), the description is reasonably complete. It explains what the tool returns ('category and its featured images') and provides domain context about categories. However, it doesn't describe the response format or what 'featured images' entails, which would be helpful since there's no output 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?

With 100% schema description coverage, the schema already fully documents the single 'category' parameter. The description adds minimal value beyond the schema by providing category examples ('charts', 'memes', 'lightning-network'), but doesn't explain parameter semantics beyond what's already in the schema description.

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') and resources ('a category and its featured images'), and distinguishes it from siblings by explaining that 'Categories group related tags' - differentiating it from tools like 'browse_by_tag' or 'browse_images'.

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 some context about what categories are and gives examples, which implies usage for exploring grouped content. However, it doesn't explicitly state when to use this tool versus alternatives like 'browse_by_tag', 'list_categories', or 'search_images', leaving the agent to infer the best choice.

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 context beyond annotations: it specifies that the response includes both tag profile and optionally paginated images, and that pagination depends on the 'limit' parameter. Annotations already cover safety (readOnlyHint=true, destructiveHint=false) and idempotency, but the description clarifies the dual-response behavior and conditional inclusion of images, which is not inferable from annotations alone.

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

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

The description is two sentences that are front-loaded with the core purpose and efficiently cover key behavioral details (response content and pagination condition). Every sentence adds value without redundancy, making it appropriately sized and well-structured for quick understanding.

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 moderate complexity (3 parameters, no output schema), the description is mostly complete: it explains the dual-response nature and pagination logic. However, it doesn't detail error cases or response format specifics, which could be helpful since there's no output schema. With good annotations covering safety and idempotency, it's largely adequate but has minor 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?

The description mentions that 'limit' controls pagination and image inclusion, adding semantic context beyond the schema's technical descriptions. However, with 100% schema description coverage, the schema already documents all parameters well (e.g., 'tag' as slug, 'limit' range, 'offset' purpose), so the description's added value is moderate, aligning with the baseline for high schema 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 specific action ('browse images for a specific tag') and distinguishes it from siblings like 'browse_by_category', 'get_tag_profile', or 'search_images' by specifying it returns both tag profile and optionally paginated images. It uses precise verbs ('browse', 'returns') and identifies the resource ('images', 'tag profile').

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 context by stating it's for browsing images by tag and optionally including paginated results, but it doesn't explicitly state when to use this tool versus alternatives like 'get_tag_profile' (which might only return tag metadata) or 'search_images' (which might allow broader filtering). It provides some guidance but lacks explicit exclusions or named 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 provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds context about browsing without a query but does not contradict annotations. The bar is lowered due to rich 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 sentences, front-loaded with purpose, no superfluous words, and clearly structured.

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 simple nature of the tool, the description combined with annotations and parameter schema provides sufficient context for invocation. No output schema exists but return values are implied.

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%, so the description's mention of filtering by tag and sorting aligns with schema. It does not add significant new meaning 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 the verb 'browse' and resource 'image gallery', and specifies that it works without a search query, distinguishing it from search tools.

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 indicates usage for discovering content by tag, trending, or recent uploads, implying when to use it. It does not explicitly exclude alternatives but the context from sibling tools makes the guidance clear.

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 non-destructive. The description adds value by specifying the output formats (markdown, HTML, plain-text, combined block), which is useful behavioral context 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?

Two sentences, no redundancy, front-loaded with the verb and resource, all information is essential and well-structured.

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 one parameter and no output schema, the description fully covers what the tool does, its inputs, and its outputs (format and combined block). No gaps evident.

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% for the single parameter, so baseline is 3. The description reinforces the parameter (multiple images) and mentions combined output, but does not add significant extra meaning 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 the tool generates canonical attribution blocks for MemeStack images. It uses a specific verb ('generate') and resource ('attribution blocks'), and is distinct from sibling tools which are for browsing, searching, or submitting images.

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?

Context implies the tool is for citing images, and no sibling tool performs this function. However, there is no explicit guidance on when not to use or prerequisites, though the use case is clear.

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. The description adds value by stating that it returns ready-to-embed images with citation blocks, providing useful behavioral context 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?

Two sentences with no wasted words. The first sentence states the action and output, the second gives usage context. Perfectly concise.

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 2 parameters and no output schema, the description covers purpose, output format, and usage context completely. Annotations fill safety requirements.

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%, so the schema describes both parameters. The description adds no parameter-specific details beyond what the schema provides, meeting the baseline but not exceeding it.

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 finds a meme capturing a vibe, idea, or concept, and returns ready-to-embed images. It distinguishes itself from siblings like browse_by_category and search_images by focusing on vibe-based meme retrieval.

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 says when to use the tool: when writing posts, articles, or social content needing a meme. It does not mention alternatives or when not to use, but the context is clear.

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, idempotentHint: true, openWorldHint: true), covering safety and idempotency. The description adds valuable context beyond annotations by specifying the AI embedding similarity mechanism and the semantic nature of the matching ('similar meaning/topic'), which helps the agent understand the tool's behavior and output characteristics. No contradiction with annotations exists.

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 and front-loaded, consisting of only two sentences that efficiently convey the tool's purpose and mechanism. Every sentence earns its place by providing essential information without redundancy or fluff, making it easy for an agent to parse and understand quickly.

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 moderate complexity (AI-based similarity search), rich annotations (covering read-only, idempotent, and open-world aspects), and high schema coverage, the description is largely complete. It explains the core functionality and mechanism well. However, without an output schema, it could benefit from more detail on return values (e.g., format or fields), though the annotations and context mitigate this gap. The description is sufficient but not exhaustive.

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 clear descriptions for both parameters ('id' as source image UUID and 'limit' with range and default). The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining how 'id' is used in similarity calculations or additional constraints. However, with high schema coverage, the baseline score of 3 is appropriate as the schema adequately documents the 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's purpose with specific verbs ('Find semantically related images') and resource ('images'), and distinguishes it from siblings by specifying the mechanism ('using AI embedding similarity') and outcome ('Returns images with similar meaning/topic'). This differentiates it from tools like 'find_similar' (which might use different criteria) and 'search_images' (which likely uses keyword matching).

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 context by mentioning 'semantically related' and 'similar meaning/topic', suggesting this tool is for finding conceptually similar images rather than visually similar ones. However, it does not explicitly state when to use this tool versus alternatives like 'find_similar' or 'search_images', nor does it provide exclusions or prerequisites. The guidance is present but 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?

The description adds valuable context about the matching method ('perceptual hash matching') and what gets returned ('images that look alike'), which goes beyond what the annotations provide. While annotations cover safety (readOnlyHint, non-destructive) and behavior (idempotent, openWorld), the description enhances understanding of the specific similarity algorithm.

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 perfectly concise with two sentences that each earn their place: the first explains the tool's purpose and method, the second clarifies what gets returned. No wasted words or 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 moderate complexity (perceptual hash matching), rich annotations covering safety and behavior, and no output schema, the description provides good context about what the tool does and returns. However, it could benefit from more detail about the matching algorithm or result format to be 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 100% schema description coverage, the schema already fully documents both parameters (source image UUID and result limit). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline for high schema 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 specific action ('Find visually similar images') using a specific method ('perceptual hash matching') and resource ('images'). It distinguishes from siblings like 'search_images' or 'find_related' by specifying the perceptual hash matching approach for visual similarity.

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 finding visually similar images, but doesn't explicitly state when to use this tool versus alternatives like 'find_related' or 'search_images'. No guidance is provided about when-not-to-use or specific prerequisites for effective use.

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 cover read-only, open-world, idempotent, and non-destructive traits. The description adds value by specifying the types of metadata returned (caption, alt text, tags, OCR text, zap stats, URLs), which helps agents understand the richness of data beyond basic image info. 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, efficient sentence that front-loads the core purpose and lists metadata fields without redundancy. Every element (verb, resource, ID specificity, metadata examples) contributes directly to clarity, with zero 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's low complexity (1 parameter), rich annotations (covering safety and behavior), and no output schema, the description is largely complete. It specifies metadata fields to address the output gap, though it could note error cases (e.g., invalid ID) for full completeness.

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 the single parameter 'id' documented as 'Image UUID'. The description adds no additional parameter details beyond what the schema provides, but the high coverage justifies the baseline score of 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 specific action ('Get full metadata') and resource ('a specific image by ID'), distinguishing it from siblings like browse_images (list) or search_images (filtered search). It lists detailed metadata fields (caption, alt text, tags, etc.) to clarify scope beyond basic retrieval.

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 detailed metadata for a known image ID is needed, but lacks explicit guidance on when to use alternatives (e.g., browse_images for listing, search_images for filtering). No exclusions or prerequisites are mentioned, leaving usage context partially inferred.

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?

While annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, the description adds valuable behavioral context about what the tool actually returns (top-ranked items by specific metrics) and the time-based filtering capability. This goes beyond the safety/performance hints provided by 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, efficient sentence that front-loads the core purpose and covers both leaderboard types and time period qualification. Every word earns its place with zero wasted text 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 read-only tool with comprehensive annotations and full schema coverage, the description provides adequate context about what the tool returns. However, without an output schema, it could benefit from mentioning the structure of returned data (e.g., ranked lists with scores). The description is complete enough given the tool's relative simplicity.

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 100% schema description coverage and both parameters having clear enum descriptions in the schema, the description doesn't add significant parameter semantics beyond what's already documented. It mentions the time period concept but doesn't elaborate on parameter usage beyond what the schema provides.

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 top-ranked') and distinguishes between two distinct resource types ('images by zaps received' vs 'zappers by amount zapped'), with explicit time period qualification. It differentiates from sibling tools like browse_images, get_image, and search_images by focusing on ranking rather than browsing or searching.

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 for when to use this tool (to obtain ranked lists by specific metrics over time periods) but doesn't explicitly state when not to use it or name specific alternatives among sibling tools. It implies usage for ranking purposes rather than browsing/searching individual items.

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 read-only, idempotent, non-destructive. The description adds behavioral context: it returns a collection of images (dominant + variants) with citations, and implies the concept of mutation groups. This goes beyond annotations by describing output structure and grouping logic.

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 consists of two concise sentences without extraneous information. The first sentence conveys main function, the second adds usage context. Every word is purposeful.

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 one parameter, no output schema, and rich annotations, the description covers key aspects: what it returns (dominant + variants + citations), the grouping concept, and when to use it. Lacks details on output limits or specific response format, but sufficiently complete for its simplicity.

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 only parameter, 'image_id', is described in the schema as 'Image UUID'. The description does not add further meaning, such as what kind of image ID (e.g., template's ID) or how to obtain it. With 100% schema coverage, baseline is 3; no extra semantic guidance provided.

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 ('Get all variants') and resource ('meme template tracked on MemeStack'), and specifies the output ('dominant image plus every variant... with citation blocks'). This distinguishes it from siblings like 'get_image' (single image) or 'find_similar' (visual similarity).

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 use cases: 'research how a meme has evolved' and 'find variants of a known image'. However, it does not contrast with similar tools or specify when not to use it, leaving room for improvement compared to ideal guidelines.

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 this is a read-only, non-destructive, idempotent operation with open-world semantics. The description adds value by specifying what data is included (e.g., 'image count, total zaps') and what is excluded ('without fetching any images'), but does not detail behavioral aspects like rate limits, error conditions, or response format beyond the listed fields.

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 that are front-loaded with the core purpose and efficiently contrast with the sibling tool. Every word serves a clear function, with no redundancy or unnecessary elaboration, making it highly concise and well-structured.

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

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

Given the tool's simplicity (one parameter, no output schema) and rich annotations, the description is mostly complete. It covers purpose, usage guidelines, and data scope, but lacks details on output structure (e.g., format of 'related tags') or potential errors, which could be helpful despite the annotations.

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% description coverage, fully documenting the single required parameter 'tag' as a slug. The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating with extra details.

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 the profile for a tag') and enumerates the exact data returned ('description, image count, total zaps, related tags'), distinguishing it from sibling tools like 'browse_by_tag' which retrieves images. It explicitly contrasts with the sibling tool, 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 provides explicit guidance on when to use this tool ('without fetching any images') and when to use an alternative ('Use browse_by_tag to also retrieve images'). This directly addresses the choice between sibling tools, offering clear context for selection.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds minimal behavioral context by specifying it retrieves 'public' profile data, implying no authentication needs and limited scope. However, it doesn't disclose rate limits, error conditions, or data freshness, leaving gaps despite 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, efficient sentence with zero waste. It front-loads the core action ('Get a user's public profile') and succinctly lists included data points. Every word contributes to understanding the tool's purpose without redundancy or 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?

Given the tool's low complexity (1 parameter, no output schema, no nested objects) and rich annotations covering key behavioral traits, the description is minimally adequate. It specifies the data returned but lacks details on response format or error handling. With annotations providing safety and idempotency, the description meets basic needs but could be more complete for agent use.

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 the parameter 'identifier' fully documented in the schema as 'User public key (hex) or UUID'. The description adds no additional parameter semantics beyond implying the identifier targets a user. Since the schema handles the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.

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 ('Get') and resource ('user's public profile') with specific content details ('display name, stats, and avatar info'). It distinguishes from sibling tools like get_leaderboard or search_images by focusing on individual user profiles rather than rankings or image searches. However, it doesn't explicitly differentiate from hypothetical user-related siblings that might exist on other servers.

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 doesn't mention prerequisites (e.g., needing a valid identifier), exclusions (e.g., what happens if the user doesn't exist), or comparisons to sibling tools like get_leaderboard for aggregated user data. Usage is implied through the action but lacks explicit 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 adds valuable context about the tool's purpose as a discovery mechanism, which goes beyond what the annotations provide. While annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, the description clarifies the tool's role in the workflow. No contradiction with annotations exists.

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 perfectly concise with two sentences that each serve a clear purpose: stating the tool's function and providing usage guidance. There is zero wasted text, and it's front-loaded with the core functionality.

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 no parameters, rich annotations (including readOnlyHint, openWorldHint, idempotentHint), and clear sibling differentiation, the description provides exactly what's needed. It explains the tool's purpose, when to use it, and how it fits into the workflow without needing to cover outputs or complex behaviors.

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 would be 4. The description appropriately doesn't discuss parameters since there are none, which is correct for this tool. No additional parameter information is needed or provided.

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 ('List all available image categories') and resource ('image categories'), and explicitly distinguishes it from the sibling tool 'browse_by_category' by indicating its preparatory role. This provides excellent differentiation from other tools in the server.

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 when to use this tool ('to discover what categories exist before calling browse_by_category'), providing clear context and naming a specific alternative. This gives the agent perfect guidance on when this tool is appropriate versus its sibling.

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 read-only and idempotent behavior. Description adds that the list is sorted by all-time usage count and that temporal filtering is unsupported, giving additional behavioral context 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?

Two sentences: one for core purpose, one for important caveat. Front-loaded and no unnecessary 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?

With one simple parameter and no output schema, description adequately covers tool behavior and limitation. Agent can infer return format from purpose, though explicit structure would improve completeness slightly.

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 documented 'limit' parameter. Description does not elaborate on parameter meaning beyond what schema provides, so baseline score applies.

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?

Clearly states the tool lists the most-used tags by all-time usage count, with specific verb 'list' and resource 'tags'. Distinguishes from sibling tools like browse_by_tag and tag_autocomplete by focusing on popularity metric and time constraint.

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?

Explicitly notes that time-period filtering is not supported, guiding agent on a key limitation. However, does not mention when to avoid this tool in favor of siblings like get_tag_profile or browse_by_tag for non-popular or filtered 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, openWorldHint, idempotentHint, and destructiveHint. The description adds value by disclosing rate limits (10/min/IP), hashing algorithm (dHash), and output format (citation blocks), providing behavioral context 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?

Three sentences, front-loaded with purpose, input types, output, and constraints. Every sentence adds necessary information, no 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 with 2 parameters and no output schema, the description covers input types, algorithm, output summary, and rate limiting. It is fully sufficient for an agent to understand and use the tool 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 coverage is 100%, so baseline is 3. The description mentions the accepted URL formats and default limit, but the schema already describes these adequately. No additional meaning beyond 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 tool finds visually similar images from MemeStack given an image URL. It uses specific verbs and resources but does not explicitly differentiate from sibling tools like 'find_similar', so it lacks sibling 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?

Usage is implied: upload or provide an image URL to find similar images. However, no explicit guidance on when to use this vs. text-based search or other siblings, and no 'when-not-to-use' or alternative tools 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 mark it as readOnly and idempotent. The description adds valuable behavioral context: it runs two search modes in parallel and merges results. This provides transparency beyond the annotations.

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

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

Three concise sentences front-load the purpose and key behavior. No fluff 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?

With 7 parameters, no output schema, but the description explains the parallel matching and return fields. It could mention that results are paginated, but schema already covers limit/offset. Missing typical output format hints, but 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% and each parameter's description in the schema is adequate. The tool description adds no further parameter semantics beyond what the schema already provides.

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 searches the MemeStack image gallery using semantic AI and keyword matching in parallel. It specifies the returned fields (captions, tags, zap stats, URLs), distinguishing it from sibling tools like reverse_image_search or browse_by_tag.

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 as a general search tool, but it lacks explicit guidance on when to use it versus alternatives like find_similar or search_text_in_image. No when-not or alternative recommendations.

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 adds only slight value by clarifying that search is on OCR text only. No additional behavioral traits are disclosed 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 concise (two sentences), front-loads the main purpose, then differentiates and gives examples. Every sentence serves a clear purpose with no 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 search tool with three parameters and no output schema, the description is complete. It explains the tool's function, scope, and use cases. Minor omission: could mention pagination or result format, but not essential.

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?

Input schema description coverage is 100%, so the schema already describes all three parameters. The description does not add extra meaning beyond the schema's parameter descriptions, leading to a baseline score of 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 it searches for images by text in them (OCR), and explicitly differentiates from regular search by specifying it only matches the text_in_image field. Examples like screenshots of quotes, signs, watermarks, and memes solidify the 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?

The description provides clear context on when to use this tool (searching for images with specific embedded text) and distinguishes it from regular search. However, it does not explicitly exclude cases or list alternatives among the many sibling 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 indicate readOnlyHint=false (consistent with mutation) and openWorldHint=true (suggesting side effects). The description adds minimal behavioral context beyond the preview note—no details on rate limits, authentication, or consequences of submission. The burden falls on annotations, which partially fulfill, but the description lacks additional transparency.

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 (two sentences) and front-loaded with the main purpose. It is concise, but the second sentence is informational rather than instructive. Generally well-structured with 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?

Given the tool performs a creation action with three parameters and no output schema, the description is incomplete. It fails to explain success/failure outcomes, constraints (e.g., file formats, size limits), or how the preview status affects functionality. The link provides some context but does not substitute for a full description.

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%, meaning no parameter descriptions exist. The tool description does not elaborate on any of the three parameters (image_url, tags, caption), failing to add meaning beyond the schema structure. With low coverage, the description should compensate but does not.

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 'Submit an image to MemeStack', using a specific verb and resource. It distinguishes from sibling tools which are predominantly browse/search operations, making the tool's 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 provides some usage context by noting the preview status and a URL for access details, but does not explicitly state when to use this tool versus alternatives or any prerequisites. The usage is implied from the tool's name and sibling contrast.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the constraint that prefix must be ≥ 2 characters, which is useful beyond annotations. 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?

Three concise sentences with no wasted words. The essential information 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?

For a simple tool with 2 parameters, rich annotations, and no output schema, the description covers all necessary context: purpose, usage, and constraints.

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 50% (only 'limit' has a description; 'prefix' only has minLength). The description does not add additional meaning beyond schema. Baseline 3 applies since coverage is not high, but description does not fully compensate.

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 it suggests tag slugs matching a prefix, which is a specific verb+resource. It distinguishes itself from sibling tools like 'browse_by_tag' or 'popular_tags' by focusing on autocompletion.

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?

Explicitly tells when to use: to verify a tag exists before filtering or to discover related tags. Also mentions the prefix constraint (≥ 2 characters), providing clear usage conditions.

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