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

With no annotations, the description takes on the burden. It discloses the return payload (URL, download URL, license, metadata) but doesn't mention error handling, rate limits, or authentication requirements, which is a moderate gap.

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 action and scoped by 'specific asset by its ID'. No filler, each sentence 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 get-by-ID with no output schema, the description adequately covers the return values and ID format. It may lack error conditions, but given the low complexity, it is nearly 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?

The schema already provides a full description of the 'id' parameter with examples. The description's examples overlap with the schema, adding little new semantic meaning, so the baseline 3 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?

The description clearly states a specific verb 'Get' and resource 'asset by its ID', distinguishing it from sibling search tools. It also provides concrete ID format examples.

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 'by its ID' implies use when an ID is already known, contrasting with the search-oriented siblings. It doesn't explicitly mention alternatives like search_icons, but the context is evident.

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?

With no annotations, the description carries the burden of disclosure. It states the tool lists configured providers and their readiness to search, which conveys read-only, non-destructive behavior. It doesn't elaborate on return format or edge cases, but for a simple listing tool this is adequate.

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

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

Two concise sentences, front-loaded with the key action and resource. Every sentence adds value: the first states the function, the second explains the purpose and timing. No redundant or vague wording.

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 tool with no output schema, the description is quite complete: it states what is returned (providers and status) and when to use it. It could mention the exact output structure, but the simplicity of the tool makes the description 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?

The tool has zero parameters, and the schema already documents this (100% coverage). Baseline for no parameters is 4, and the description doesn't need to add parameter semantics since there are none.

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') with a clear resource ('all available asset providers') and adds scope ('their status'). It clearly distinguishes from sibling search tools by focusing on enumerating providers rather than searching for assets.

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 advises to use this tool 'before searching,' providing clear context for when it applies. It doesn't mention when not to use or alternatives, but the phrasing effectively differentiates it from the search-focused 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?

With no annotations, the description carries the full transparency burden. It discloses that the tool returns SVG emoji files and notes the CC BY-SA 4.0 license, which is useful behavioral context. However, it does not mention potential caveats like rate limits, pagination, or behavior on empty results, so it's not exhaustive.

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 three concise sentences, each adding value: the purpose, the output format, and licensing. It is front-loaded with the key action and resource, with 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?

For a simple search tool with two parameters and no output schema, the description is fairly complete. It states what is searched, what is returned, and the license. It does not detail the exact response structure, but that is less critical given the absence of an output schema and the simplicity of the tool.

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 covers 100% of parameter descriptions, so the baseline is 3. The description adds minimal param-specific meaning beyond the schema; it does not elaborate on 'query' or 'limit' syntax or behavior. The schema's own descriptions are sufficient, so the description adds little extra.

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 for open-source emoji from OpenMoji') and specifies the resource type (emoji from OpenMoji). It explicitly differentiates from sibling tools like search_icons and search_logos by naming the provider and asset type, and mentions the output format (SVG files).

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 searching for open-source emoji from OpenMoji. However, it does not explicitly mention alternatives or exclusions (e.g., 'use search_icons for icons'). The context is clear but lacks explicit alternative 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?

With no annotations, the description must carry the behavioral burden. It does disclose key behavior: returns SVG icons with license info, and implies a read-only search. However, it lacks details on search behavior (matching, ordering), result size limits, or potential error handling, making it only partially transparent.

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, each adding value: what it searches, what it returns, and when to use it. Front-loaded with the verb 'Search.' 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 straightforward search tool with a well-documented schema and no output schema, the description is complete enough for an agent to select and invoke it. It covers the resource, return type, and use cases. It doesn't mention potential alternatives but that's more relevant to usage guidelines, which already scored a 4.

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 parameter meanings are already fully documented in the input schema. The description adds no additional parameter semantics, and per the rubric, baseline is 3 when schema covers parameters well. No bonus or penalty beyond 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 the tool searches for icons from a large collection (200,000+ icons, 150+ sets) and returns SVG icons with license info. It mentions use cases ('UI icons, app icons, symbols') which helps distinguish from sibling tools like search_logos or search_emoji, but it does not explicitly differentiate from search_vectors, which could overlap.

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 the tool: 'Perfect for finding UI icons, app icons, and symbols.' It implies usage for icon-specific needs but does not explicitly state when not to use it or name alternative tools, so it stops short of full 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?

