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

With no annotations, the description carries the full burden and does explain the main behavior: it returns three kinds of series and an industry distribution. However, it does not disclose how peers are selected, what timeframe granularity is used, or how missing/edge cases are handled, so the behavioral disclosure is partially complete.

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 dense sentence with no filler. It front-loads the core action and outputs, then adds an interpretative use case ('Answers is this good?') that gives the agent meaningful selection guidance without extra 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 4-parameter tool with no output schema, the description adequately covers the return values (company series, peer series, distribution) and the schema covers parameter semantics thoroughly. It lacks details like peer selection criteria or data frequency, but nothing required for a competent call is missing.

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%, so the baseline is 3 even without parameter details in the description. The description adds only conceptual mapping ('single metric' to metric, 'several years' to years, 'peers' to peer_count), which is helpful but not beyond what the schema already 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 verb ('Benchmark'), a specific resource ('one company against its industry peers'), and a specific scope ('on a single metric over several years'). It also states the concrete outputs (company series, peer series, industry distribution), making it clearly distinguishable from siblings like get_financials or get_ranking.

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 for when to use it: when a single company's numbers cannot answer 'is this good?' it provides relative benchmarking against peers. It does not explicitly name alternative tools or state when not to use it, but the phrase 'which a single company's numbers alone cannot' implies the contrast with standalone financial data tools.

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?

With no annotations provided, the description carries the full burden, and it does disclose the key behavioral scope: it returns a single company's profile and only the most recent reported financial summary. It does not overpromise historical or exhaustive financial detail, though it could mention response-size constraints or error handling.

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 carry the full message with no wasted words, front-loading the main purpose and then immediately routing to the relevant sibling. The profile contents are itemized compactly and the alternative tool is named explicitly.

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 single-company read tool, the description sets accurate expectations about the returned data even without an output schema. It names the main sibling to avoid confusion, and the schema handles parameter details, though it does not cover every edge case such as invalid codes or omitted fields.

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%, thoroughly documenting both code and fields, so the baseline is 3. The description adds context about what the returned profile contains, but it does not add parameter-level semantics beyond the schema's already-rich details.

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 verb and resource ('Get the full profile of one company') and enumerates the payload contents: identifiers, industry, market segment, headcount, and recent financial summary. It also explicitly distinguishes itself from get_financials by labeling itself the general 'tell me about this company' tool.

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 clearly states when to use this tool — as the general company-profile tool — and gives a direct alternative with the condition: 'for a multi-year numeric series use get_financials.' This gives an agent a concrete routing decision without inferring from context.

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?

No annotations are provided, so the description carries the burden of disclosing behavior. It conveys that this is a read-only operation ('Get'), indicates the data source ('disclosed by one company'), and itemizes returned fields. It does not mention edge cases or access constraints, but for a straightforward retrieval tool the main behavioral expectations are covered.

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 two sentences with no wasted words: the first sentence front-loads the verb and resource, then adds payload detail; the second sentence states the use case. Every clause earns its place.

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 tool with only 2 parameters (1 required), no output schema, and no annotations, the description plus schema is largely sufficient: required identifier resolution, optional fiscal_year behavior, output fields, and main use case are all covered. An explicit pointer to relevant siblings would improve completeness, but it is not essential for a correct call.

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 100%, with detailed parameter descriptions including EDINET code examples, the distinction from securities codes, the resolution step, and the fiscal_year default behavior. The description itself adds no parameter-specific detail, so a baseline score of 3 is appropriate.

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 uses a specific verb ('Get'), names the resource ('board roster disclosed by one company'), and enumerates the returned entities ('each director and corporate auditor') with their attributes. This clearly distinguishes it from sibling tools like get_shareholders, which would return ownership data rather than board composition.

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 states the intended use case ('Answers governance and board-composition questions'), and the schema's code parameter explains that a name or securities code must first be resolved via search_companies. It does not explicitly name alternatives or state when not to use the tool, but the context is reasonably clear.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states that the tool returns filing metadata (dates and types) rather than narrative content, which prevents misuse. It does not mention pagination, result limits, or ordering, but for a read-only listing tool the core behavior is transparent.

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 two sentences with no waste. The first sentence front-loads the action, resource, and output fields; the second sentence adds the usage distinction and the alternative tool. Every word earns its place.

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?

