Dumaguete Extension

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so safety and determinism are fully covered. The description adds the currency context (Philippine pesos), which is useful, but nothing about caching, staleness of price data, or scope of coverage, which matters for cost figures.

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 resource and followed by the exact content list. Every clause 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?

No output schema, but the description enumerates what the caller will receive (rent bands, utilities, deposit, monthly total) and the currency, which is enough for an agent to call it correctly. Missing only currency-conversion or data-recency notes, minor for a read-only reference tool.

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

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

One optional lang parameter with 0% schema description coverage, but the enum values are self-explanatory language codes. The description says nothing about the lang parameter or multilingual output, so it neither compensates nor misleads. Baseline 3 for a single trivial parameter.

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?

Specific verb-style resource (cost of living in Dumaguete) with a content breakdown that distinguishes it from siblings like get_dumaguete_facts or get_dumaguete_paperwork. An agent can route to it without ambiguity.

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 content enumeration (rent bands, utilities, deposit, monthly total) makes the trigger condition clear by implication, but it never states when to prefer it over get_dumaguete_topic or search_dumaguete_answers. No explicit alternatives or exclusions.

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, openWorldHint=false, so the safety profile is covered. The description adds value by disclosing the exact content set (with no output schema to reveal it), but omits whether the facts are a static published snapshot and how current the prices are.

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 content inventory followed by the routing hint. The topic list is dense but earns its place by defining coverage; no filler.

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

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

For a read-only, no-required-param tool with no output schema, the description supplies enough for correct invocation and sets expectations for what comes back. Only a freshness/staleness caveat is missing for price-bearing facts.

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?

There is one optional parameter (lang) with a 23-value enum and 100% schema description coverage, so the schema already documents it fully (default en). The description says nothing about language, so 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 names the resource precisely ('the 12 key facts about Dumaguete City, Negros Oriental, Philippines') and enumerates the covered topics (rent, utilities, airport/ferries, visa office, hospitals, weather, place counts, listing prices). This lets an agent distinguish it from siblings like get_dumaguete_costs or get_dumaguete_weather, though it lacks a verb phrase stating it retrieves a fixed set.

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?

'Use first for any question about Dumaguete' is an explicit routing instruction that positions this as the default entry point over the more specific siblings. It does not, however, state when to prefer a sibling instead or what this tool won't answer (e.g., follow-ups needing fresh pricing).

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 and mutability profile is fully covered without description help. The description adds no behavioral detail beyond that — nothing about how the content is sourced, whether it is static or cached, or how the language selection affects the response. Minimal but not contradictory.

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 front-loaded sentence that leads with the subject (visa extensions and government offices) and then lists specifics. The agency enumeration is dense but earns its place by scoping the tool's coverage. Slightly fragment-like with no verb, but 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 static content-lookup tool with no output schema, the description gives a reasonable sense of what topics are covered, which helps an agent decide relevance. However, it omits the language-selection behavior and the default locale, both of which matter for correct invocation given the required-free 'lang' parameter.

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 0% and the description says nothing about the single 'lang' parameter, so it fails to compensate for the coverage gap. The enum values are self-describing language codes, but the description does not state which language is defaulted to when 'lang' is omitted (the parameter is not required). That gap is left entirely unresolved.

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 names a concrete resource — visa extensions and government offices in Dumaguete — and enumerates the agencies covered (Bureau of Immigration, LTO, SSS, NBI, DFA, City Hall, SIM registration). This clearly separates it from siblings like get_dumaguete_costs or get_dumaguete_weather by content domain. It loses a point only because the verb is left to the tool name and no sibling is explicitly named as an alternative.

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 only implied: an agent can infer this tool answers questions about bureaucracy/paperwork in Dumaguete, but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as get_dumaguete_topic or search_dumaguete_answers. The topic list serves as weak scoping guidance at best.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavior beyond them: the dataset size (742 verified places), that results are grouped by category, and that each result carries a barangay count and a dumaguete.uk link — effectively describing the return shape absent an output schema. It does not mention pagination or result caps, which for a 742-item list is the one meaningful omission.

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, zero filler, with the content scope front-loaded and the routing pointer second. Every clause 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 simple read-only listing tool with no output schema, the description adequately conveys what comes back (places, grouped by category, with counts and links). The only substantive hole is the undocumented 'lang' parameter, which an agent must guess at.

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 50%: 'category' is documented in the schema with its allowed ids, but 'lang' (a 23-value enum) has no description anywhere. The prose only implies category filtering ('by category') and says nothing about language behavior, so it neither compensates for the gap nor adds meaning beyond the schema. Baseline 3 fits.

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: it returns the 742 verified places in Dumaguete by category, along with barangay counts and links. That is far more specific than the vague sibling names, but it does not explicitly contrast itself with sibling tools like get_dumaguete_topic or search_dumaguete_answers; the only differentiation offered is against a non-sibling external API for single-place lookups.

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 a clear condition for when NOT to use it — 'For one individual place, use the source API at dumaguete.uk/v1/places' — which routes the agent away for single-record fetches. It stops short of stating when to prefer this over sibling aggregate tools such as get_dumaguete_facts or get_dumaguete_topic, so the guidance is one-sided but explicit.

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, destructiveHint=false and openWorldHint=false, so the safety profile is carried by structured data. The description adds only the empty-id fallback behavior; it says nothing about what a 'topic' payload contains or how large a full-catalog response is.

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 sentence that front-loads the primary mode (single lookup) before the fallback (all topics), with zero filler.

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

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