With no annotations provided, the description carries the full burden. It discloses that the tool returns high-quality PNG logos, has a large brand coverage, and requires a specific env var for full functionality. This provides useful behavioral context beyond a simple 'search' statement.

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 and front-loads the main purpose. Every sentence adds value: the first states the function and key attribute (logos), the second adds scale and a prerequisite. No wasteful 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's low complexity, the schema covers parameters, and there is no output schema, the description is fairly complete. It explains the return format (PNG), coverage, and token requirement. It could mention how results are returned (e.g., URLs or binary data), but that is a minor gap.

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%, as both query and limit have descriptive text. The description adds no additional parameter semantics beyond what the schema already provides, 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 ('Search') and a specific resource ('brand and company logos'), clearly distinguishing it from sibling tools like search_icons, search_vectors, and search_stock_photos. It also adds context about output format (PNG) and scale (50,000+ brands).

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: use this when needing brand/company logos. It also mentions a prerequisite (LOGO_DEV_TOKEN) for full functionality, which helps set expectations. However, it does not explicitly state when not to use it or name alternatives, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full transparency burden. It adds useful context about free commercial use and provider enablement via env vars, but it does not disclose behavior like what happens if no API keys are set, how results are aggregated across providers, or any rate limits. This is adequate but not comprehensive.

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: the first states the core purpose, the second adds licensing and setup notes. Every sentence earns its place with no wasted words, and key 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?

The tool has 4 parameters and no output schema, so the description should explain return values or error behavior. It does not mention what the search returns (e.g., photo URLs, metadata) or how missing API keys are handled. Given the multi-provider complexity, this is a notable gap, though the core purpose and provider setup are covered.

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 covers 100% of parameter descriptions (query, color, limit, license), so the description itself does not need to add parameter details. It adds no extra semantic value beyond the schema, and the baseline of 3 is appropriate given full 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 tool's function: 'Search for free stock photos from Pexels, Unsplash, and Pixabay.' It uses a specific verb ('search') and specifies the resource type (stock photos) along with named providers, distinguishing it from sibling tools like search_icons or search_vectors.

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 searching for stock photos) through its clear purpose, and it provides setup context by mentioning required environment variables for each provider. However, it does not explicitly state exclusions or alternative tools, so it falls short of a full 5.

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?

With no annotations, the description carries the transparency burden. It discloses that the tool returns downloadable SVG files with license information, but it omits details like output format, pagination behavior, or error handling. This is moderate disclosure.

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 that states the primary action and result. It contains no filler, redundancy, or unnecessary detail.

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 3-parameter search tool with no output schema, the description covers purpose, source, and return type (downloadable SVG files with license info). It lacks detailed output structure, but is sufficiently complete for basic 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?

The input schema provides 100% parameter coverage with descriptions, so the baseline is 3. The tool description adds no extra parameter semantics beyond the schema, only mentioning license information in the return 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 action 'Search' and resource 'SVG vectors and illustrations from SVG Repo', with scale and licensing context. It distinguishes from siblings like search_icons and search_logos by specifying a different asset category and source.

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 clear context for when to use this tool (when searching for SVG vectors/illustrations from SVG Repo), but it does not explicitly mention exclusions or alternative sibling tools. This aligns with 'clear context, no exclusions'.

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?

With no annotations, the description must convey behavior. It discloses that the tool automatically selects provider(s) and searches all sources, giving insight into its decision-making. It doesn't detail ranking or limitations, but covers the essential behavior for a suggestion 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 that lead with the core action and immediately explain the tool's advantage. Every word adds value, and the structure is clear and scannable.

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 4 parameters and no output schema, the description adequately explains the input style and behavior. It could mention what the response looks like, but 'get the best matching assets' signals the output. Sibling context and schema fill most remaining 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?

Schema coverage is 100% with detailed descriptions for all parameters. The tool description adds context about the 'description' parameter (natural language) but doesn't significantly enhance understanding beyond the schema. 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 tool's function: suggesting assets across all sources based on natural language input. It distinguishes itself from sibling search tools by explicitly targeting cases where the user doesn't know the exact asset type.

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 explicit guidance: 'Use this when you're not sure which specific asset type to search for.' This tells the agent exactly when to select this tool over the specialized search_* siblings.

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