Find and book fishing guides in Brazil, plus fishing spots, species and tides (pt-BR).
Scored across 12 tools
Most tools target distinct resources/actions: species, locations, rivers, guides, quotes, bookings, and conditions are separate. The main ambiguity is between search_destinations and search_locations, both used for “where to fish,” and between find_guides with dates and quote_trip, both returning trip pricing; descriptions help but the overlap is real.
All tool names use a consistent snake_case verb_noun pattern: find_guides, get_guide, search_species, quote_trip, request_booking, etc. The verbs are predictable and the entity names are clear throughout.
Twelve tools is well-scoped for a fishing-guide discovery and booking platform. Each tool covers a meaningful part of the workflow without feeling padded or thin.
The surface covers discovery, guide profiles, conditions, quoting, booking requests, and booking status well. However, the booking lifecycle has a notable gap: there is no cancel_booking or modify/reschedule tool, so an agent cannot complete those common follow-up actions and must fall back to the website.
Guias de pesca com barco e pousadas cadastrados na iscabox para um lugar do Brasil (rio, represa, cidade ou praia): guideId, nome, onde atende, de onde sai, peixes, se leva equipamento e o preço da diária; com datas, o total da viagem (com a taxa da iscabox) e o sinal. Nunca traz telefone, email ou Instagram. Sempre traz requestUrl, o pedido de guia na iscabox. Lista vazia quer dizer que a iscabox ainda não tem guia cadastrado ali; o mesmo pedido (requestUrl, ou request_booking sem guide_id) faz a equipe procurar um guia.
| Name | Required | Description | Default |
|---|---|---|---|
| fish | No | O peixe procurado (opcional), ex.: "tucunaré". | |
| kind | No | guia-barco (padrão) ou pousada (pousada ou pacote de pesca). | |
| place | No | O lugar, como o usuário disse. Ex.: "Represa de Furnas", "Bertioga", "rio Araguaia em Aruanã". | |
| people | No | Quantos pescadores (opcional). | |
| date_end | No | Último dia, AAAA-MM-DD (opcional). | |
| page_path | No | Ou o caminho exato da página do lugar na iscabox (/blog/locais/...), de search_destinations ou search_locations. | |
| date_start | No | Primeiro dia, AAAA-MM-DD (opcional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Well beyond the annotations, the description enumerates what comes back (guideId, name, service area, departure point, fish, equipment included, daily rate, trip total with the iscabox fee, deposit), states what is deliberately excluded (phone, email, Instagram), and always includes requestUrl. What it omits is pagination/result limits and how the iscabox fee is computed, which weakens but does not defeat an otherwise rich disclosure.
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?
Purpose is front-loaded, but the definition is a single long semicolon-chained sentence where return-field enumeration, privacy exclusions, and the empty-result fallback are stacked with equal weight. Each clause carries information, yet the density and lack of structure make the fallback guidance easy to miss.
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 return-value burden and does so thoroughly, including privacy limits and the requestUrl contract. For a 7-parameter, all-optional search tool this is nearly complete; only result-count or pagination behavior is unaddressed.
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 every parameter already carries its own description and the baseline is 3. The description adds only marginal meaning, mainly that supplying dates yields the trip total and the deposit, plus that place can be a river, dam, city, or beach; fish, people, kind, and page_path semantics come entirely from 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?
Opens with a specific verb+resource+scope: fishing-boat guides and lodges registered in iscabox for a place in Brazil (river, dam, city, or beach). The resource and geographic scope are unambiguous, but it never names the sibling it is not (get_guide for a single guide, search_locations/search_destinations for place lookup), so differentiation is left to inference.
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?
Gives explicit conditional guidance for the empty-result case: the same request (requestUrl, or request_booking without guide_id) makes the iscabox team search for a guide, which routes the agent to a named sibling. It does not say when to prefer this over get_guide or the search_* tools, so the main guidance gap is sibling selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Em que pé está uma reserva feita com request_booking, pelo bookingToken ou pelo payUrl: aguardando o pagamento do sinal, aguardando o guia (com o prazo), confirmada, cancelada ou reembolsada, com os valores e o último dia para cancelar. Os contatos não vêm aqui: depois do aceite eles vão pelo WhatsApp e ficam na página da reserva.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | O bookingToken, ou o payUrl inteiro. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered structurally. The description adds real value beyond them by disclosing what the response contains (state, amounts, last cancellation date) and, importantly, what it does not contain (contacts), which sets correct expectations for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and the accepted identifiers, followed by the state enumeration and the contact exclusion. The list of states is long but each item is informative; there is no filler or restatement of the title.
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 tool with no output schema, the description compensates well by listing the possible statuses and the fields returned (amounts, cancellation deadline). Combined with annotations covering the safety profile, an agent has what it needs; only pagination/format details for the free-form token could be tighter.
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 single parameter is documented as accepting either a bookingToken or a full payUrl. The description reinforces that dual form and adds provenance — the token comes from request_booking — which is meaning not present in the schema itself.
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 and resource (retrieving the status of a booking) and enumerates the exact states returned: awaiting deposit, awaiting guide with deadline, confirmed, cancelled, refunded. It also anchors the tool to the sibling that creates the booking (request_booking), so an agent can place it in the workflow immediately.
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 makes clear this is the follow-up to request_booking and that it works with either the bookingToken or the full payUrl. It explicitly excludes one expected use case (contact details), redirecting to WhatsApp and the booking page, which prevents a wrong call. It stops short of naming another tool as the alternative for that excluded data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Use quando o usuário perguntar sobre maré, lua, melhor horário para pescar, ou se o dia está bom. Hoje por padrão; passe date para amanhã, um dia da semana ou uma data, e range para a semana ou o mês inteiro. Maré só existe para portos do litoral; para água doce a ferramenta devolve a fase da lua e as janelas de horário do dia (bestWindows).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude em graus decimais do ponto citado, se você souber. Ex: -26.24. | |
| lng | No | Longitude em graus decimais. Ex: -48.63. | |
| date | No | O dia perguntado: "hoje", "amanhã", um dia da semana ("domingo") ou uma data ("2026-09-13", "13/09"). Omita para hoje. | |
| query | No | Cidade ou porto que o usuário citou. Ex: "São Francisco do Sul", "Guarapari". | |
| range | No | Quanto tempo o usuário quer: "dia" (padrão), "semana" (7 dias) ou "mes" (o mês inteiro publicado). Use "mes" quando ele pedir "tábua completa", "mês completo", "a tábua do mês" ou uma programação de viagem. | |
| water | No | 'doce' quando o ponto é rio, lago, represa, açude ou pesqueiro: a resposta sai sem maré. | |
| portSlug | No | Slug do porto coberto pela iscabox. Se a cidade que o usuário citou é um destes portos (ou é atendida por um deles), passe o slug direto — é mais confiável que a busca por texto. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no restating. The description adds genuine behavioral context the annotations cannot: tide data exists only for coastal ports, freshwater input returns moon phase plus bestWindows instead, and 'mes' returns the entire published month. It does not cover what happens when no location parameter is supplied, which would have earned a 5.
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, front-loaded with the output inventory before the usage triggers, and the freshwater caveat is placed last as a genuine edge case. Slightly dense in the middle sentence where date and range guidance are packed together, but no filler sentences.
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?
Seven optional parameters, no output schema, and no required fields make this a tool whose failure modes matter, and the description covers the two big ones: coastal-only tide data and freshwater fallback behavior. It also names the returned fields, compensating for the absent output schema. The remaining gap is what occurs when the agent passes no location hint at all.
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 and every parameter is already documented with examples. The description adds some meaning beyond the schema, notably that portSlug is more reliable than free-text city search and that range drives a full-month publication, but most of its parameter remarks (date formats, default today) restate 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 statement ('Condições de pesca de um dia') and enumerates the exact payload: tide table, moon phase, best time windows, water temperature and weather. No sibling tool (get_location, get_species, find_guides, search_destinations) overlaps with fishing conditions, so the agent can route unambiguously.
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?
Explicit trigger conditions are given: ask about tide, moon, best fishing time, or whether the day is good. Defaults and extensions are spelled out (today by default; date for tomorrow/weekday/date; range for week or month). It stops short of naming a when-not-to-use case or an alternative tool, but the trigger list is concrete enough that little is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
O perfil público de um guia cadastrado na iscabox, pelo guideId de find_guides: fotos, o que oferece, barcos (tipo, tamanho, motor, lugares), os lugares onde atende com o preço da diária e os peixes, e se leva equipamento. Sem telefone, email ou Instagram: os contatos são trocados pela iscabox depois que o guia aceita a reserva.
| Name | Required | Description | Default |
|---|---|---|---|
| guide_id | Yes | O guideId de find_guides ou search_destinations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: contact details are deliberately withheld and are exchanged by iscabox only after the guide accepts a reservation, which shapes downstream agent behavior. It does not cover error cases for an invalid guide_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what the tool returns, followed by the privacy constraint. Dense but every clause carries payload information; the field enumeration is long yet justified for a no-output-schema tool.
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?
Single required integer parameter, no output schema, so the description carries the full burden of describing the return shape. It does so field by field and additionally states what is excluded, leaving nothing an agent needs in order to call it or interpret the result.
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 already documents guide_id, including the search_destinations source that the description omits. The description's mention of find_guides adds nothing beyond the schema text. Baseline 3 applies where the schema does the work.
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 resource (public profile of a registered guide) plus the exact key that selects it (guideId from find_guides) and enumerates the payload: photos, offerings, boats with type/size/engine/seats, served locations with daily rate and fish, and equipment inclusion. An agent can distinguish this from find_guides (search) without opening any schema.
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?
Implies the workflow clearly: the guide_id comes from find_guides, so this is a lookup of an already-identified guide rather than a discovery tool. It also sets a firm boundary on what cannot be obtained here (phone, email, Instagram), pointing the agent to the booking flow instead. No explicit named alternative is given for the search case, which keeps it at 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detalhes de um local de pesca: como chegar, melhores pontos, espécies, iscas e técnicas que funcionam ali.
| Name | Required | Description | Default |
|---|---|---|---|
| locationPath | Yes | O locationPath exato retornado por search_locations. |
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.
Traçado de um rio que a iscabox mapeou: os municípios que ele atravessa, na ordem da nascente à foz, com o trecho em km de cada um, e os locais de pesca do acervo ao longo dele. Use quando o usuário perguntar por onde um rio passa, que cidades ficam nele, ou onde pescar ao longo de um rio.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Nome do rio como o usuário escreveu. Ex: "rio taquari". |
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.
Detalhes de uma espécie: habitat, dieta, técnicas que funcionam, iscas, melhor época do ano (seasonalCalendar) e regiões onde pescar. Use antes de recomendar equipamento ou local para um peixe específico, e para "melhor época / quando pescar X".
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | O slug retornado por search_species. Ex: "tucunare". |
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.
Orçamento de uma pescaria com um guia da iscabox: guia + datas + pessoas → o preço do guia, a taxa da iscabox (13% por cima), o total, o sinal pago pela iscabox (que dá mais segurança ao pescador e ao guia e volta inteiro se o guia não aceitar), o restante pago ao guia no dia, o último dia para cancelar com tudo de volta e em quantas horas o guia responde. Os mesmos valores que o site cobra. Não cria pedido.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Opcional, quando o guia oferece os dois. | |
| people | No | Quantos pescadores (padrão 1). | |
| date_end | No | Último dia, AAAA-MM-DD (o mesmo dia para um dia só). | |
| guide_id | Yes | O guideId de find_guides. | |
| page_path | No | O lugar, quando o guia atende mais de um (pagePath de get_guide). Sem ele, o primeiro lugar do guia. | |
| date_start | Yes | Primeiro dia, AAAA-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the description is free to add business behavior — the 13% fee, a refundable deposit that returns in full if the guide declines, the on-day balance, the cancellation cutoff, guide response latency, and the assurance that values match what the site charges. That is substantial context beyond the safety hints and reinforces the read-only nature.
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?
Front-loaded with the purpose, then an arrow mapping inputs to a checklist of returned values, closing with the key exclusion. The nested parentheticals explaining the deposit make one sentence quite dense, but every clause carries real information and the ordering is logical.
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 correctly spends its budget enumerating the returned fields, including the fee arithmetic and refund terms. Combined with annotations covering the safety profile, an agent has everything needed to call this and interpret the result.
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 a baseline of 3 applies, but the description adds value by framing the operative inputs as 'guia + datas + pessoas', signaling which parameters actually drive the computation and implicitly demoting kind and page_path to optional refinements. It does not explain date formats or the page_path fallback, which the schema already handles.
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 and resource (quoting a guided fishing trip) and enumerates exactly what the quote contains: guide price, the 13% iscabox fee, total, deposit, remainder, cancellation deadline, response time. It also draws a hard boundary with the booking path via 'Não cria pedido', so an agent can tell it apart from request_booking without opening a schema.
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 purpose plus 'Não cria pedido' makes the when-to-use context clear (price inquiry, not booking) and implicitly routes booking to a sibling. It never names request_booking explicitly, so the alternative must be inferred from the sibling list rather than read from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Faz o pedido de reserva na iscabox e devolve payUrl, a página da iscabox onde o pescador paga o sinal. O pedido só chega ao guia depois do sinal pago; o guia tem 24 h para aceitar (6 h quando a pescaria é hoje ou amanhã) e, se não aceitar, o sinal volta inteiro. Os contatos do guia e do pescador são trocados pelo WhatsApp depois do aceite. Precisa do WhatsApp do pescador e não recebe dados de pagamento. Sem guide_id, o pedido vai para a equipe da iscabox, que procura um guia para o lugar e responde pelo WhatsApp (útil quando find_guides vem vazio).
| Name | Required | Description | Default |
|---|---|---|---|
| fish | No | O peixe procurado (opcional). | |
| kind | No | guia-barco (padrão) ou pousada. | |
| name | No | O nome do pescador (opcional). | |
| people | No | Quantos pescadores (padrão 1). | |
| date_end | No | Último dia, AAAA-MM-DD. | |
| guide_id | No | O guideId escolhido (de find_guides). Sem ele, a iscabox procura um guia. | |
| Yes | O WhatsApp do pescador, com DDD. Ex.: "(31) 99876-5432". | ||
| page_path | No | O lugar (pagePath de search_destinations, find_guides ou get_guide). Com guide_id, padrão é o primeiro lugar do guia. | |
| date_start | No | Primeiro dia, AAAA-MM-DD. Obrigatório com guide_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations covering the safety profile (mutation, openWorld, non-idempotent, non-destructive), the description adds substantial lifecycle context: the request only reaches the guide after the deposit is paid, the 24h/6h acceptance window, full deposit refund on rejection, and WhatsApp contact exchange after acceptance. It also states a hard prerequisite (fisher's WhatsApp) and an explicit exclusion ("não recebe dados de pagamento"), which an agent cannot infer from the schema or 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 core action and return value are front-loaded, then the acceptance/refund lifecycle, then the edge case of a missing guide_id with its motivating condition. Dense but every sentence carries a distinct fact; only the guide-contact sentence could be trimmed without loss of decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nine-parameter mutation tool with no output schema, the description supplies the return value (payUrl and what the page is for), the full post-request lifecycle, prerequisites, and the no-guide fallback path. Nothing an agent needs in order to decide and call correctly is missing, including what not to send.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all nine parameters described, so the baseline is 3. The description reinforces only two points already documented in the schema — that whatsapp is required and what happens without guide_id — and adds no format, range, or interdependency detail beyond 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?
"Faz o pedido de reserva na iscabox e devolve `payUrl`" names a specific verb (pedido de reserva), the resource (booking), the target system, and the primary return value. This clearly separates it from read-only siblings like find_guides or quote_trip, and an agent knows immediately what changes in the world.
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 documents the fork in usage: with guide_id the request goes to that guide, without it the iscabox team finds a guide and answers via WhatsApp — including the trigger condition "útil quando find_guides vem vazio". What is missing is a direct comparison with quote_trip (price inquiry before booking), which an agent would plausibly confuse with this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Destinos de pesca no Brasil (rios, represas, lagos e litoral) para um peixe, uma região ou perto da cidade de onde o pescador sai: os peixes de cada lugar, a distância, os guias cadastrados na iscabox ali e se a piracema fecha a pesca nas datas. Cada destino traz pagePath (para find_guides e request_booking) e requestUrl, o pedido de guia no site. Um destino sem guia cadastrado ainda pode receber pedido: a equipe da iscabox procura um guia.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Ou a latitude do ponto de partida, em graus decimais. | |
| lng | No | E a longitude. | |
| fish | No | O peixe, ex.: "tucunaré", "robalo", "dourado". | |
| kind | No | guia-barco (padrão) ou pousada. | |
| near | No | Cidade (município) de onde o pescador sai, ex.: "Belo Horizonte", "Campinas". | |
| limit | No | Quantos destinos (1-8, padrão 5). | |
| place | No | Nome de um lugar ou região, ex.: "Pantanal", "Araguaia", "litoral norte de SP". | |
| state | No | Estado, pelo nome ou pela sigla. Ex.: "Minas Gerais", "MS". | |
| max_km | No | Distância máxima da cidade de partida, em km (padrão 400). | |
| people | No | Quantos pescadores (opcional). | |
| date_end | No | Último dia, AAAA-MM-DD (opcional). | |
| date_start | No | Primeiro dia, AAAA-MM-DD (opcional; usado para guias livres e piracema). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and closed-world, so the bar is lower. The description nonetheless adds real business behavior beyond them: what each result carries (fish per place, distance, registered iscabox guides, piracema closure on the requested dates) and the fallback that iscabox staff will source a guide when none is registered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first carries purpose and filters, the second carries return shape plus the no-guide fallback, with nothing decorative. The first sentence is densely packed with parentheticals, but nothing is redundant.
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 12 optional parameters and no output schema, the description does the work of describing the result fields and the pagePath/requestUrl artifacts, which is the main gap a schema alone would leave. It lacks only edge-case behavior (empty results, how lat/lng interacts with near, how limit truncates ranking).
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 every parameter including lat/lng, max_km, kind and the date pair is already documented in the schema. The description adds only the framing that date_start drives piracema/availability checks and that results are proximity-filtered, which is marginal over the schema's own wording. 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?
States the resource (fishing destinations in Brazil: rivers, reservoirs, lakes, coast) and the three retrieval axes (fish, region, near-city) in one front-loaded clause. It also distinguishes itself from find_guides and request_booking by naming them as downstream consumers of the returned pagePath, so an agent can place it in the workflow without reading the schemas.
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 filter axes and the downstream handoff (pagePath for find_guides and request_booking, requestUrl for the site request) make the intended use clear, and the note that unguided destinations can still receive a request removes a likely hesitation. It stops short of an explicit when-not-to-use rule or a contrast with search_locations, so no full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca locais de pesca no acervo da iscabox — rios, represas, praias, pesqueiros. Filtre por estado, espécie ou tipo de água. Use quando o usuário perguntar onde pescar. Se o usuário citar uma cidade, passe lat e lng dela: locais próximos entram na resposta mesmo quando a cidade em si não tem página. Use kind para separar pesque-pague de água livre.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude, em graus decimais, da cidade ou ponto que o usuário citou. Preencha com o que você sabe da geografia brasileira. Ex: Marau (RS) é -28.45. | |
| lng | No | Longitude do mesmo ponto. Ex: Marau (RS) é -52.20. | |
| kind | No | Tipo de local. "pesqueiro" = pesque-pague; "natural" = rio, represa, lagoa, praia. Passe "natural" quando o usuário não quer pesque-pague. | |
| limit | No | Quantos resultados (1-8, padrão 5). | |
| query | No | Nome do local, cidade, região ou espécie. | |
| state | No | Nome ou slug do estado. Ex: "sao-paulo", "Mato Grosso". | |
| water | No | Tipo de água. Use "estuarine" para estuários e "pelagic" para pesca em alto-mar / oceânica / mar aberto. | |
| anchor | No | Lugar citado antes na conversa, quando a mensagem atual não cita nenhum ("quero locais na beira do lago" depois de falar de Fortaleza): a busca fica ancorada nele. | |
| exclude | No | locationPath dos locais já mostrados, para não repeti-los. | |
| radiusKm | No | Distância máxima em km quando o usuário pede para ampliar ("até 1 hora e meia", "uns 100 km"). Dentro do raio, os melhores locais vêm primeiro, não os mais perto. | |
| speciesSlug | No | Slug de espécie (de search_species) para achar onde pescá-la. |
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.
Busca espécies de peixes no acervo da iscabox pelo nome popular ou científico. Use quando o usuário mencionar um peixe para confirmar qual espécie é antes de responder.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Quantos resultados (1-8, padrão 5). | |
| query | No | Nome do peixe. Ex: "tucunaré", "robalo". | |
| water | No | Filtra por tipo de água. |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
build_tralhafind_guides1 field changedInput schema / properties / page_path / descriptionPrevious value: -"Ou o caminho exato da página do lugar na iscabox (/blog/locais/...), de search_locations."New value: +"Ou o caminho exato da página do lugar na iscabox (/blog/locais/...), de search_destinations ou search_locations."get_booking_statusget_creator_pageget_creator_tralhaget_equipment_detailsget_guideget_lures_for_speciesquote_triprequest_bookingsearch_destinationssearch_equipmentfind_guidesget_equipment_details1 field changedInput schema / properties / productPath / descriptionPrevious value: -"O productPath exato retornado por search_equipment."New value: +"O productPath retornado por search_equipment (aceita também a URL da página do produto)."get_techniquesearch_equipment1 field changedInput schema / properties / techniqueAdded value: +{
+ "description": "Estilo de pesca: limita aos equipamentos que servem para ele e devolve o guia da técnica. Combina com category (ex.: technique \"praia\" + category \"molinetes\").",
+ "enum": [
+ "ultralight",
+ "arremesso-carretilha",
+ "superficie",
+ "meia-agua",
+ "iscas-de-silicone",
+ "pesqueiro",
+ "praia",
+ "embarcada-mar",
+ "jigging",
+ "fly",
+ "caiaque",
+ "pesca-submarina"
+ ],
+ "type": "string"
+}search_techniquesget_creator_pageget_creator_tralhasearch_equipment1 field changedInput schema / properties / subcategory / descriptionPrevious value: -"Subcategoria exata, se souber."New value: +"Subcategoria exata, se souber. Em varas: casting (vara para carretilha), spinning (vara para molinete), vara-de-mao, fly, praia, telescopicas."search_equipment1 field changedInput schema / properties / category / descriptionPrevious value: -"Categoria exata. Uma de: acessorios, anzois, barcos-e-caiaques, boias, carretilhas, chumbadas, iscas-artificiais, linhas, molinetes, motores, roupas, varas."New value: +"Categoria exata. Uma de: acessorios, anzois, barcos-e-caiaques, boias, carretilhas, chumbadas, iscas-artificiais, linhas, molinetes, motores, pesca-submarina, roupas, varas."search_locations2 fields changedInput schema / properties / excludeAdded value: +{
+ "description": "locationPath dos locais já mostrados, para não repeti-los.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / radiusKmAdded value: +{
+ "description": "Distância máxima em km quando o usuário pede para ampliar (\"até 1 hora e meia\", \"uns 100 km\"). Dentro do raio, os melhores locais vêm primeiro, não os mais perto.",
+ "type": "number"
+}get_fishing_conditions1 field changedInput schema / properties / waterAdded value: +{
+ "description": "'doce' quando o ponto é rio, lago, represa, açude ou pesqueiro: a resposta sai sem maré.",
+ "type": "string"
+}search_equipment1 field changedInput schema / properties / sortByPriceAdded value: +{
+ "description": "'asc' para o mais barato primeiro. Use quando o usuário pedir \"a mais barata\".",
+ "type": "string"
+}search_locations1 field changedInput schema / properties / anchorAdded value: +{
+ "description": "Lugar citado antes na conversa, quando a mensagem atual não cita nenhum (\"quero locais na beira do lago\" depois de falar de Fortaleza): a busca fica ancorada nele.",
+ "type": "string"
+}get_fishing_conditions1 field changedInput schema / properties / rangeAdded value: +{
+ "description": "Quanto tempo o usuário quer: \"dia\" (padrão), \"semana\" (7 dias) ou \"mes\" (o mês inteiro publicado). Use \"mes\" quando ele pedir \"tábua completa\", \"mês completo\", \"a tábua do mês\" ou uma programação de viagem.",
+ "enum": [
+ "dia",
+ "semana",
+ "mes"
+ ],
+ "type": "string"
+}get_fishing_conditions1 field changedInput schema / properties / dateAdded value: +{
+ "description": "O dia perguntado: \"hoje\", \"amanhã\", um dia da semana (\"domingo\") ou uma data (\"2026-09-13\", \"13/09\"). Omita para hoje.",
+ "type": "string"
+}build_tralhaget_equipment_detailsget_fishing_conditionsget_locationget_lures_for_speciesget_riverget_speciesget_techniquesearch_equipmentsearch_locationssearch_speciessearch_techniquesTides, currents, marine forecasts and warnings for paddlers, anglers and small boats, 26 countries.
Search 1.8M+ live Brazilian used-car and motorcycle listings, with FIPE reference prices.
Free lookup of 28.4M active Brazilian companies by CNPJ or name (Receita Federal open data).
Brazilian case law: 1.1M+ decisions from 17 courts, with citable links to official sources.
Add one secure layer between your agents and this server.