iscabox

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description doesn't need to restate mutation semantics. It adds meaningful behavioral context beyond annotations: the rig always includes natural bait as a fixed item for pesqueiro trips, and it respects the budget in budgetBRL. It does not fully describe the output format or whether it performs web searches, but the openWorldHint=true and the 'Respeita o orçamento' line give useful practical constraints. A 4 is appropriate because it adds valuable behavioral details without contradicting 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?

The description is two sentences, front-loaded with the core purpose and followed by usage contexts and exclusions. Every sentence earns its place: the first defines the output scope, the second covers when to use it, the natural-bait special case, the budget constraint, and the sibling alternative. Slightly dense, but no wasted words; a 4 is fitting.

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?

This is a moderately complex tool with a single free-text parameter, an optional budget parameter, and no output schema. The description tells the agent what kind of prompt to expect, how the budget constraints behavior, and which sibling handles single-item questions. It doesn't specify the exact return format or what happens if the budget is impossible, but for a generative assembly tool with two parameters and no output schema, the context is largely complete. A 4 is justified.

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 both parameters (prompt, budgetBRL) are documented in the schema. The description adds meaning beyond the schema by explaining what the prompt should contain (species, water, budget, preferences) with a concrete example, and by tying budgetBRL to the tool's budget-respecting behavior. This is a solid contribution, though the schema already carried the essential meaning, so it's not a 5.

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 is specific: it states the tool assembles a complete, coherent fishing rig (rod, reel, line, leader, lures, hooks) for a fishing trip, and distinguishes itself from sibling tools by explicitly covering kit requests and 'what do I need to fish X'. It uses a clear verb (Monta) and a precise resource (tralha completa), so an agent can tell it apart from single-item tools like search_equipment.

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 explicit when-to-use guidance: when the user asks for a full assembly, a kit, or 'what do I need to fish X', including pesqueiro with natural bait. It also provides an exclusion: 'Para dúvidas sobre um produto só, use search_equipment.' This directly routes the agent to the correct sibling and prevents mis-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 establish that the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond the annotations by specifying what content is returned and that the price is 'ao vivo' (live), while also indicating a dependency on the productPath from search_equipment.

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 with no wasted words. It front-loads the output content and immediately follows with the usage context and dependency, making it easy for an agent to parse 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?

For a simple read-only lookup with one required parameter, the description is complete enough: it names the input, the output categories, and the exact usage sequence. The annotations cover the safety profile and no output schema is needed given the straightforward content list.

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%, and the schema already documents that productPath must be the exact value returned by search_equipment. The tool description reinforces this dependency but does not add meaningful new parameter-level semantics 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 what the tool returns: complete equipment details including specifications, pros and cons, and live price. It also distinguishes this tool from search_equipment by framing it as the follow-up step for a specific product.

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 to use it after search_equipment when the user wants more information about a specific product. This gives the agent a clear, actionable trigger condition for invoking this tool versus the sibling search tool.

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?

Beyond annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses a non-obvious behavioral trait: tide data exists only for coastal ports, while freshwater requests return only moon phase and the day's time windows (bestWindows). It also names the bestWindows field, giving the agent expectations about response contents in the absence of an output 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?

Three sentences, each earning its place: what it returns, when to use it, and the freshwater caveat. The purpose is front-loaded in the first sentence and nothing is wasted.

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 4-optional-parameter tool with no output schema, the description covers return contents, call triggers, and the key behavioral caveat, while the fully-covered schema handles input semantics. A minor gap is location resolution priority — which parameter wins when lat/lng, query, and portSlug are all supplied — and behavior for ports not in the enum.

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%, and each parameter is already documented with examples (lat/lng in decimal degrees, query as 'São Francisco do Sul', portSlug with a reliability note steering agents toward slugs). The description adds only marginal param-level value via the coastal/freshwater caveat, 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 opens with a specific verb+resource: 'Condições de pesca de hoje' followed by an explicit output list (tábua de marés, fase da lua, melhores janelas de horário, temperatura da água e tempo). This precisely states what the tool returns and clearly differentiates it from all siblings, which are in the equipment/species/technique/location domains.

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 second sentence gives explicit trigger conditions: use when the user asks about tide, moon, best time to fish today, or whether the day is good. It names no when-not-to-use alternatives, but none of the sibling tools compete in the conditions domain, so the clear context is sufficient.

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 destructiveHint, covering the safety profile. The description adds value beyond those by specifying the guide's content categories (how to get there, best points, species, baits, techniques), giving the agent a concrete picture of the returned information. 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?

