Systra Tools

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

The description specifies the primary behavior—returning full source code—but with no annotations it does not disclose error behavior for unknown names or explicitly guarantee read-only semantics. The 'get' verb implies a read operation, but this is not made explicit.

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

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

The description is a single, clear sentence with no redundant wording. It directly conveys what the tool does and how the input is used.

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 single-parameter retrieval tool, the description provides sufficient context about the expected input and output. It does not describe failure cases or output formatting, but these are less critical given the simple schema and the availability of sibling listing/search tools.

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 description adds no parameter-specific detail, but the input schema fully describes the name parameter with an example. Since schema coverage is high, the 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?

The description states that the tool returns the complete, copy-ready React/TSX source code for a component given its name. This clearly identifies the verb, resource, and input, and distinguishes it from listing, searching, and styled-component siblings.

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

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

The description implies use when the agent already knows the component name and needs its source code. It does not explicitly contrast this with get_component_styled or explain when to prefer search_components first.

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?

No annotations are provided, but the description transparently explains that the tool 'returns' data, indicating a read-only operation. It does not mention side effects or prerequisites, but for a simple getter 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?

The description is concise, consisting of two sentences that convey the purpose and benefit without unnecessary detail 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?

The description fully explains the output (component, design tokens, guide) and the practical outcome, but does not specify error handling or output schema details, which are not strictly necessary.

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

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

Both parameters are covered in the schema with clear descriptions and examples ('Komponentenname, z. B. ...' and 'Style-Slug aus list_styles'), exceeding the baseline for 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 that the tool returns a component along with design tokens and a customization guide, distinguishing it from siblings like get_component and get_style.

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 it (when you need a component styled with brand tokens) and its added value over separate component/style retrieval, though it does not explicitly contrast with 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?

With no annotations provided, the description carries the full burden. It discloses what is returned (HTML, script, rules) and the intended use, but it does not explicitly state that the operation is read-only or that no side effects occur. For a get operation this is implied, but not stated.

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, and front-loads the primary purpose before detailing contents. It is efficient with no wasted words, though it could be slightly more structured with bullet points, but overall it is appropriately sized.

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

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

Given the low complexity (2 params, no output schema), the description adequately describes what is returned and what can be done with it. It does not cover error cases or the 'lang' parameter, but those are handled by the schema. The description is complete enough for an agent to call it correctly.

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

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

The schema description coverage is 100%, so both 'slug' and 'lang' are documented in the schema itself. The tool description adds no extra parameter semantics beyond what the schema already provides, so the baseline of 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 the verb (returns), the resource (post template), and the specific content (HTML file, export script, and rules). It distinguishes from siblings like get_component and get_recipe by focusing on posts, so an agent can tell it apart without ambiguity.

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

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

The description implies the tool is for fetching a post template for modification and rendering, but it does not explicitly mention when to use it versus alternatives or when not to. It relies on the tool name and resource type for differentiation, which is adequate 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 focuses on the return value but does not mention error handling, side effects, or the read-only nature of the operation. Since no annotations are provided, the description carries the burden, and these aspects are left implicit, though the 'get' wording suggests a safe read.

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, consisting of two sentences, and directly conveys the core functionality without extraneous detail. It is well-structured and easy to parse.

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 description covers the main output content (section sequence, purpose, source code, optional style) but does not provide a formal output schema or details on possible formats. For a recipe tool, this is reasonably complete, though more specifics could enhance clarity.

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

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

Both parameters are described with references to source lists (list_recipes and list_styles), which clarifies what values are expected. The descriptions are brief but sufficient for the user to understand the parameter roles.

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 that the tool returns a page recipe including the section sequence with purpose per section and the complete source code of all sections, as well as the optional brand style. This is specific and distinguishes it from other getter 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 that the 'name' parameter should be a recipe slug from list_recipes and 'style' from list_styles, giving useful context on valid inputs. It does not explicitly contrast with sibling tools like get_component, but the recipe-specific wording makes the primary use case 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?

No annotations are provided, so the description carries the full burden. It clearly discloses what the tool returns (colors, typography, CSS variables, DESIGN.md) and implies a read-only operation. While it doesn't mention error behavior or edge cases, for a simple getter this is acceptable and adds concrete value by enumerating output contents.

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 sentence, front-loaded with the action, and contains no filler. It efficiently conveys the core purpose without redundancy.

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

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

