Query Indonesian administrative area IDs for shipping calculations. [CRITICAL]: 1) Search using ONLY a single subdistrict or district name (e.g. 'Setia Budi' or 'Arcamanik') or a 5-digit postal code. 2) DO NOT combine multiple levels in a single query.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Single subdistrict/district name, or 5-digit postal code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly warns about the critical input format and the prohibition on combining levels, which helps the agent understand the tool's strict requirements. However, it does not describe the return format or any potential errors.
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 concise and front-loaded with the core purpose, followed by clearly structured critical instructions. Every sentence contributes essential information without redundancy or unnecessary 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?
Given the tool's low complexity (one parameter, no output schema), the description covers the essential aspects: what the tool does and how the input must be formatted. It does not explain the return values in detail, but the phrase 'administrative area IDs' implies the output, making the description sufficiently complete for this simple 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?
The schema already describes the single 'input' parameter as a subdistrict/district name or postal code (100% coverage). The description adds value by providing examples ('Setia Budi', 'Arcamanik'), explicitly specifying the 5-digit postal code format, and emphasizing the critical rule against combining multiple levels.
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's function: 'Query Indonesian administrative area IDs for shipping calculations.' It specifies a distinct resource (area IDs) and purpose, which differentiates it from sibling tools like get_courier_rates and usage_statistic.
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 provides explicit usage constraints: search using only a single subdistrict/district name or 5-digit postal code, and explicitly instructs not to combine multiple levels. This gives clear context on how to use the tool, though it does not mention any alternative tools or when not to use it beyond the constraint.
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 serves a clearly distinct purpose: get_courier_rates for shipping costs, get_map_areas for administrative IDs, and usage_statistic for API limits. There is no overlap or ambiguity between them.
Two tools follow the get_verb_noun pattern (get_courier_rates, get_map_areas), but usage_statistic deviates as a noun phrase. The naming is still readable and predictable, with only a minor inconsistency.
With only 3 tools, the set is well-scoped for a focused logistic rates API. Each tool is necessary, and the count falls comfortably within the typical 3-15 range, avoiding bloat.
The tool surface covers the full workflow: get_map_areas provides required area IDs, get_courier_rates delivers the core functionality, and usage_statistic handles API monitoring. There are no obvious gaps for the stated purpose.