A single, information-dense sentence that front-loads the primary purpose ('Detalhes de um local de pesca') and then enumerates the deliverable content. No filler 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 one-parameter read-only tool with rich annotations, the description sufficiently explains what the guide contains. Since there is no output schema, the listed content areas provide the necessary expectations, though it could have mentioned the overall return structure.

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 locationPath property already explained as the exact path from search_locations. The description adds no additional parameter semantics, so the baseline score 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 tool returns details for a fishing spot, listing specific content areas (access, best spots, species, baits, techniques). This distinguishes it from sibling tools like search_locations, get_species, and get_technique by its focus on a single location's guide.

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 parameter description adds usage guidance by stating locationPath must be the exact value returned by search_locations, implying search_locations should be called first. It does not explicitly discuss alternatives or exclusions, but the context is clear enough for an agent to know when to use this getter.

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, idempotent, and non-destructive behavior. The description adds meaningful context: the data source, the fallback from curated lists to species guide recommendations, acceptance of family names, and that live prices are returned. This goes beyond the annotations without contradicting them.

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 compact but information-dense, front-loaded with what the tool does and followed by clear usage guidance. Every sentence contributes: purpose, source/fallback behavior, when to use over the sibling, family-name handling, and output 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 one-parameter lookup tool with annotations covering safety and idempotency, the description is complete. It explains what is returned, where the data comes from, how to route the query, and what edge cases are handled, leaving no significant gap for the agent.

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 the schema already describes the species parameter with examples. The description adds extra semantic value by explaining that family names are accepted and that 'robalo' covers 'peva' and 'flecha', which is not present in 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 states that the tool returns the right lures for a specific fish, with the reason for each lure, and explicitly contrasts it with search_equipment. This gives a clear verb, resource, and enough detail to distinguish it from 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?

It explicitly instructs to use this tool whenever the question is 'what lure for <fish>' and says to use it instead of search_equipment, with a reason why. It also covers family-name handling, so an agent knows when a broader query is acceptable.

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 establish that the call is read-only and idempotent. The description adds useful behavioral detail beyond that: results are ordered from nascente to foz, include per-municipality km stretches, and include fishing locations from the collection.

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 compact sentences: the first front-loads what the tool returns, the second states exactly when to invoke it. No filler or repetition of the schema.

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 single-parameter, read-only lookup with no output schema, the description covers the essential return content and the triggering user intents. An agent has enough context to select and call 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 only parameter, name, is fully described in the schema with an example ('rio taquari'). The description adds no additional parameter semantics, 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 identifies the resource (a mapped river) and the specific output: municipalities in source-to-mouth order, km segments, and fishing spots. It does not explicitly contrast with sibling tools like get_location or search_locations, but the river-route focus is distinctive enough to set it apart.

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 explicit trigger conditions: 'Use quando o usuário perguntar por onde um rio passa, que cidades ficam nele, ou onde pescar ao longo de um rio.' It does not mention when not to use it or name an alternative tool, so it falls just 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so this is clearly a safe read operation. The description adds behavioral context by listing exactly what kind of guidance the tool provides and clarifying its role as a pre-recommendation lookup. 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?

Two short, information-dense sentences. The first lists the content domains returned, and the second gives clear usage timing. Every sentence contributes value with no repetition of schema or annotation details.

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 single-parameter read-only lookup tool, the description is complete: it states what data is returned, where the input comes from, and when the tool should be used. The absence of an output schema is compensated by the explicit list of returned content areas.

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 fully documents the single required parameter 'slug' with a description explaining it comes from search_species and giving an example. The tool description adds no new meaning beyond referring to 'a specific fish,' so the baseline of 3 is appropriate since the schema already carries the semantic load.

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 detailed species information: habitat, diet, effective techniques, baits, and fishing regions. It identifies the resource (a species guide) and differentiates it from search_species by positioning it as the detailed follow-up lookup.

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 to use this tool before recommending equipment or locations for a specific fish. It also references that the slug comes from search_species, establishing a dependency. It does not explicitly contrast with sibling tools like get_lures_for_species or get_technique, but the primary 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the result includes step-by-step guidance, equipment, and when-to-use context, but does not disclose any further behavioral traits. 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 compact sentence that front-loads the tool's purpose and concisely lists the key content areas: step-by-step, equipment, and when to use. There is no wasted text.

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 lookup with one required parameter, strong annotations, and no output schema, the description adequately conveys what the tool returns and where the slug comes from. Nothing critical is missing.

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 the slug parameter is well-described as the value returned by search_techniques. The description adds no additional parameter meaning beyond what the schema already provides, so the 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 identifies the resource (uma técnica) and the intent (detalhes), distinguishing it from search_techniques which would list techniques. It does not use a strong action verb or explicitly name a sibling, but the meaning is 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 schema's slug description references search_techniques, implying this tool is meant to be called after a search returns a slug. However, the description itself provides no explicit when-to-use guidance or exclusions, and it does not contrast with related tools like get_equipment_details.

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 readOnly/idempotent/destructive behavior. The description adds useful beyond-annotation context by scoping the data source to the iscabox catalog and stating 'Retorna preços ao vivo,' which is a meaningful behavioral promise for a price-sensitive search tool. 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?

