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

With no annotations, the description carries the full burden. It usefully discloses that the call consumes 0 credits (a real behavioral trait) and that the operation is a read, but says nothing about authentication, rate limits, or whether the expiry list is paginated or truncated.

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 front-loaded sentence naming the returned data, with the cost note tucked into a parenthetical. Every element earns its place and nothing is redundant.

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 read with no output schema, the description adequately conveys both the return content (balance plus lot expiration list) and the cost. It is only slightly incomplete in not hinting at response shape or freshness of the balance data.

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; no compensation is 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 states a specific verb (取得) and two concrete resources (現在のクレジット残高 and ロットの有効期限一覧), so an agent knows exactly what it returns. The sibling tools are all company-search oriented, so there is no ambiguity to disambiguate.

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?

Usage is only implied — an agent infers it should call this when it needs credit/expiry information, but there is no explicit when-to-use, prerequisite, or alternative stated. The '(消費クレジット: 0)' note is a useful cost hint but does not constitute 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 provided, so the description carries the full burden. It usefully discloses the credit cost model ('1 credit per column') and a constraint on redundant field requests, but says nothing about auth needs, rate limits, error behavior, or what the response 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?

Two short sentences with the core purpose front-loaded and the cost/constraint note following. Efficient, though the parenthetical cost formula is somewhat dense.

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, an agent gets purpose, input shape, and cost behavior but no sense of the returned payload's structure or size limits. Adequate for a simple 2-parameter lookup, but not thorough.

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 both parameters (code, fields) are already documented, including the default and the credit-cost note on fields. The description largely reiterates the schema's cost statement rather than adding new format or syntax detail — 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?

States a specific verb and resource: retrieve detailed information for one company by stock code. This clearly separates it from search_companies and resolve_company by scope (single-company detail lookup), though it never names a sibling explicitly.

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?

Adds a real usage rule — don't request columns you already have — which is a cost-motivated constraint rather than a when-to-use-vs-alternative directive. It does not say when to prefer this tool over resolve_company or search_companies, so guidance is implied at best.

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, the description carries the full behavioral burden. It does add genuinely useful context the schema lacks: credit consumption of one credit per returned row. However, it omits auth requirements, whether deletions are included, pagination/ordering behavior, and what the returned history 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 front-loaded sentence giving purpose followed by the cost model. No filler, no repetition of the name, and every clause carries 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?

No output schema exists, so the description should ideally outline what the change history contains, but it only covers purpose and cost. For a read tool with three parameters and zero annotations, this is adequate but leaves notable gaps about the returned data and access requirements.

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 three parameters (limit, since, column) are already documented in the schema. The description adds no syntax or format detail about them, so the 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?

The description states a specific verb+resource: retrieving the data change history for a given point in time onward. The purpose is unambiguous and clearly distinct from the company/balance-oriented siblings. It does not, however, explicitly name or differentiate itself from any alternative 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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The phrase 'since a specified point in time' only implicitly suggests change-tracking use, which is too thin to count as 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?

With no annotations provided, the description carries the full behavioral burden. It usefully discloses the operation's cost ('消費クレジット: 0', i.e. a free call) and describes what is returned, but it never states the read-only, side-effect-free nature of the operation explicitly.

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 front-loaded sentence that names the resource first and appends the cost note. Every element earns its place with 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 zero-parameter listing tool with no output schema, the description adequately enumerates the returned content (columns, unit prices, source info). It is nearly complete, with only the return structure/shape left unspecified.

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 schema or description to document; the baseline of 4 for a parameterless tool applies. No parameter semantics are needed or missing.

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 (取得します/retrieve) and concrete resources: available columns, unit prices, and data source information. The purpose is unambiguous, though it offers no explicit differentiation from the company-oriented siblings (search_companies, get_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?

Usage is only implied – an agent can infer this is the discovery tool for learning what fields exist before searching, but the description never says when to reach for it versus the sibling company tools or what to do with the result. No exclusions or alternatives are named.

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 does add real behavioral context beyond the schema: a cost disclosure (1 credit, 0 when no hits) and the fact that only the single top-ranked match is returned. It omits auth requirements, error/ambiguity behavior, and what '照合情報' actually 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 front-loaded sentence pairing the action with its return values, with the cost note compactly parenthesized. No filler, though the parenthetical slightly interrupts the primary statement.

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 one-parameter tool with no output schema, the description helpfully enumerates the returned fields (code, name, match info) and the credit cost. Only the resolution semantics for ambiguous queries remain unaddressed.

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 there is only one parameter, whose schema text ('検索クエリ (社名または別名)') already matches the description's '社名や別名'. The description adds no syntax, aliasing, or normalization guidance, so the 3 baseline 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 (特定) and resource (社名や別名→最上位1社) plus the return payload (コード・名前・照合情報). The '最上位1社' scoping implicitly separates it from search_companies, but it never names a sibling, so it stops short of full differentiation.

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?

Usage is only implied: call this when you have a name/alias and want a single resolved company. There is no explicit when-not, no mention of search_companies for multi-result lookups, and no stated alternative for exact-vs-fuzzy matching.

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 behavioral burden. It usefully discloses credit cost (1 per call, 0 when there are no results) and the key restriction that only attribute columns are retrievable, but says nothing about return shape, pagination, or the result limit behavior (max 5).

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 short, front-loaded sentences with the purpose first, then cost, then the field constraint. No filler or redundancy within the text itself.

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 10-parameter search tool with no annotations and no output schema, the description covers purpose, cost, and a field constraint but leaves the result format, the hard 5-item cap context, and sibling routing unaddressed. Adequate but with visible gaps.

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 10 parameters are already documented in the schema. The description's field-related constraints ('only attribute columns', 'don't request columns you already have') largely duplicate the fields parameter's own schema description, so it adds little beyond the structured data.

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+resource: searching a list of company candidates by company name or alias. An agent can identify the operation, though the description does not explicitly name the sibling (get_company/resolve_company) it contrasts with — that routing hint only appears in the schema's fields description.

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?

Gives one real usage rule ('don't request columns you already have'), which is genuinely actionable, but offers no guidance on when to choose this over resolve_company or get_company, nor any prerequisite conditions.

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