company-data

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by specifying that the data is yearly financial history, amounts in RON, and lists the fields returned. It does not disclose potential error conditions or data availability, but it adds value beyond annotations.

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 a single sentence that front-loads key information: the data type, identification method, fields, and currency. Every part is necessary and there is no extraneous text.

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?

There is no output schema, so the description's list of fields (revenue, profit, employees, total assets, liabilities) gives a good sense of what the response contains. However, it does not specify the structure (e.g., an array of yearly objects) or handle possible missing data. For a simple retrieval tool, this is nearly 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 description mentions 'by CUI' but does not explain the 'years' parameter or clarify that it limits the number of years returned. With 0% schema description coverage, the description should compensate, but it adds no meaning beyond the schema property names.

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 that the tool retrieves yearly financial history for a company by CUI, listing specific financial fields (revenue, profit, employees, total assets, liabilities) and the currency (RON). This is specific and distinct from sibling tools like get_company_profile or get_company_status.

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 does not explicitly state when to use this tool versus alternatives, but the sibling tools have clearly different purposes (profile, status, search, caen), implying usage. No exclusions or prerequisites are mentioned, which would elevate the score.

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

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

Annotations already indicate read-only and open-world semantics. The description adds behavioral context: mentions 'latest public financials' implying possible staleness, and 'data-source freshness' as a field, which complements the openWorldHint.

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 sentences: first states what the tool does, second adds a crucial constraint. Every word serves a purpose; no redundancy.

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 single-parameter tool without output schema, the description covers input usage, output contents, and explicit omission. It is sufficiently complete for an agent to understand the tool's scope.

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 input schema has 0% description coverage, but the description compensates by explaining that 'cui' accepts an 'RO' prefix and is a Romanian company identifier, adding meaning beyond the schema.

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 specifies the tool's action ('Fetch'), the resource ('Romanian company'), and the identifier ('by CUI'). It explicitly lists what information is retrieved and what is not returned, distinguishing it from siblings like get_company_financials.

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 usage hints (accepts 'RO' prefix) and states what the tool does not provide (contact details). However, it does not explicitly mention when to use versus siblings or any prerequisites.

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

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

Annotations already declare readOnlyHint and destructiveHint=false. The description adds value by listing the types of status flags returned, though it does not cover data freshness or completeness aspects beyond the openWorldHint annotation.

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 a single, concise sentence that front-loads the main purpose and lists key output categories without redundant words.

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 simple tool with one parameter and no output schema, the description provides sufficient context: input (CUI), output categories, and distinguishes from sibling tools. No gaps remain.

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 only parameter 'cui' has no schema description (0% coverage). The description explains it is the company identifier used to look up status, adding necessary meaning beyond the raw schema.

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 returns public status flags for a company by CUI, listing specific statuses (registration, VAT, fiscal activity, etc.). This distinguishes it from siblings like financials, profile, or search.

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 implies usage for company status lookup but does not explicitly contrast with sibling tools or provide when-not-to-use guidance. No alternatives or exclusions are mentioned.

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

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

Annotations already indicate read-only and non-destructive behavior. Description adds that results include hierarchy and Romanian labels, but doesn't disclose other behavioral aspects like error handling or rate limits. No contradiction with annotations.

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?

One concise sentence that front-loads the main action and output, with additional detail on hierarchy and language. No wasted words.

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?

Completeness is adequate given the tool's simplicity and annotations. Description covers purpose, output contents, and language, but lacks details on error scenarios or input validation. Output schema is absent but not critical for this 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?

Single parameter 'code' has zero schema description. The description clarifies it's a Romanian CAEN activity code, adding semantic meaning beyond the bare schema. Slight room for improvement (e.g., format hints), but sufficient for correct use.

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?

Description clearly states the tool looks up a Romanian CAEN code and returns its official label and hierarchy. It uses specific verb 'Look up' and resource 'Romanian CAEN code', distinguishing it from sibling tools that deal with company data.

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?

No explicit guidance on when to use or avoid this tool vs. alternatives. However, the purpose is self-contained and distinct from siblings, implying use for code resolution independently.

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

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

Beyond annotations (readOnlyHint, destructiveHint), it adds concrete behaviors: max 25 results per page, opaque cursor, single-year financial filters, and the need for at least one filter.

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 core purpose and pack essential details without redundancy.

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?

Covers key aspects for a search tool but lacks output schema details; could mention result fields. Still, annotations (readOnlyHint, openWorldHint) reduce the burden.

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?

With 0% schema description coverage, the description lists most filter types (name, CAEN, county/locality, revenue/profit/employees, VAT, year), but misses parameters like 'limit', 'cursor', and 'active_only'.

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 it searches and filters a company directory using multiple criteria, distinguishing it from sibling tools that retrieve specific details for known companies.

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 specifies that at least one filter is required and provides default year and pagination details, but does not explicitly contrast with sibling tools or state when not to use.

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