The schema fully documents all five parameters, and the description states the return fields and the intended use case while naming the relevant sibling tool. There is no output schema, but the description names the key returned attributes. The only notable gap is the absence of pagination or result-limit behavior, which would be useful but is not critical for this simple list operation.

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 100%, and the param descriptions already provide strong guidance: EDINET code examples, clear date formats, and comma-separated type filter semantics. The description itself adds no deeper parameter meaning beyond 'given period' and document types, so the baseline of 3 applies.

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 uses a specific verb ('List') and a specific resource ('regulatory documents one company filed in a given period'), and it names the key output fields ('filing dates and document types'). It also clearly separates this tool from get_text_blocks, which is pointed to for narrative filing content.

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 explicitly frames when to use this tool: to answer 'what did they file and when', and directs the agent to get_text_blocks for reading narrative content. The schema additionally instructs the agent to resolve a name or securities code with search_companies first, giving a complete usage path.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully discloses ordering ('newest first'), content (reported results and forecast), and timing relative to annual reports. However, it does not mention output format, pagination behavior, or any operational constraints such as rate limits or authentication, leaving some behavioral uncertainty for a read tool without annotation support.

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 two sentences with no wasted words. The first sentence states what the tool does and its output ordering; the second sentence provides timing context and the sibling alternative. Information is front-loaded and every clause earns its place.

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 tool with no output schema, the description offers some return-value context by mentioning that results include reported figures and management forecasts, plus ordering. It does not describe the exact response shape, but the simple list semantics and well-documented parameters make this a minor gap. Overall it is reasonably complete for selecting and invoking the tool.

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 100%, so all parameters are already documented in the input schema. The description adds no parameter-level detail beyond the schema. Per the baseline rule, a score of 3 is appropriate since the schema carries the parameter documentation burden.

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 opens with a specific verb and resource ('Get a company's quarterly earnings releases'), and specifies ordering ('newest first') and content ('reported results and management's own forecast'). It also distinguishes itself from the sibling get_financials by noting that earnings releases arrive before the annual report. This is a clear, differentiating statement.

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 explicitly states when to use this tool: 'use this for the latest numbers' because earnings releases arrive weeks before the annual report. It also names the alternative, get_financials, for the 'audited long-run series'. This gives an agent an actionable decision rule.

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?

