Electronic Compliance Objects (49 markets)

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

Annotations already declare readOnly, idempotent, closed-world behavior, yet the description adds genuine extra context: every field carries its source page and a signature (kid allooloo-eco-2026-10), plus a node status. That provenance/signing detail is behavioral information not available in the annotations, though caching or freshness behavior is unstated.

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 resource is front-loaded, but the rest is a single dense run-on cataloguing a dozen fields plus a signing key identifier, which is harder to parse than a structured list. Most content is relevant, but the signing kid is a fine detail that slightly clutters the core message.

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 no output schema, the description carries the burden of describing the return value, and it does so by enumerating the fields (regulator, exchanges, deadlines, ISIN prefix, LEI, calendar, halts page, node status). For a single-parameter read tool that is largely complete, though it omits error behavior for an unknown market code.

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 coverage is 100% and the market parameter is fully described in the schema, so the schema does the heavy lifting. The description only implies a single-market scope via 'of one market (49)' and adds no format or syntax detail beyond what the schema provides.

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 names a specific resource (the Electronic Compliance Object for one market) and enumerates its contents, so an agent knows exactly what it retrieves. It does not distinguish itself from siblings like get_signal or resolve_issuer, leaving sibling differentiation to inference.

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 statement of when to call this versus get_signal, list_nodes, or resolve_issuer, and no prerequisites such as needing a market code first. Usage must be guessed from the resource name alone.

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?

The description adds substantial behavioral context beyond the annotations: it explains every signal code, notes the home-market scope, covers the conditional ticker case, routes GTINs elsewhere, discloses the system-error condition, and clarifies that halted status is advisory and links to the market's halts page. The annotations already cover safety and idempotency, and nothing contradicts them.

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 front-loaded with the tool's purpose and then efficiently enumerates the signal codes and edge cases. It is dense but appropriately sized for the number of status codes, with only the signal-page URL sentence being marginally expendable.

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 read-only tool with no output schema, the description provides enough context to call it correctly: it explains the identifier expectations, the meaning of each possible signal, the conditional exchange requirement, the GTIN exclusion, and the halted advisory behavior.

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 coverage is 100% and the identifier schema already documents ISIN, ticker with exchange, LEI, and CMR key formats. The description adds useful semantics by warning that a bare ticker may name multiple issuers and by excluding GTINs, directing them to gtinfetch.ai.

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 identifies the resource as the ACM-68000 signal for a listed security in its home market and enumerates the possible signal codes. It is distinguishable from siblings like get_record and resolve_issuer by its focus on a signal status, though it does not explicitly name those alternatives.

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 input-specific guidance such as adding an exchange when a bare ticker names multiple issuers and asking gtinfetch.ai for GTINs. However, it does not state when to use this tool versus sibling tools like resolve_issuer or get_record, leaving selection largely implied.

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=true, idempotentHint=true, destructiveHint=false, and a closed world, so the safety profile is fully covered. The description usefully adds that the result set is a fixed twelve nodes with liveness and Agent Card data, which implies no pagination or filtering, but says nothing about ordering or failure modes.

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 short sentence with no filler, and the key content (the twelve nodes and their attributes) is front-loaded. It reads as a fragment rather than a sentence, which slightly hurts clarity but not length.

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 zero-parameter, non-paginated read tool with no output schema, the description covers enough to know what comes back at a high level. However, undefined domain terms like 'market nodes', 'regional doors', and 'Agent Cards' are not explained, leaving the agent unsure what the returned data actually represents.

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 is nothing for the description to disambiguate. Baseline 4 applies since no parameter semantics are needed.

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 is a noun phrase rather than a verb+resource, and it largely restates the title 'List market nodes', but it does add real detail beyond it: exactly twelve nodes, liveness status, regional doors, and Agent Cards. The resources covered are identifiable, though nothing distinguishes this from sibling list tools.

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 when-to-use, when-not-to-use, or alternative-tool guidance. The sibling tools (get_record, list_aliases, list_events_since, resolve_issuer) are never referenced, so the agent must infer from the name alone when this listing is the right call.

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 readOnly, idempotent, non-destructive and closed-world behavior. The description adds genuinely new behavioral context — that the apex node resolves ownership and forwards to a regional node for the summary — but says nothing about failure modes (unknown identifier), latency, or what the summary contains.

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 sentence, front-loaded with the purpose before the routing detail, with no filler. The trailing architecture jargon ('apex names the owning node and forwards to that node's regional door') is dense and slightly obscures rather than clarifies.

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 no output schema and no annotations covering the return value, the description carries the burden of explaining results, yet only says 'the record summary' without defining it. For a single-parameter lookup the input side is well covered, but the output side and the internal routing metaphor remain under-specified.

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 coverage is 100% and the parameter description already spells out ticker formats, ISIN, LEI, exact legal name and sourced alias. The description adds little beyond repeating 'ticker, ISIN or LEI', and in fact omits the legal-name and alias forms the schema supports, so it is baseline at best.

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 concrete verb ('Find') and resource ('listed company') and enumerates the identifier kinds (ticker, ISIN, LEI), so an agent can tell what the tool does. However, it never contrasts itself with the nearby sibling get_record, even though it also mentions returning 'the record summary', leaving some ambiguity about which tool to pick.

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 the tool is for looking up a company from an identifier, but offers no explicit when-to-use guidance, no when-not-to-use, and no comparison to siblings like get_record or list_nodes. The agent must infer that resolution is the entry point to the record summary.

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