Three short sentences with no filler: purpose/scope, when-to-use, and return behavior. The category parenthetical is helpful rather than redundant because it enumerates the catalog's scope.

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 7-parameter search tool with no output schema, the description covers selection triggers, catalog scope, and live-price return behavior. It is slightly incomplete about the result shape, but the schema documents all parameters and the use cases are fully 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?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the price-range concept and gives example product categories, but it does not add per-parameter meaning 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 uses a specific verb and resource: 'Busca equipamentos de pesca no catálogo da iscabox' and lists concrete product types. It is clearly distinct from sibling location/species/technique searches, though it does not explicitly differentiate itself from overlapping product tools like get_lures_for_species or route to get_equipment_details.

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 gives an explicit trigger: 'Use sempre que o usuário pedir recomendação de produto, comparação ou faixa de preço.' This tells an agent when to select the tool, but it gives no exclusions or alternative tool routing for adjacent cases such as species-specific lure 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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable non-obvious behavior: passing lat/lng for a city returns nearby places even when the city itself has no page. It also instructs using kind to separate pesque-pague from natural water, going beyond what annotations provide.

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?

Four sentences, each earning its place: the purpose, the filter capabilities, the primary use trigger, and the city/kind behavior. It is front-loaded with the most important information and contains no filler.

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 an 8-optional-parameter search tool with no output schema, the description covers the main invocation scenarios: general 'where to fish' queries, city-based proximity searches, and kind separation. It does not describe the response shape or ordering, but the rich schema descriptions and annotations carry enough of that burden.

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%, and the description itself mostly restates what the schema already explains, such as filtering by state, species, or water type. The only added semantic hint is 'Use kind para separar pesque-pague de água livre', but the kind parameter description already conveys that distinction. 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 opens with 'Busca locais de pesca no acervo da iscabox', naming the specific verb, resource, and collection, then enumerates the types of results (rios, represas, praias, pesqueiros). This clearly distinguishes it from sibling search tools like search_species or search_equipment, which target different resource types.

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 'Use quando o usuário perguntar onde pescar', providing a clear trigger condition for when to invoke the tool. It also gives contextual guidance for city-based queries, but it does not mention when not to use it or name alternative tools like get_location or get_river.

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, covering the safety profile. The description adds context that the search is a confirmation step, but it does not disclose additional behavior like return format, pagination, or matching behavior. The added value is modest but not absent.

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 with no filler. The main function is stated first, followed by a clear usage directive. Every sentence earns its place and the structure is easy to scan.

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 all parameters documented, no output schema, and annotations covering safety, the description is largely complete. It states what is searched, the search criteria, and when to use it. The only notable gap is the lack of differentiation from the 'get_species' sibling, but this is not critical 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?

Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds minor semantic context by indicating the query can be a popular or scientific name, but this largely overlaps with the schema's description of 'query'. No additional meaning is provided for 'limit' or 'water'.

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 'Busca' (searches) and the resource 'espécies de peixes no acervo da iscabox', specifying it searches by popular or scientific name. However, it does not distinguish itself from the sibling tool 'get_species', so the differentiation between them is unclear.

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 to use this tool when the user mentions a fish to confirm which species before responding. This provides clear context for when to invoke it, but it does not explicitly state when not to use it or mention alternatives such as 'get_species'.

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 safety is covered. The description adds valuable behavioral context beyond the schema: passing species merges collection techniques with species-guide recommendations. It does not disclose result ordering or pagination, but for a read-only search this is a minor 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?

Three short sentences, front-loaded with the core action, followed by usage triggers and a conditional species behavior. Every sentence earns its place; the examples are compact and useful.

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 search tool with all parameters optional and fully documented, the description covers intent routing, the special species behavior, and the domain. No output schema exists, but return values are unlikely to affect correct invocation. It could briefly mention the shape of results, but nothing critical is missing.

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 baseline is 3. The description adds extra meaning for species: it explains that the parameter is not merely a filter but triggers inclusion of species-guide-recommended techniques. It also anchors query semantics to user intents like 'como pescar' and 'nó'. Other parameters (limit, category) are already fully documented in 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 opens with a specific verb and resource: 'Busca técnicas e nós de pesca no acervo da iscabox'. It clearly marks the tool as a search over fishing techniques and knots, which separates it from sibling search tools focused on equipment, locations, or species, and from get_technique, which implies single-record 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 gives explicit triggers: use when the user asks how to fish, which technique to use, or how to tie a knot. It also explains when to pass species. It does not name any sibling or state when not to use it, so it stops short of a full when-not/alternatives statement.

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