get_tipping_rulesGet concise tipping guidance for a country: status, summary, key service recommendations, last reviewed date, and the canonical country URL.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country slug (preferred) or country name, e.g. japan or Japan. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results are 'concise' and curated (status, recommendations), but doesn't disclose aspects like whether the data is cached, how current the 'last reviewed date' typically is, or what happens for an unknown country slug.
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 one concise sentence that front-loads the core action ('Get concise tipping guidance for a country') and then lists the key output fields. Every phrase earns its place; no filler or redundant wording.
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 tool with a rich schema and safety annotations, the description is nearly complete. It tells the agent what it will get back (making the output predictable) and keeps scope clear. Missing only minor behavioral edge cases (unknown country, normalization), which are unlikely to block correct 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?
The schema has 100% description coverage for its single parameter (country slug/name with example), and the description adds context that the tool is about tipping rules, which reinforces the parameter's purpose. The description could add nuance like case-insensitivity or how 'Japan' vs 'japan' is normalized, but the schema already covers the essential meaning.
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 verb ('Get') and resource ('tipping guidance for a country'), and enumerates the exact content returned: status, summary, key service recommendations, last reviewed date, and canonical country URL. This distinguishes it from any sibling tool that might return detailed tipping explanations or browse all countries.
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 for 'concise tipping guidance' per country, which implies when to use it, and the single-country scoping implicitly rules out multi-country lookups. However, no explicit alternatives or when-not-to-use guidance is provided; an agent is left to infer that broader tipping content is elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct role: searching for countries, retrieving tipping rules, and calculating tips. There is no overlap or ambiguity between them.
All tool names follow the same verb_noun snake_case pattern: calculate_tip, get_tipping_rules, search_countries. The naming is predictable and consistent.
With three focused tools, the set is lean but well-scoped for the domain. Each tool serves a necessary and distinct part of the tipping guidance workflow.
The server covers the core workflow of discovering a country, reading its tipping rules, and calculating a tip. A minor gap is the lack of a bulk 'list all countries' tool, but search by name or region sufficiently covers discovery.