get_mexico_municipalities

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

With no annotations, the description carries the full burden. It discloses important behavioral traits: results are ranked by amount, data is annual only, and pagination is supported through limit and offset. It does not describe response shape or edge cases, but for a read-only list tool the main behavior is well covered.

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 concise sentences front-load the main operation and then add filtering, pagination, and granularity guidance. Every sentence earns its place with no filler or 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 relatively simple read tool, the description covers scope, ranking, annual granularity, state filtering, and pagination. It lacks an explicit pointer to sibling tools for state-level or national comparisons, and sort direction is only implicit, but the core calling context is sufficiently complete.

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 documents year and state, so the description adds value mainly by explaining limit and offset as pagination mechanisms and reinforcing that state restricts to one state. It does not explicitly tie the 'year' concept to the year parameter or explain defaults, but it compensates reasonably for the 50% schema coverage.

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: 'Remittances received by Mexican municipality for one year, ranked by amount.' This clearly identifies the tool's scope and distinguishes it from siblings like get_mexico_state_timeseries and get_national_totals by emphasizing 'one year' and 'municipal data is annual only.'

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 clear context for use: annual municipal-level data, optional state filtering, and pagination using limit and offset. However, it does not explicitly name sibling alternatives or state when not to use this tool versus get_mexico_states or get_coverage, so it stops short of full routing guidance.

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