blueprint-modular

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

Annotations already mark the tool as readOnlyHint=true; description adds behavioral context by detailing the return content (props, types, example usage, semantic layer) and parameter flexibility (accepted name formats). No contradictions. Lacks mention of any side effects, but none are expected for a read operation.

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

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

The description is concise and well-structured: it starts with the core purpose and return content, then adds usage instructions, and finally clarifies parameter acceptance. Every sentence adds value, no 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 no output schema, the description thoroughly explains what the return includes (description, props/types, example usage, associated/parent components, semantic layer details). It also provides usage context and parameter details, making it complete for a single-parameter detail 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?

Schema coverage is 100% with a clear description of the 'name' parameter. The description repeats the acceptable formats ('bpm.metric' or 'metric'), adding no new meaning beyond the schema. Baseline score of 3 is appropriate as description does not enhance parameter understanding.

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 the full detail of a component, listing specific fields (description, props/types, example usage, etc.). It distinguishes itself from siblings by specifying it is to be used after list/search, making it clear that this tool provides the deep detail needed for code generation.

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 instructs to use after list/search to obtain exact signature and meaning before generating code. This provides clear when-to-use guidance and implies it is not for initial discovery. The context signals sibling tools, and the description positions this tool as the follow-up for detail retrieval.

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, so the description adds value by explaining pagination (cursor) and category filtering, which are beyond the annotation scope.

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 a list of categories - highly efficient, front-loaded with purpose and usage, 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?

For a simple list tool with 2 optional params and no output schema, the description fully covers purpose, usage, pagination, and category filter, leaving no 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%, but the description enriches parameters by listing exact categories ('Catégories : ...') and explaining cursor pagination ('réutiliser nextCursor'), going beyond schema descriptions.

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 'Liste les composants' with specifics (name + one-line description), and implicitly distinguishes from siblings like get_component (single) and search_components (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?

It says 'À UTILISER pour parcourir le catalogue ou découvrir ce qui existe dans une catégorie donnée', providing clear usage context. It doesn't explicitly state when not to use, but the context implies 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 provide readOnlyHint, and description adds pagination by cursor. No contradictions. Reveals search behavior 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, front-loaded with purpose and usage, then pagination detail. 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?

For a search tool with 2 params and no output schema, description covers fields, sorting, and pagination. Lacks explicit return format but sufficient given complexity.

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%, but description adds meaning by specifying search fields (name, description, category, tags) and sorting by relevance, aiding proper use.

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 components by free text, matching on name, description, category, and tags, sorted by relevance. It distinguishes from siblings like 'get_component' (single) and 'list_components' (listing) by focusing on keyword 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?

Explicitly states when to use ('when searching for a component by function or keyword') with examples. Does not mention when not to use, but the sibling context implies limits.

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 provide readOnlyHint and openWorldHint. The description adds value by explaining the semantic reasoning process and output details (meaning, pairWith). It also notes 'Réponse bornée' (bounded response), which is additional behavioral 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 concise with two sentences. It is front-loaded with the core purpose and provides essential usage guidance without extraneous 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?

Given full schema coverage, no output schema, and annotations, the description adequately covers the tool's purpose, usage scenario, and output characteristics. It mentions the semantic reasoning and output structure (meaning, pairWith), which sets clear expectations.

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 parameter descriptions. The description adds a usage hint for the need parameter (screen intention example) but does not add substantial new semantics 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 it suggests a list of Blueprint Modular components based on a natural language need, using semantic reasoning. It distinguishes from siblings (get_component, list_components, search_components) by focusing on semantic suggestion rather than exact lookup or listing.

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 a clear usage scenario: 'À UTILISER pour partir d'une intention d'écran...' and includes an example. It does not explicitly state when not to use it or list alternatives, but given sibling tools and the context, it is easy to infer.

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