Lists DGEG fuel types and valid district names for fuel-price queries, helping you choose the correct fuel name before requesting prices.
List DGEG fuel types (id, name, unit) and the districts accepted by fuel_prices.
Only needed when unsure which fuel name to pass; fuel_prices also understands "diesel", "petrol", "95", "98", "lpg".
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. The verb "List" clearly implies a read-only reference lookup with no mutation, and the description identifies what is returned (fuel type ids/names/units and accepted districts), though it does not discuss authentication, caching, or rate limits.
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 short sentences with no filler. The core list purpose is front-loaded, followed immediately by the usage caveat and alternative.
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 zero parameters and an output schema present, the description does not need to explain return values in detail. It provides enough context about what the tool lists, when to use it, and which sibling handles common fuel names, making it complete for this simple reference lookup.
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 tool takes zero parameters, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and the description appropriately does not invent parameter details.
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 and resource: it lists DGEG fuel types with their id, name, and unit, and also lists the districts accepted by fuel_prices. It clearly distinguishes itself from the sibling fuel_prices tool by explaining that fuel_prices accepts common fuel names directly.
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 says it is only needed when the agent is unsure which fuel name to pass, and it names fuel_prices as the primary alternative that understands "diesel", "petrol", "95", "98", and "lpg". This gives a clear when-to-use and when-not-to-use rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.