Financial highlights

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

The description goes well beyond the readOnlyHint annotation by disclosing critical behavioral details: figures are never rescaled, each period has its own currency_units label, the two sections may disagree (with a concrete observed example), and the scale should be treated as uncertain if labels conflict. This is exactly the kind of contextual information an agent needs to avoid misinterpreting results.

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 efficiently structured: purpose first, then return structure, then the critical units warning, then scope clarification. Each sentence earns its place, and the units warning is front-loaded for safety. Despite being relatively long, it is highly informative and not verbose.

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 complexity (annual vs quarterly sections, currency unit inconsistencies, line-item labels), the description covers the key aspects of return format, data source limitations, and the critical unit caveat. Since an output schema exists, return values are further specified, making the description complete for an agent to invoke the tool correctly and interpret results safely.

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 has only one parameter 'symbol' with no description. The tool description does not explain the symbol parameter's format or examples, despite low schema coverage (0%). The phrase 'for a company' indirectly implies the parameter is a company identifier, but it does not compensate for the lack of explicit parameter documentation.

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 ('Get') and resource ('financial highlights PSE Edge publishes for a company'), and details the return structure (annual/quarterly sections with balance sheet and income statement). This clearly distinguishes it from siblings like get_stock_quote or get_company_profile.

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 gives clear context about data scope and an important exclusion ('Only the highlights Edge serves as data are here — this server does not parse filed PDF statements'). This implicitly tells when not to use the tool, but it does not name alternative tools explicitly, leaving some ambiguity for agents unfamiliar with sibling tools.

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