With no output schema, the description should at least sketch what a topic record looks like and note the lang effect on returned text. It covers the call mechanics adequately but leaves the return shape and localization behavior to inference.

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 50%: the id examples in the description duplicate the schema's own examples, so little net value there, though the empty-id semantics are clarified. The lang parameter is undocumented in both the schema and the description, leaving an important output-shaping control unexplained.

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 ('One Dumaguete topic by id') and its dual behavior ('or every topic when no id is given'), with concrete example ids. It doesn't differentiate itself from topical siblings like get_dumaguete_costs or search_dumaguete_answers, so it falls short of a 5.

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 no-id-equals-list-all behavior is implied usage guidance, and the id examples hint at the topic vocabulary. But there is no explicit when-to-use versus the seven sibling tools, particularly search_dumaguete_answers, which is the obvious alternative for free-form lookup.

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 readOnly, idempotent, non-destructive and closed-world behavior, so safety is covered. The description usefully adds the topical scope of what will be returned, but says nothing about the response form (prose text) or that output is localized.

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?

One compact sentence that front-loads the purpose ('How to reach Dumaguete and get around') and then lists covered modes. The enumeration is dense but every item is informative, with no filler.

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

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

No output schema exists, so the description should carry more of the burden; it adequately conveys content scope for a simple read-only info tool. It is incomplete regarding the lang parameter's effect on the returned content, which is the main thing an agent needs before calling.

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 0% and the description never mentions the single 'lang' parameter, so its meaning (output language) must be inferred entirely from the enum values. With one undocumented parameter, the description fails to compensate for the coverage gap.

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 and enumerates its contents (airport, ferries, buses, tricycles/jeepneys), so an agent knows exactly what topical information it returns. It does not explicitly distinguish itself from siblings like get_dumaguete_places or get_dumaguete_topic, which overlap in the 'about Dumaguete' space.

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?

No when-to-use, when-not-to-use, or alternative routing is given; nothing tells the agent why to pick this over get_dumaguete_places or search_dumaguete_answers. The content scope implicitly defines the topic, but that is inference, not guidance.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful scope by enumerating the content buckets the agent will get back, but it does not say whether this is static reference content or live conditions, nor whether the PAGASA detail is current.

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?

One tight sentence, front-loaded with the resource and followed by the content inventory; no filler. It reads as a topic dump rather than prose, but nothing is wasted.

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

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

For a simple read-only lookup with one optional parameter and no output schema, the topic inventory is reasonably complete about what comes back. It nonetheless omits the multilingual capability and any usage framing, leaving modest gaps.

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

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

Schema description coverage is 0% and the description never mentions the lang parameter or that the tool supports 23 output languages. The enum values make the parameter self-explanatory, but per the low-coverage rule the description should compensate and adds nothing here.

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 names a concrete resource (Dumaguete weather) and enumerates the specific topics returned — dry/wet seasons, amihan/habagat, street flooding, PAGASA signals. It is clearly distinguishable from siblings like get_dumaguete_costs or get_dumaguete_travel by topic, though it never explicitly states it retrieves a weather overview.

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?

There is no when-to-use or when-not guidance, no mention of alternatives such as get_dumaguete_topic or search_dumaguete_answers, and no indication of when this overview is preferable to a general search. The reader must infer usage purely from the tool name.

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 covered. The description adds that matching is over curated "short answers" rather than documents, and that both keyword strings and natural-language questions are accepted, but says nothing about ranking, result shape, or language handling.

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 front-loaded sentence: purpose first, then a colon-delimited topic list that helps agents match user phrasing. The topic enumeration is long and partly redundant with sibling tool names, but it earns its space as query-matching vocabulary.

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 no output schema, the description covers intent but omits what an agent needs to call it well: whether `lang` constrains the query or the results, that `limit` defaults to 5, and what a hit looks like. Annotations carry the safety story, so the gap is moderate rather than severe.

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 only 33%: "query" is documented and the description essentially restates it ("by keywords or a full question"). Neither `lang` (search/output language? which of 23 locales?) nor `limit` (default 5, capped at 20) is explained anywhere, so the description fails to compensate for the documentation gap.

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 gives a clear verb+resource ("search short answers about Dumaguete") and enumerates the topical breadth it covers (rent, visas, weather, forum, marketplace), which lets an agent recognize it as the general free-text lookup. It does not, however, explicitly contrast itself with the seven sibling topic tools, even though their coverage overlaps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says how to query ("keywords or a full question") but never states when to prefer this tool over get_dumaguete_costs, get_dumaguete_weather, or the other siblings whose subject matter it duplicates. There are no exclusions or routing hints for an agent facing eight overlapping Dumaguete tools.

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