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?

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds substantial behavioral context beyond that: default date handling, range semantics, the fact that tides only exist for coastal ports, and that freshwater requests return only moon phase and bestWindows. This is exactly the kind of runtime behavior an agent needs to know.

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 and front-loaded: it states the tool's output first, then usage triggers, then parameter defaults, then the important freshwater caveat. Every sentence carries useful information with no filler or repetition.

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

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

For a read-only tool with 7 optional parameters and no output schema, the description covers the main invocation scenarios, date/range semantics, and the freshwater exception. The main gap is the absence of the exact return structure, though the description does enumerate key returned data fields (tide table, moon phase, windows, water temperature, weather).

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

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

Schema coverage is 100%, so the schema already documents all 7 parameters. The description adds extra meaning by explaining date/range behavior and the freshwater fallback ('para água doce a ferramenta devolve a fase da lua e as janelas de horário do dia (bestWindows)'), which goes beyond the schema's parameter-level details.

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

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

The description starts with a concrete resource and payload: 'Condições de pesca de um dia: tábua de marés, fase da lua, melhores janelas de horário, temperatura da água e tempo.' It also ties the tool to specific user intents (maré, lua, melhor horário para pescar, se o dia está bom), making it easy to distinguish from sibling tools that cover species, locations, equipment, and techniques.

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 sobre maré, lua, melhor horário para pescar, ou se o dia está bom') and explains date/range usage ('Hoje por padrão; passe date para amanhã... e range para a semana ou o mês inteiro'). It does not name an alternative tool or give an explicit 'when not to use', but it does describe the coastal vs freshwater boundary clearly.

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 mark readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds that it returns seasonalCalendar and regions, which is useful context beyond the annotations, but doesn't detail any other behavioral quirks (e.g., whether it returns null if the slug is unknown). 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 short and front-loaded: it opens with an explicit noun-phrase definition of what the tool returns, then lists the content categories, then gives precise usage guidance. Every sentence earns its place and there is no repetition of schema 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 with no output schema, the description covers what the tool does, when to use it, and what data it returns (habitat, diet, techniques, baits, seasonal calendar, regions). It's slightly lacking an explicit statement of what happens if the slug doesn't match, but that's minor; the tool is otherwise fully usable from the description alone.

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 parameter 'slug' is already fully documented in the schema. The description reinforces that the slug comes from search_species and gives an example ('tucunare'), which adds a small practical hint beyond the schema, but the schema covers the essential meaning. 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 a specific verb ('Detalhes de uma espécie') and enumerates the exact content covered: habitat, dieta, técnicas, iscas, seasonalCalendar, and fishing regions. It distinguishes itself from sibling tools by focusing on species-level biological/fishing context rather than equipment, locations, or techniques.

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: before recommending equipment or location for a specific fish, and for questions about best season / when to fish X. This gives an agent clear routing criteria and implies when not to use it, since equipment/location-specific tools exist as 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?

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 declare readOnlyHint, idempotentHint, and destructiveHint, so the tool is known to be safe. The description adds the key behavioral detail 'Retorna preços ao vivo' (returns live prices), which is valuable context. It does not mention default sorting, pagination, or empty-result behavior, but given the annotations cover safety, 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 a compact two-sentence structure. The first sentence states the purpose and scope; the second states when to use it and what it returns. No wasted words, and the most important information is front-loaded.

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

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

For a search tool with 8 optional parameters and no output schema, the description covers the core aspects: what it searches, when to use it, and that it returns live prices. It does not detail the return format (list vs single item) or default sorting, but those are partly inferable from the tool's nature and the parameter descriptions. Given the annotations and schema richness, it is fairly 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?

Schema description coverage is 100%, so all 8 parameters already have detailed explanations in the schema. The tool description does not add new parameter semantics beyond what the schema provides; it only hints at price-related use cases. According to the rubric, baseline is 3 when schema coverage is high, and the description does not elevate it.

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

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

The description states a clear verb+resource ('Busca equipamentos de pesca no catálogo da iscabox') and enumerates the types of items covered (varas, carretilhas, molinetes, linhas, iscas, anzóis, acessórios). It also distinguishes itself from sibling search tools that target other entities (species, locations, techniques) by explicitly limiting scope to equipment. The mention of product recommendation, comparison, and price range further clarifies the intended use.

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 states when to use the tool: 'Use sempre que o usuário pedir recomendação de produto, comparação ou faixa de preço.' This is a clear trigger condition. However, it does not mention when not to use it or provide alternatives (e.g., get_lures_for_species for species-specific lure advice), so it stops short of a full routing guide.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, and the prose adds genuinely useful semantics: cities without their own page still return nearby locations when lat/lng are passed, and kind changes which sub-collection is searched. There is no contradiction with 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?

Five short sentences with no filler: purpose, filters, trigger, proximity rule, and kind rule. The most important decision rule appears early, and every 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 read-only search with 11 optional parameters and no output schema, the prose plus detailed parameter descriptions cover the main decisions. It is not a 5 only because it never explicitly routes to nearby siblings like get_location or get_river.

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

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

Schema coverage is 100%, so the schema already documents all 11 parameters; the baseline is 3. The description adds cross-parameter meaning by tying lat/lng to the city-proximity fallback and tying kind to the pesque-pague vs. natural-water split, which the individual enums do not fully convey.

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 action and resource: 'Busca locais de pesca no acervo da iscabox', and it enumerates the kinds of places (rios, represas, praias, pesqueiros). This makes it immediately clear this is a place-search tool and distinguishes it from the sibling species, equipment, and technique searches.

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 quando o usuário perguntar onde pescar') and concrete conditional rules: supply lat/lng when a city is mentioned, and use kind to separate pesque-pague from open water. It stops short of naming alternatives or stating when not to use it, so it does not earn 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, 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.