For a simple getter with one parameter and no output schema, the description sufficiently conveys the return contents and how to obtain the parameter. It doesn't specify the exact output format or error handling, but these are minor for a straightforward fetch and the description is complete enough for an agent to invoke it correctly.

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

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

Schema description coverage is 100% (slug has a description). The description itself doesn't add parameter detail, but the schema's description 'Style-Slug aus list_styles' provides a valuable cross-reference to the source of the slug, which goes beyond a bare type definition. This warrants above-baseline scoring.

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 returns all design tokens of an extracted brand style, enumerating specific components (colors, typography, CSS variables, DESIGN.md). It distinguishes from siblings like get_component and get_post by focusing on style tokens, avoiding any tautology.

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 does not explicitly say when to use this versus alternatives, but the parameter description 'Style-Slug aus list_styles' clearly indicates the workflow: first list styles to obtain a slug, then call this tool. This is effective implicit guidance, though it lacks explicit exclusions for when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only operation via 'listet' but does not explicitly mention absence of side effects, required permissions, or potential performance considerations for large category sets.

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

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

A single, concise sentence conveys the essential purpose and output. No extraneous information 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 parameterless list-all operation, the description adequately informs the agent of what will be returned (categories with counts). No additional context is needed given the simplicity of the operation.

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 no parameters, so there is nothing to clarify. The description adds no parameter-related details, but this is appropriate given the empty 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 action (list), the resource (all categories of Systra tools), and includes a relevant detail (the number of contained components). It is easily distinguished from sibling tools that operate on components, posts, recipes, and styles.

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 does not explicitly state when to use this tool versus alternatives. Although no sibling tool targets categories, there is no guidance on when a list-all operation is preferred over a search or get operation for categories, leaving some ambiguity.

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?

No annotations are provided, so the description carries the burden. It implies a read-only operation ('lists') but does not mention the return format, pagination, or error behavior. This is adequate for a basic list, but could be more explicit about side effects or constraints.

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, using two short sentences with no redundant information. It is well-structured and immediately understandable.

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 simplicity of the tool and that no output schema is provided, the description is complete enough for an agent to know what it does and how to invoke it. It could benefit from a brief note on return structure, but that is not critical for a straightforward list operation.

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

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

The schema has one parameter with a full description and examples of valid categories ('heros', 'forms', 'cta'). This adds meaning beyond the raw schema, making the parameter's purpose and values 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 tool 'lists components of the library' with an optional filter by category slug. This is a specific verb (list) and resource (components), and it is easily distinguished from sibling tools that list other entities like categories or 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 indicates that the tool can optionally filter by category slug, providing concrete usage guidance. It does not explicitly mention when to use this over search_components, but the simple list purpose is clear enough for typical use cases.

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?

No annotations are provided, so the description must carry the behavioral burden. It implies a read-only operation (listing) and notes that URLs are permanent, but it does not mention potential side effects, pagination, or error behavior. It is adequate but not highly 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?

The description is a single, concise sentence that conveys the core functionality and optional filters without redundancy. It is well-structured and easy to parse.

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 description adequately covers the purpose, the nature of the output (permanent URLs), and the available filters. For a simple list operation, it is reasonably complete, though it omits details like sorting order or pagination. The lack of an output schema is partially mitigated by the mention of URLs.

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 already provides descriptions for both parameters (album and format), achieving 100% schema description coverage. The tool description adds no extra semantic detail beyond what is already in the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('listet'), the resource ('Bilder der Medienbibliothek von Systra Tools'), and the key value proposition ('mit fertigen, dauerhaft gültigen URLs zum direkten Einsetzen'). This distinguishes it from other listing tools that handle different entities.

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 mentions optional filtering by album and format, giving some usage guidance. However, it does not explicitly contrast with the sibling 'search_images' tool or explain when to prefer listing over searching. No alternative tool is referenced.

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?

Although no annotations are provided, the description implies a read-only listing operation and explains that each template is an HTML file that can be modified/exported. This gives useful behavioral context beyond the schema.

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, providing essential information without redundancy. It is well-structured and front-loaded with the main purpose.

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

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

For a simple listing tool, the description fully covers what is listed, the template format, and the intended usage, making it complete for an agent to understand when and how to use it.

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 single 'family' parameter has a schema description and the tool description adds clarifying context about what 'klar' and 'editorial' families mean, enriching the parameter's meaning.

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 lists Instagram post templates and specifies the size (1080x1350) and format (HTML files). This distinguishes it from sibling list tools for other entities.

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

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