With no annotations provided, the description carries the behavioral burden and does meaningful work: it states the data source ('XBRL in the company's own regulatory filings') and explicitly guarantees no language model is involved in producing figures. This gives the agent confidence about provenance, though it does not describe output structure or failure behavior.

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 two sentences with no wasted words. The first sentence front-loads the action, scope, and content; the second adds valuable provenance context. Both sentences earn their place.

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 there is no output schema, the description compensates by listing the key line items and stating the time-series nature. It does not detail row layout or units, but the information is sufficient for an agent to invoke the tool correctly and set expectations for the response.

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 100%, and the schema already explains `code`, `years`, and `period` in detail, including the EDINET-code caveat and period meanings. The description adds no parameter-level meaning beyond framing the result as a per-period time series, so baseline 3 is appropriate.

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 uses a specific verb ('Get') with a clear resource ('multi-year financial statement time series') and scope ('for one company'), and it lists the exact metrics returned. This makes it easy to distinguish from siblings like get_earnings or get_segments without opening their schemas.

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 makes it clear this is for retrieving broad financial-statement time series for a single company, which gives the agent useful context for when to select it. It does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.

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?

No annotations are present, so the description carries the full burden. It conveys read-only intent via 'Get', market-wide scope, and ranking order via 'top companies', but it does not describe response shape, ordering direction nuances, or why some metrics might be better when ranked lower (e.g., emissions). A 3 is appropriate: useful but not deeply transparent.

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 with no filler. The core purpose is front-loaded, and the usage guidance is delivered in a compact second sentence.

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?

The tool is simple: one required enum parameter plus one optional limit. The description adequately covers purpose, scope, and alternative routing. Since there is no output schema, a brief mention of what a league-table row contains would improve completeness, but the current wording is enough for an agent to invoke the tool correctly.

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%, so the baseline is 3. The description adds value by mapping several cryptic enum values to human-readable concepts ('return on equity', 'market capitalisation', 'dividend yield', 'female director ratio') and clarifying the one-metric constraint. It does not decode all enum values, but the added semantics exceed the schema's generic parameter descriptions.

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?

States a specific verb ('Get') and resource ('market-wide league table') with a clear scope ('one metric'), and distinguishes itself from siblings by explicitly contrasting with screen_companies. The examples of metrics make the ranking purpose unmistakable.

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?

Explicitly says when to use the tool: 'who is highest on X'. Also gives a concrete when-not-to-use directive: 'use screen_companies when you need several conditions at once'. This is a clear usage rule with a named alternative.

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?

No annotations are provided, so the description must carry the burden. It communicates the read-only retrieval nature and the metric list, but does not disclose output structure, pagination, or behavior for companies without segment disclosures. This is adequate but not rich.

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 with no filler: the first states the resource and output metrics, the second gives the strategic use case and the key sibling distinction. The most decision-relevant information is front-loaded.

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 read-only retrieval tool with detailed schema documentation, the description plus schema covers the EDINET code prerequisite, period/quarter/fiscal year semantics, and the key alternative. Without an output schema, it does not specify the exact response shape, but the listed metrics make the main result clear enough.

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 100%, so the baseline is 3. The schema fully documents all four parameters and their constraints, including code conversion guidance and quarter validity, so the description does not need to add parameter detail.

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 opens with a specific verb and resource ('Get the reported business-segment breakdown for one company') and enumerates concrete fields returned. It also distinguishes itself from get_financials by noting consolidated totals cannot show segment-level profitability, so an agent can tell them apart.

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 explicitly says to use it when the task is seeing which part of a business earns money, and contrasts with get_financials. The schema's code description adds a clear prerequisite: resolve names/securities codes to EDINET codes via search_companies first.

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?

With no annotations provided, the description carries the burden of disclosing behavior. It usefully explains what kind of data is returned (5%+ stake reports, ratio, as-of date) and that this is the issuer-side filing view. However, it does not mention whether the result is a list, how the data is ordered, or any pagination or time-range limitations, leaving some behavioral ambiguity for an AI agent.

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 tightly written sentences deliver the core purpose, the threshold, the data content, and the sibling distinction. The most important scoping information is front-loaded in the first sentence, and every clause adds value with no filler.

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 low complexity of a single-parameter getter, the description is nearly complete: it tells the agent what will be returned, what threshold applies, and how this differs from search_shareholders. The absence of an output schema and annotations means some return-format specifics are not covered, but they are minor for this tool's simple usage.

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 already documents the single parameter very well, including that it requires an EDINET code, provides concrete examples, notes that it is not a securities code, and points to search_companies for resolution. Since schema description coverage is 100%, the tool description itself adds little new parameter-level meaning beyond tying the code to a single company context.

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 and resource: retrieving large-shareholding reports for a company, with the 5% threshold and key data points (ratio and date). It explicitly distinguishes itself from its sibling search_shareholders by framing this as the issuer-side view, so there is no ambiguity about scope.

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 clearly explains when to use this tool versus search_shareholders: use it to see all declared stakes against one company, and use search_shareholders to see everything one investor holds. The parameter description adds a concrete prerequisite: resolve names or securities codes to an EDINET code with search_companies first.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It clearly discloses the 2,000-character excerpt behavior, the per-section return shape, and the Japanese-language nature of the content — non-obvious traits an agent needs. It does not discuss rate limits or error behavior, but for a read operation this is reasonably complete.

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 efficient sentences deliver the core purpose, the content scope, and the key output behavior. Every clause earns its place, and the most important detail — what the tool reads — is front-loaded.

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 moderately complex read tool with no output schema, the description explains the expected return value and format sufficiently. The remaining gaps, such as exact response structure or behavior for missing years, are minor and partially covered by the parameter schemas.

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 100%, so the parameters are already fully documented. The description adds marginal context by listing section names in prose, but does not materially extend the schema's meaning for full, sections, or fiscal_year.

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 verb ('Read'), a specific resource ('narrative sections of a company's annual securities report'), and enumerates the exact sections covered. This clearly distinguishes it from sibling tools like get_financials or get_disclosures.

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 when the tool is appropriate — when narrative annual-report text is needed — but does not explicitly contrast it with alternatives or state when not to use it. The 'original filed Japanese text' detail is a useful implicit signal, but no explicit routing guidance is given.

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?

No annotations are provided, so the description must carry behavioral disclosure on its own. It usefully reveals that filters combine with AND, apply across the entire listed-company universe, and surviving companies are sorted. However, it does not disclose the result shape, behavior with no conditions, or pagination expectations beyond what the schema already exposes.

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 with no filler. The first sentence states the core operation, scope, filtering semantics, and sorting; the second provides the sibling distinction. Every clause adds information.

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 9-parameter tool with no output schema, the description covers the purpose, when to use it, and the key AND-combination semantics, while the schema covers parameter details. The main gap is that the return contents are only implied by 'survivors' rather than described, and no caveats or prerequisites are mentioned.

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 already documents all 9 parameters with 100% coverage, so the baseline is 3. The description adds a meaningful semantic not explicit in the schema: numeric and categorical criteria are combined with AND. This helps an agent correctly model how the various filter fields interact.

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 and resource: filtering the whole universe of Japanese listed companies by numeric and categorical criteria, AND-combining them, then sorting survivors. It explicitly contrasts this with search_companies, so an agent can distinguish screening-by-profile from lookup-by-known-company.

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 gives an explicit when-to-use rule: use screen_companies when looking for companies that match a profile, and use search_companies when you already know the company. This is direct routing guidance between the two closest siblings, though it does not discuss other siblings like get_ranking.

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?

No annotations are provided, so the description carries the full burden. It clarifies the lookup behavior and that the result includes an EDINET code, but it does not disclose matching behavior, read-only guarantees, or response shape. This is a moderate gap for an otherwise simple search 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?

Three concise sentences with no wasted words. The main purpose is front-loaded, followed immediately by usage guidance and the key alternative tool.

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 3-parameter search tool with fully documented schema, the description is nearly complete: it explains what to do, when to do it, and which sibling to prefer instead. It stops short of describing the exact output structure, but it does say a company record is returned.

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 100%, so the schema already fully documents q, limit, and include_delisted. The description adds context about needing the EDINET code for other tools, but it does not materially enhance parameter understanding 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 uses a specific verb ('Resolve') and names the resource: company name, EDINET code, or securities code to a company record. It also differentiates from screen_companies by stating this tool is for when you know WHO you are looking for.

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?

Explicitly states when to use this tool ('Use this first when you know WHO...') and names the alternative ('use screen_companies instead') for a distinct case. No inference is needed.

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?

No annotations are provided, so the description must carry the behavioral disclosure. It clearly communicates that the operation is a lookup/search of filing relationships, but it does not mention pagination, default result count, or any output structure. Core behavior is present; depth is minimal.

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 with the core action in the first sentence and the key differentiator in the second. No filler or redundant restatement.

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?

Simple 2-parameter tool with fully documented schema and a clear relationship to its sibling. The description covers the main concept and reverse relationship; only a return-shape note would make it fully complete, but this is a minor gap.

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 100%, with q and limit already documented including example and default. The description adds no new parameter meaning beyond the schema, so baseline 3 applies.

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?

States a specific verb ('Look up'), the resource (investor by name), and the outcome (every listed company with a large-shareholding filing). It also names the sibling it is the reverse of, so it is immediately distinguishable from get_shareholders.

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?

Explicitly frames the tool as the reverse of get_shareholders and tells the agent to start from the holder rather than the issuer. This is a clear when-to-use signal and references the main alternative.

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