life__get_fuel_prices
[台彩 發票 油價對獎]取得台灣中油本週油價(92、95、98 無鉛汽油、酒精汽油、超級柴油,每公升新台幣)與比上週漲跌。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
[台彩 發票 油價對獎]取得台灣中油本週油價(92、95、98 無鉛汽油、酒精汽油、超級柴油,每公升新台幣)與比上週漲跌。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It does disclose the scope (this week's CPC prices) and that a week-over-week delta is included, which adds real behavioral context. However it says nothing about update cadence, data source authority, or whether the delta can be null/absent.
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 well-formed sentence with no filler. The bracketed prefix '[台彩 發票 油價對獎]' is a keyword/cluster tag that adds little for an agent, mildly diluting the front-loading, but the core payload follows immediately.
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, no output schema, and no annotations, the description's enumeration of returned fuel grades and the week-over-week delta is enough for an agent to know what a call yields. The main missing piece is any routing versus the fuel-promos sibling.
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 the baseline is 4. The description correctly implies a no-argument call returning a fixed set of fuel grades. Nothing further is needed on the parameter side.
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 specific verb+resource ('取得...台灣中油本週油價') and enumerates exactly which grades are returned (92/95/98 unleaded, alcohol gasoline, super diesel, NT$ per liter) plus week-over-week change. This is far more specific than the tool name alone, but it never distinguishes itself from the nearby sibling life__get_fuel_promos.
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 explicit when-to-use, when-not-to-use, or alternative routing. The only guidance is implied by 'this week's prices'. An agent faced with both get_fuel_prices and get_fuel_promos gets no signal about which applies.
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.