It describes what the list contains and the nature of the templates, which helps an agent decide to use it for retrieving templates. It does not explicitly compare to alternatives, but the sibling tools are clearly for different entity types.

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 full responsibility for behavioral disclosure. It does not state whether the operation is read-only, whether it modifies data, or any side effects, rate limits, or auth requirements. While 'list' implies a read operation, this is not explicitly disclosed.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the core purpose and examples efficiently.

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

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

For a simple list tool with no parameters and no output schema, the description adequately conveys what is returned (recipes) and gives illustrative examples. It does not specify the exact output format (e.g., names vs. full details), but that is a minor gap for a list 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?

There are zero parameters, so the schema fully covers the input surface (100% coverage). The description adds value by explaining what a 'recipe' is (sequences of sections for landing pages), which provides context beyond the empty schema. Baseline 4 for no params 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 (Listet) and resource (kuratierte Seiten-Rezepte) and clarifies what recipes are with concrete examples (SaaS, Coaching, Hotel). This clearly distinguishes it from siblings like get_recipe, which would retrieve a single recipe.

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

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

No explicit guidance is given on when to use this tool versus alternatives. It does not mention that get_recipe should be used for a specific recipe, nor does it state any conditions or exclusions. The usage context is only implied by the verb 'list'.

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?

No annotations are provided, so the description alone carries the burden. It mentions the source (Style Extractor) and applicability, but does not disclose side effects, permissions, pagination, or return format. For a simple list operation, this is sufficient but lacks explicit behavioral details.

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

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

The description is a single, concise sentence with no redundancy. It efficiently conveys the purpose and context without extra 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?

For a parameterless list tool, the description provides sufficient context: it explains what is listed (brand styles from Style Extractor), the content (colors and fonts), and the use case (applying to components). No additional information is needed to invoke 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?

The tool has no parameters, and the schema coverage is effectively 100%. The description adds no parameter-related information because there are none to describe; the baseline of 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 the verb 'Listet' (lists) and the object 'Marken-Stile' (brand styles), specifying that they come from the Style Extractor and include colors and fonts. This unambiguously distinguishes it from sibling tools like get_style, which retrieves a single style.

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 a list of styles is needed but does not explicitly state when to use this tool over alternatives such as get_style or other list_* tools. It lacks explicit conditions or comparisons, so guidance is only implicit.

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?

There are no annotations describing side effects, auth requirements, or rate limits. The description implies a read-only search action by saying 'Sucht' and 'gibt Treffer zurück', but it does not explicitly state the absence of side effects or explain result limits and ordering.

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

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

The description is a single, clear sentence with no superfluous words. It communicates the action, target, search criterion, and expected result efficiently.

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 no output schema provided, the description still mentions that the tool returns 'Treffer' (matches), giving a basic expectation. It could be more detailed about result structure or limits, but it is sufficient for a search tool with one parameter.

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 describes the single parameter as 'Suchbegriff', and the tool description adds the important nuance that the keyword applies to name or category. This goes beyond the minimal schema description and clarifies how to use the parameter.

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 components by keyword and returns matches. It uses a specific verb ('Sucht') and resource ('Komponenten'), and distinguishes itself from listing or getting components by emphasizing keyword-based search.

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 when to use the tool: when searching components by a keyword in name or category. It does not explicitly contrast with siblings like list_components or get_component, but the keyword-search criterion is clear enough to guide 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?

The description states that the tool returns ready-made URLs, which is a behavioral detail. Since no annotations are provided, the description carries the burden; it implies a read-only search operation without explicitly stating side effects, which is acceptable for this context.

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

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

The description is a single, concise sentence that communicates the core functionality without unnecessary detail. It is well-structured and easy to parse.

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 one parameter, the description is complete. It defines the search targets and output behavior (URLs), so an agent has enough context to use it correctly without additional 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?

The only parameter 'query' is fully described in the schema with examples ('gradient', 'laptop', 'wald') and the description clarifies it is used for searching in title, filename, or album. This adds meaning beyond the schema's basic type definition.

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 that the tool searches the media library for images by a keyword in title, filename, or album, and returns ready-made URLs. This is a specific verb-resource pair that distinguishes it from list_images and other list 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?

It explicitly describes the search scope (title, filename, album), which tells the agent when to use this tool. It does not mention alternatives or when not to use it, but the guidance is clear enough for typical search scenarios.

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