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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the return content (nome, link e peixe) but nothing about auth, rate limits, or failure modes, so it earns only modest incremental credit.

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 that front-load what is returned and then give the usage trigger. Nothing is padded, though the parenthetical URL/format is slightly redundant with the schema's own handle description.

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?

There is no output schema, and the description compensates by naming the returned fields (nome, link, peixe), which is helpful. What is missing is disambiguation from the very similar 'get_creator_tralha' sibling, which is essential context for correct tool selection here.

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 there is a single required 'handle' parameter whose format ('com ou sem @') is already documented in the schema. The 'iscabox.com/@handle' in the description merely restates the handle concept, adding no syntax or constraint beyond the schema, 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 states a specific resource (as tralhas publicadas por um criador de conteúdo de pesca na iscabox) and even enumerates the returned fields (nome, link e peixe), so the agent knows what this returns. The gap is sibling differentiation: 'get_creator_tralha' is a near-identical sibling and the description never clarifies how these two differ, leaving the agent to guess.

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 supplies a trigger condition ('Use quando o usuário perguntar pela tralha de um canal ou vídeo'), which is real usage guidance. However, it offers no when-not guidance and no routing to alternatives, which is a notable omission given the presence of the confusingly similar 'get_creator_tralha' and 'build_tralha' 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 establish readOnly, idempotent, non-destructive behavior, so the bar is lower. The description adds real output context beyond annotations: the returned `url` earns the creator commission, and `storyImageUrl` is a 1080x1920 JPEG ready to post as a story.

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 tight sentences with zero filler. It front-loads what the tool returns, then the actionable instruction (deliver the url), then a note on the image asset, each earning 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?

With no output schema, the description carries the burden of explaining returns and does so: the url, the commission mechanic, and storyImageUrl format. It is nearly complete, only lacking any note on error cases or what happens if the tralha slug is invalid.

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 both parameters (handle as the creator's @ on iscabox, tralha as the slug from get_creator_page) are already documented in the schema. The description adds no syntax or format detail beyond that, 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?

States a specific verb+resource: retrieves a creator's 'tralha' (the gear kit used in a video), and details what it contains (each item's version and today's lowest price). This distinguishes it from generic equipment searches, though it does not explicitly contrast with the sibling build_tralha.

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?

Usage is implied through chaining: the tralha param is noted as coming from get_creator_page, and the description instructs delivering the `url` to the user. However, there is no explicit when-to-use/when-not guidance or direct comparison against alternatives like build_tralha or 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 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 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.