get_price

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

With no annotations provided, the description shoulders the burden of behavioral disclosure. It clearly explains what the tool returns ('price, previous close, change %, day range and — for equities — the 52-week range and where price sits inside it') and documents accepted symbol formats per market. However, it does not mention potential errors, rate limits, or that it is a read-only operation (which is implied but not explicit). This is more than adequate for a simple price lookup tool.

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 appropriately sized and well-structured, using 'Args:' and 'Returns:' sections. Every sentence provides necessary information: symbol formats, market values, and return fields. There is no fluff or repetition, and the content is front-loaded with the core action first.

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 simplicity (2 params, 1 required) and the presence of an output schema, the description covers all necessary aspects for correct invocation: what it does, how to specify symbol and market, and what data is returned. It is complete enough for an agent to select and use the tool effectively without additional context.

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?

Schema description coverage is 0%, so the description fully compensates by explaining both parameters in detail. It describes the 'symbol' parameter with concrete examples for each market (BTC, BTCUSDT, AAPL, BBCA) and defines the 'market' parameter's allowed values ('crypto', 'stock', 'idx'). This adds substantial meaning beyond the bare schema, making invocation correct without needing external knowledge.

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: 'Get the current price and daily change for one instrument.' It specifies a verb ('Get'), resource ('current price and daily change'), and scope ('one instrument'), which distinguishes it from sibling tools like get_prices (plural). This is a specific and unambiguous purpose.

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 clear context on when to use the tool, detailing accepted symbol formats per market (crypto, stock, idx) and explaining return data. It implicitly differentiates from get_prices by emphasizing 'one instrument,' but it does not explicitly name alternatives or state when-not-to-use scenarios. This aligns with 'clear context, no exclusions'.

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