Japanese EDINET XBRL facts: bilingual labels, financials, screening. No prices. Signup required.
Scored across 17 tools
Most tools target clearly distinct resources or actions (search vs. screen vs. profile vs. statements vs. segments vs. shareholders), so an agent can usually pick correctly. The main soft spots are get_company_financials versus get_financial_facts (multi-period grouped statements vs. raw per-filing XBRL facts) and get_document_summary versus analyze_document (pre-baked summary vs. free-form Q&A), which require reading descriptions to separate.
Every tool follows a consistent snake_case verb_noun pattern: get_*, list_*, search_*, screen_*, compare_*, analyze_*, report_*. No camelCase or bare-noun outliers, so the naming is fully predictable.
At 17 tools the set is slightly heavy but each entry corresponds to a genuinely different access path (screening, search, per-company profile, statements, raw facts, segments, filings, shareholders, industry stats, quota, issue reporting). Nothing looks redundant enough to be a filler tool, though a few retrieval modes could plausibly be consolidated.
The surface covers discovery (search/screen/list_industries), per-company data (profile, financials, facts, segments, calculation tree, filings, shareholders), cross-company comparison, document Q&A, plus quota and error reporting — a strong lifecycle. Minor gaps are the absence of any tool for retrieving raw filing text/passages (only AI summary and Q&A cover narrative content) and no multi-period or time-series comparison beyond the single compare_companies call.
Ask a specific question about a Japanese financial document (annual report, earnings release, etc.) from EDINET and receive an AI-generated answer. Source: EDINET (https://disclosure2.edinet-fsa.go.jp/), PDL 1.0 (https://www.digital.go.jp/resources/open_data/public_data_license_v1.0). Data is processed by Kabuken, not raw unprocessed FSA data. Output is AI-generated by Kabuken from EDINET filings and may contain errors; not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | EDINET document identifier (e.g. S100ABCD) | |
| language | No | Response language: 'JA' (default) or 'EN' | |
| question | Yes | Question to answer about the document (max 1000 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds useful caveats beyond annotations: the answer is AI-generated, may contain errors, is processed by Kabuken rather than raw FSA data, and is not investment advice.
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 purpose is front-loaded, but the description includes licensing URLs and legal boilerplate that are not essential for tool selection or invocation. It is reasonably structured but could be tighter.
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 three-parameter QA tool with no output schema, the description adequately explains the source, the AI-generated nature of the answer, and important limitations. It could say more about answer format or length, but the core context is present.
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 are already documented in the input schema. The description does not add parameter-specific meaning beyond what the schema provides, which is acceptable at baseline 3.
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: ask a question about a Japanese financial document from EDINET and receive an AI-generated answer. It is clear what the tool does, but it does not explicitly distinguish itself from siblings like get_document_summary or get_financial_facts.
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 by saying to ask a specific question about a document, but it never states when to choose this tool over alternatives such as get_document_summary or get_financial_facts. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare key financial metrics across 2–5 Japanese listed companies using their latest annual securities report (有価証券報告書) filings. Returns a matrix of revenue, net income, total assets, equity, operating income, and period_end so mismatched fiscal year-ends are visible. Every value is a CONSOLIDATED figure for that filing's own period: non-consolidated (parent-only) and segment-dimensional values are never reported or substituted, so peer rows are always like-for-like. Concept matching reaches per-company taxonomy extensions and the five-year 主要な経営指標等の推移 (SummaryOfBusinessResults) families as well as the standard JP-GAAP, IFRS and US-GAAP concepts, so filers whose consolidated statements use no standard concept are still comparable. A metric with no consolidated current-period fact is null and carries an omission_reason (no_consolidated_context, no_current_period_fact, reported_nil, no_numeric_value, owners_equity_not_established, not_applicable_to_statement_format, no_total_concept_in_format, concept_absent) in the per-company metrics object, which also exposes each metric's own concept_id, context_ref and resolved period — the latter can differ from the row's period_end, which is the document's. Equity is always equity attributable to owners of the parent. J-GAAP filers report no single concept for it, so it is DERIVED as the owner components (株主資本 + 評価・換算差額等) of 純資産, checked to reconcile with the reported total: a derived metric carries derived: true, concept_id null, and a derivation object listing the reconciled_against total (which includes non-controlling interests and is NOT the value) and every component with its role (owner or non_owner), value and context_ref. Metrics read from a single fact carry neither field. Every metric also carries unit and decimals (the XBRL unit and precision of the value). Revenue does NOT always mean net sales. A resolved revenue metric carries basis and basis_label (en/ja); basis_label states the meaning, which can differ from the concept name and its taxonomy label. net_sales: 売上高 / revenue of a general filer. operating_revenue: 営業収益 of a general filer. ordinary_revenue_bank and ordinary_revenue_insurance: 経常収益, the GROSS top line of a Japanese-GAAP bank or insurer (interest, fees, premiums, investment revenue). It is revenue, NOT profit, even though its concept is named OrdinaryIncome... and EDINET's English label says 'Ordinary income'; 経常利益 (ordinary profit) is a different line and is never reported as revenue. operating_revenue_securities: gross 営業収益 of a securities firm, before 金融費用. operating_revenue_finance: 営業収益 of a finance, commodity-futures, investment-management or construction-guarantee filer. insurance_revenue_ifrs: IFRS 17 insurance revenue of an IFRS insurer, which excludes investment and other revenue. revenue_financial_filer_unverified: a bank, insurer or securities firm not filing Japanese GAAP whose revenue line's meaning is not established; it is not comparable with net sales. statement_format reports the EDINET industry format (general, bank, insurance, insurance_life, insurance_nonlife, securities, ...), the DEI industry code and accounting standard as filed. operating_margin_denominator is the figure operating margin must divide by: the revenue metric for most filers, but 純営業収益 (basis net_operating_revenue_securities) for a securities firm, whose gross revenue includes interest later deducted as 金融費用. Omission reason not_applicable_to_statement_format: the filing's format has no such line (a Japanese-GAAP bank or insurer has no operating income, current assets or current liabilities, so no operating margin or current ratio); no other subtotal is substituted, and it is not missing data. no_total_concept_in_format: the format tags only component lines for the metric and the filer reported no total. Source: EDINET (https://disclosure2.edinet-fsa.go.jp/), PDL 1.0 (https://www.digital.go.jp/resources/open_data/public_data_license_v1.0). Data is processed by Kabuken, not raw unprocessed FSA data. Figures are calculated by Kabuken from EDINET filings, not reported directly by EDINET. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_codes | Yes | List of 2 to 5 EDINET entity codes to compare (e.g. ['E02144', 'E00076']). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, and destructiveHint, but the description adds extensive behavioral context: null handling with omission_reason values, derivation of equity for J-GAAP filers, revenue basis distinctions, omission reasons like not_applicable_to_statement_format, and data provenance. This goes far beyond what annotations cover.
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 extremely long and dense, forming a single paragraph with many nested details. While the purpose is front-loaded, the remainder is a wall of text that could be organized into clearer sections, making it hard to scan and absorb quickly.
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?
Despite the lack of an output schema, the description thoroughly explains return values (matrix of metrics, period_end, per-company metrics object with concept_id, context_ref, derived fields, omission_reason), revenue basis labels, and data limitations. It is complete for a complex financial comparison 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?
Only one parameter (entity_codes) exists and the schema description coverage is 100%, fully documenting it as a list of 2–5 EDINET entity codes. The description adds no additional semantics about the parameter, so the baseline 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 states a specific verb (Compare) and resource (key financial metrics across 2–5 Japanese listed companies) using latest annual securities report filings. It clearly distinguishes itself from single-company tools like get_company_financials by emphasizing comparison across multiple entities and the matrix return format.
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 purpose implies when to use the tool (multi-company comparison), but it never explicitly states when to choose this over siblings such as get_company_financials or screen_companies. No exclusions or alternative conditions are provided, leaving usage inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the caller's current daily usage: calls used today, daily limit, remaining calls, and the reset time (reset_at, UTC). Some accounts also get a free_facts block with the daily count for fact lookups. This call is self-exempt: it does not consume or count toward the daily tool-call quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds substantive behavior beyond that: it specifies the exact quota fields returned, notes that reset_at is UTC, mentions that some accounts receive a free_facts block, and clarifies that this call does not count toward the quota.
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 three sentences and is front-loaded with what the tool returns, followed by the optional free_facts detail and the self-exemption caveat. Every sentence contributes useful 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 zero-parameter, read-only quota-check tool with no output schema, the description provides enough detail about what is returned, the reset time semantics, optional account-specific data, and the quota exemption. Nothing an agent needs in order to call it correctly 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?
There are zero input parameters, so parameter semantics are inherently minimal and the baseline is 4. The description usefully explains the return fields even though there is no output schema, but it does not need to clarify input parameters.
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 — returning the caller's current daily usage — and enumerates the exact fields returned (calls used today, daily limit, remaining calls, reset_at, and optional free_facts). It is immediately distinguishable from all sibling tools, which are financial/document analysis tools rather than quota 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?
The description makes clear this is for checking current daily usage and that the call is self-exempt from quota consumption, which is useful usage context. It does not explicitly say when not to use it or name alternatives, but there are no comparable sibling tools for account quota.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the income flow (P&L structure, 損益の流れ, 収益構造, 損益計算書の構造) of one filing: revenue and other income, each cost line and the net result, with amounts, shown as a diagram where the client supports it. Also returns the XBRL calculation linkbase as a tree (e.g. TotalAssets = CurrentAssets + NonCurrentAssets). Source: EDINET (https://disclosure2.edinet-fsa.go.jp/), PDL 1.0 (https://www.digital.go.jp/resources/open_data/public_data_license_v1.0). Data is processed by Kabuken, not raw unprocessed FSA data. Includes EDINET Taxonomy content, excluded from PDL 1.0 and separately licensed (https://www.fsa.go.jp/search/EDINET_Taxonomy_Legal_Statement.html). © Copyright 2014 Financial Services Agency, The Japanese Government. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the user's request: en or ja. Sets the language of the diagram and of the amounts summary. | |
| limit | No | Maximum number of calculation arcs to process (1-500, default 200) | |
| doc_id | Yes | EDINET document ID, e.g. S100ABCD | |
| root_concept | No | Optional XBRL concept name to use as the root of the subtree (e.g. 'jppfs_cor:Assets'). If omitted, all root nodes are returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: output is a diagram where the client supports it, the data is Kabuken-processed rather than raw FSA data, and taxonomy content carries a separate license. It omits behavior that matters for calling it, such as what happens at the limit boundary (truncation vs. error) or the response shape.
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 functional sentence is front-loaded, but it is followed by a parenthetical list of four near-synonyms (P&L structure, 損益の流れ, 収益構造, 損益計算書の構造) and then a long licensing/copyright block with URLs. The legal notice may be required, but it crowds out operational information within a single dense paragraph.
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 must characterize the return value, and it does so partially (diagram plus linkbase tree with an example arc). However, for a tool that returns a potentially large calculation tree governed by a limit parameter, the description never explains truncation, ordering, or what the amounts summary looks like.
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 four parameters (doc_id, lang, limit, root_concept) are already documented in the schema, including the root-node-default behavior. The description adds no parameter-level detail beyond what the schema provides, 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?
States a specific verb and resource: 'Returns the income flow ... of one filing' with concrete contents (revenue, cost lines, net result) and adds a second output, the XBRL calculation linkbase as a tree. The purpose is legible, but the two outputs (P&L flow vs. generic calculation tree) are blended into one sentence and no sibling tool is named to anchor the distinction.
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?
'of one filing' and the existence of root_concept imply per-document structural drill-down, but there is no explicit when-to-use or when-not guidance. Nothing tells the agent why it would pick this over get_financial_facts, get_segment_breakdown, or analyze_document for the same document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the profile of one Japanese listed company (names, entity code, ticker, industry) by any identifier. Returns bilingual names, entity code (for EDINET lookups), ticker, and industry.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Company identifier value, interpreted according to id_type | |
| id_type | No | Type of identifier: entity_code | ticker | name | simple_name (default: entity_code) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful domain context (bilingual names, EDINET entity codes) but says nothing about error/not-found behavior or whether results are cached or sourced from EDINET.
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, and the second largely repeats the first's field list (names, entity code, ticker, industry). The EDINET hint is the only new information in sentence two, so the definition is roughly 40% 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?
With no output schema, the description does the right job of enumerating return fields and noting bilingual output. Only gap is failure modes and how lookups resolve ambiguous names (e.g., 'name' vs 'simple_name').
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 id_type enum values are fully documented in the schema, so this is baseline 3. The description's 'by any identifier' and the EDINET note add only marginal 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?
States a specific verb and resource ('Return the profile of one Japanese listed company') and names the fields returned. It implicitly separates a single-profile lookup from sibling search/screen tools by emphasizing 'one' company, but never names an alternative 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?
The phrase 'by any identifier' hints at flexible input, but there is no explicit when-to-use guidance, no mention of when to use search_companies or screen_companies instead, and no note on what happens if the company is not found.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return multi-period financial statements (income statement, balance sheet, cash flow) and headline figures such as revenue and net income for a Japanese listed company from its EDINET/XBRL filings. Groups facts by statement type across annual and interim periods. Each period also carries a key_metrics object holding the eight headline figures (revenue, operating_income, net_income, total_assets, equity, current_assets, current_liabilities, total_liabilities), each with its value, concept_id, context_ref and resolved period. key_metrics holds the headline figures: the statement buckets are keyed on the filing's statement-type tagging, and many filers — including those using per-company taxonomy extensions or the five-year 主要な経営指標等の推移 (SummaryOfBusinessResults) concepts — report their consolidated top line outside those buckets, where it would otherwise not appear. Values are CONSOLIDATED figures for the filing period only: non-consolidated (parent-only), segment-dimensional and prior-period values are never reported or substituted, EXCEPT for a filer whose DEI declares (or, absent that DEI element, has) no consolidated statements at all, whose non-consolidated (単体) figures ARE its own figures; every metric with a value carries consolidation_basis (consolidated or non_consolidated) so this is always explicit, never silent. A key metric with no consolidated current-period fact is null and carries an omission_reason (no_consolidated_context, no_current_period_fact, reported_nil, no_numeric_value, owners_equity_not_established, not_applicable_to_statement_format, no_total_concept_in_format, concept_absent); Equity is always equity attributable to owners of the parent. J-GAAP filers report no single concept for it, so it is DERIVED as the owner components (株主資本 + 評価・換算差額等) of 純資産, checked to reconcile with the reported total: a derived metric carries derived: true, concept_id null, and a derivation object listing the reconciled_against total (which includes non-controlling interests and is NOT the value) and every component with its role (owner or non_owner), value, context_ref Metrics read from a single fact carry neither field. Every metric also carries unit and decimals (the XBRL unit and precision of the value). Statement-bucket concepts with no consolidated current-period value are listed in that period's omitted_concepts. Revenue does NOT always mean net sales. A resolved revenue metric carries basis and basis_label (en/ja); basis_label states the meaning, which can differ from the concept name and its taxonomy label. net_sales: 売上高 / revenue of a general filer. operating_revenue: 営業収益 of a general filer. ordinary_revenue_bank and ordinary_revenue_insurance: 経常収益, the GROSS top line of a Japanese-GAAP bank or insurer (interest, fees, premiums, investment revenue). It is revenue, NOT profit, even though its concept is named OrdinaryIncome... and EDINET's English label says 'Ordinary income'; 経常利益 (ordinary profit) is a different line and is never reported as revenue. operating_revenue_securities: gross 営業収益 of a securities firm, before 金融費用. operating_revenue_finance: 営業収益 of a finance, commodity-futures, investment-management or construction-guarantee filer. insurance_revenue_ifrs: IFRS 17 insurance revenue of an IFRS insurer, which excludes investment and other revenue. revenue_financial_filer_unverified: a bank, insurer or securities firm not filing Japanese GAAP whose revenue line's meaning is not established; it is not comparable with net sales. statement_format reports the EDINET industry format (general, bank, insurance, insurance_life, insurance_nonlife, securities, ...), the DEI industry code and accounting standard as filed. operating_margin_denominator is the figure operating margin must divide by: the revenue metric for most filers, but 純営業収益 (basis net_operating_revenue_securities) for a securities firm, whose gross revenue includes interest later deducted as 金融費用. Omission reason not_applicable_to_statement_format: the filing's format has no such line (a Japanese-GAAP bank or insurer has no operating income, current assets or current liabilities, so no operating margin or current ratio); no other subtotal is substituted, and it is not missing data. no_total_concept_in_format: the format tags only component lines for the metric and the filer reported no total. Source: EDINET (https://disclosure2.edinet-fsa.go.jp/), PDL 1.0 (https://www.digital.go.jp/resources/open_data/public_data_license_v1.0). Data is processed by Kabuken, not raw unprocessed FSA data. Figures are calculated by Kabuken from EDINET filings, not reported directly by EDINET. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| periods | No | Number of most recent filing periods to return (1–20, default 3; values below 1 are treated as 1). The response reports periods_requested and periods_returned; periods_returned is lower when fewer filings are available. | |
| entity_code | Yes | EDINET entity code (e.g. "E02144" for Toyota). | |
| period_type | No | Filter by filing period type. ANNUAL = 有価証券報告書; INTERIM = semi-annual/quarterly; ALL = both. Default: ANNUAL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, the description discloses the critical behavioral traits an agent could not get elsewhere: consolidation basis is explicit per metric, non-consolidated figures are used only when the filer has no consolidated statements, omitted metrics carry enumerated omission_reason codes, and derived equity is flagged with derivation metadata. It also warns about semantic traps, such as 経常収益 being revenue rather than profit and 純営業収益 being the correct margin denominator for securities firms.
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 purpose is front-loaded in the first sentence, but the body is an extremely dense wall of run-on clauses covering revenue bases, derivation mechanics, omission codes, licensing and disclaimers. Much of this is relevant, but the lack of paragraphs or bullet structure makes it difficult to scan and pushes the description well past a reasonable size.
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 must carry the return-value burden, and it does: it explains period grouping, statement buckets, the eight key_metrics fields, omitted_concepts, consolidation_basis, derivation objects, and statement_format. Given the complexity of EDINET/XBRL data, this is essentially complete for correct interpretation of results.
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 three parameters are already fully documented. The description reinforces that results span annual and interim periods and multiple periods, but it adds no syntax or constraint detail beyond the schema's own defaults and enum definitions. 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 first sentence names the specific resource (multi-period financial statements for a Japanese listed company from EDINET/XBRL) and enumerates the statement types and headline figures, which is far clearer than a tautology. It does not explicitly contrast itself with siblings such as get_financial_facts or get_segment_breakdown, so an agent must infer the boundary rather than read it.
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 sentence telling the agent when to call this versus alternatives like get_financial_facts or compare_companies, nor any stated prerequisites. The context of retrieving EDINET financials is implied by the topic, but no routing guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve an AI-generated comprehensive summary of a Japanese financial document (annual report, earnings release, etc.) from EDINET. Source: EDINET (https://disclosure2.edinet-fsa.go.jp/), PDL 1.0 (https://www.digital.go.jp/resources/open_data/public_data_license_v1.0). Data is processed by Kabuken, not raw unprocessed FSA data. Output is AI-generated by Kabuken from EDINET filings and may contain errors; not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | EDINET document identifier (e.g. S100ABCD) | |
| language | No | Response language: 'JA' (default) or 'EN' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, closed-world operation. The description adds meaningful behavioral context beyond annotations: the summary is AI-generated, may contain errors, is processed by Kabuken rather than being raw FSA data, and is not investment advice.
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 core purpose is front-loaded and easy to find, but the description repeats EDINET and AI-generated provenance across multiple sentences and includes licensing URLs that do not help an agent select or invoke the tool. It is adequately structured but not maximally economical.
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 two-parameter tool with a fully documented schema and no output schema, the description is largely complete. It explains the provenance and caveats of the returned summary, though it could say more about the summary's expected form or coverage.
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 the doc_id and language parameters are already well documented in the schema. The description does not add syntax, format, or behavioral meaning for either parameter 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 states a specific verb and resource: retrieve an AI-generated comprehensive summary of a Japanese financial document from EDINET. It clarifies that the output is a processed summary rather than raw filings, which helps distinguish it from data-fetching siblings, but it does not explicitly name an 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?
The description gives no explicit guidance on when to use this tool versus alternatives such as analyze_document, get_financial_facts, or list_documents. The intended use is only implied by the fact that it returns a summary rather than raw data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the XBRL financial facts reported in one EDINET filing of a Japanese listed company. Returns structured financial data with bilingual labels. When two facts in the result share the same standard label, those facts also carry label_en_verbose and label_ja_verbose with the full taxonomy label. Source: EDINET (https://disclosure2.edinet-fsa.go.jp/), PDL 1.0 (https://www.digital.go.jp/resources/open_data/public_data_license_v1.0). Data is processed by Kabuken, not raw unprocessed FSA data. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of facts to return (1-500, default 100) | |
| cursor | No | Opaque next_cursor from the previous response; send it with the same doc_id, filters and limit to get the next page | |
| doc_id | Yes | EDINET document ID, e.g. S100ABCD | |
| concepts | No | Optional list of XBRL concept names (fact_name) to filter to (e.g. 'jppfs_cor:NetSales') | |
| statement_type | No | Optional filter by financial statement type (e.g. 'bs', 'pl', 'cf', 'ss') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, non-destructive, closed-world profile, so the description only needs to add context – and it does: source, license, the caveat that data is Kabuken-processed rather than raw FSA data, and the bilingual label behavior. It omits pagination behavior, but cursor/limit are documented in the schema.
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 core purpose and scope are front-loaded in the first sentence, followed by the label-behavior note. The licensing and disclaimer sentences are longer than needed for tool selection but are legitimate provenance/disclaimer content, so the definition stays reasonably efficient.
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 a fully documented schema and no output schema, the description covers provenance, label structure, and a partial picture of the return shape. It could say more about pagination and what a 'fact' record contains, but an agent has enough to call it 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 description coverage is 100%, so every parameter including the opaque cursor and concept filter is already explained. The description adds no syntax or semantic detail beyond the schema, which is acceptable at this coverage level but not value-adding.
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 ('Return the XBRL financial facts') plus the scope ('in one EDINET filing of a Japanese listed company'), which tells an agent exactly what data it yields. It does not explicitly distinguish itself from siblings like get_company_financials or get_calculation_tree, so the differentiation is implicit rather than stated.
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 never says when to choose this tool over get_company_financials, get_calculation_tree, or analyze_document, nor does it state any prerequisites or exclusions beyond the implied single-filing scope. Usage must be inferred from the scope phrase alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregated financial ratio statistics for all companies within a Japanese industry classification. Returns mean, median, and count per ratio, plus the top and bottom 3 companies by each ratio. Source: EDINET (https://disclosure2.edinet-fsa.go.jp/), PDL 1.0 (https://www.digital.go.jp/resources/open_data/public_data_license_v1.0). Data is processed by Kabuken, not raw unprocessed FSA data. Figures are calculated by Kabuken from EDINET filings, not reported directly by EDINET. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| industry_id | Yes | Industry ID, e.g. ind_3700. The bare industry code (3700) is also accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), but the description adds genuinely useful context: the data is Kabuken-derived rather than raw FSA filings, and the source/licensing is disclosed. The derived-data caveat is a real behavioral trait an agent would not otherwise know. It stops short of noting rate limits or response size.
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 lead sentence is well front-loaded and the return shape is stated early, but the provenance block is repetitive: 'processed by Kabuken, not raw unprocessed FSA data' is immediately restated as 'calculated by Kabuken from EDINET filings, not reported directly by EDINET.' Full license URLs consume space without aiding tool selection.
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 read tool with no output schema, the description covers purpose, output shape, provenance and licensing adequately. The remaining gap is operational: nothing tells the agent where industry_id values come from.
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 single industry_id parameter is documented with an example and the note that a bare code is accepted. The description adds nothing beyond the schema, which is the expected baseline for full coverage.
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, resource and scope: aggregated financial ratio statistics for all companies in a Japanese industry classification. It also spells out the shape of the result (mean, median, count plus top/bottom 3 per ratio). It does not explicitly contrast itself with siblings like compare_companies or screen_companies, so it is clear but not sibling-differentiating.
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 implied by the scope statement, but there is no explicit 'use this when' condition and no mention of list_industries as the way to obtain a valid industry_id. The agent must infer both the selection case and the prerequisite step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get risk context indicators for a Japanese listed company. Returns BOJ rate sensitivity and METI export control classification. Figures are calculated by Kabuken from EDINET filings, not reported directly by EDINET.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_code | Yes | EDINET entity code of the company (e.g. 'E02144'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious provenance: the figures are Kabuken-calculated from EDINET filings rather than reported directly, warning the agent that values are derived and may not match the source filing verbatim.
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 sentences, each earning its place: what it returns, then the provenance caveat. Front-loaded with purpose, no filler or repetition of the title.
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 must characterize return values and does so at the field level (BOJ rate sensitivity, METI export control classification). Minor gaps remain around empty/unknown results and whether coverage varies by company, but for a single-parameter read tool this is close to sufficient.
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 entity_code is documented with an example ('E02144'), so the schema carries parameter meaning. The description adds nothing further about the identifier format or what happens with an unknown code, 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 and resource ('Get risk context indicators for a Japanese listed company') and then concretizes the payload as BOJ rate sensitivity and METI export control classification. That content profile clearly separates it from siblings like get_company or get_company_financials, though no sibling is named 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?
Usage is only implied: an agent can infer this is the tool for rate/export-control exposure on a single company. There is no explicit when-to-use statement, no exclusions, and no pointer to alternatives such as get_company_financials or compare_companies for cross-company analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return segment data (by business segment, geography or consolidation scope) from one EDINET filing of a Japanese listed company. Shows how facts are broken down by business segment, geography, or reporting consolidation scope. Includes bilingual axis and member labels; a label can be null when the filing's taxonomy has none. Also returns regional revenue and non-current assets parsed from the filing's geographic table, each row with its source cell and a reconciliation status; rows with is_corporate_elim true are corporate or elimination lines, not regions. Source: EDINET (https://disclosure2.edinet-fsa.go.jp/), PDL 1.0 (https://www.digital.go.jp/resources/open_data/public_data_license_v1.0). Data is processed by Kabuken, not raw unprocessed FSA data. Includes EDINET Taxonomy content, excluded from PDL 1.0 and separately licensed (https://www.fsa.go.jp/search/EDINET_Taxonomy_Legal_Statement.html). © Copyright 2014 Financial Services Agency, The Japanese Government. When truncated is true, next_cursor is set; pass it as cursor to read the remaining segment rows (next_cursor is null on the last page). The geographic table is returned on the first page only. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | 'segments' returns the dimension segments only, 'geographic' returns the regional table rows only, 'all' returns both. Default all. | all |
| limit | No | Maximum number of segment records to return per page (1-500, default 100) | |
| cursor | No | Opaque next_cursor from the previous response; send it with the same doc_id, fact_name, include_all_axes, view and limit to get the next page. The geographic table is returned on the first page only. | |
| doc_id | Yes | EDINET document ID, e.g. S100ABCD | |
| fact_name | No | Optional XBRL dimension axis name to filter results to a specific axis (e.g. 'jppfs_cor:ConsolidatedOrNonConsolidatedAxis'). If omitted, only business segment, geographic and consolidation scope axes are returned, business segments first. | |
| include_all_axes | No | When true, also returns non-segment axes such as components of equity, officers and share classes (listed after the segment axes). Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safe read profile, and the description adds substantial behavioral context on top: null labels when the taxonomy lacks them, per-row source cell and reconciliation status for geographic rows, the is_corporate_elim flag meaning rows are not real regions, and that the geographic table appears only on page one. Data provenance (Kabuken processing, EDINET Taxonomy carve-out and licensing) is also disclosed, which matters for redistribution.
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 functional purpose is correctly front-loaded, but roughly a third of the text is licensing and copyright boilerplate that dilutes the operational content an agent needs. The remaining sentences are dense but mostly 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?
With no output schema, the description carries the burden of explaining return values, and it does so well: segment dimension rows, bilingual labels with possible nulls, geographic rows with reconciliation status, and pagination via truncated/next_cursor. A short note on the shape of the segment record fields would make it fully self-sufficient.
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 description mostly restates what the schema already states (cursor reuse, geographic-on-first-page) and adds little parameter-level meaning beyond the schema, such as how axis ordering interacts with fact_name filtering.
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 ('Return segment data ... from one EDINET filing') and enumerates the three breakdown types plus the geographic table, so the agent knows exactly what content comes back. It does not name or contrast with any sibling (e.g. get_financial_facts, get_calculation_tree), so it falls short of the 5 bar for explicit sibling 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 implied by the scope ('one EDINET filing'), and the truncation/cursor paragraph gives concrete guidance on continuing a paginated read. However, nothing says when to prefer this over get_financial_facts or get_document_summary, and there are no stated exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the EDINET filings of a Japanese listed company by entity code. Returns documents with submission dates, period coverage, and XBRL/PDF availability.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of documents to return (1-100, default 20) | |
| cursor | No | Opaque next_cursor from the previous response; send it with the same entity_code and limit to get the next page | |
| entity_code | Yes | EDINET entity code of the company, e.g. E02144 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, closed-world safety profile, and the description adds real value by disclosing what each result contains (submission dates, period coverage, XBRL/PDF availability). It omits ordering and pagination behavior, though the cursor/limit params cover paging.
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 packed sentences: the operation and scope first, then the returned attributes. No filler or 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 simple filtered-list tool with rich schema descriptions and safety annotations, the definition covers what is needed to call it correctly and what comes back. Minor omission of result ordering/default sort is not blocking.
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 entity_code format (E02144), limit bounds, and cursor semantics are already fully documented in the schema. The description only restates that lookup is by entity code, adding little beyond the structured fields.
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?
Concrete verb+resource: lists EDINET filings for a Japanese listed company by entity code, which distinguishes it from single-document siblings like get_document_summary and analyze_document. It stops short of explicitly saying why to call this instead of those siblings, keeping it at 4.
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: the entity_code scoping and returned fields suggest it as a discovery step before per-document tools, but no when-to-use, when-not-to-use, or named alternative is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all industry classifications used to categorize Japanese listed companies in EDINET. Returns bilingual (EN/JA) industry names and their IDs for use in company filtering.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a read-only, non-destructive, closed-world operation, and the description adds useful behavioral context: it lists all classifications and returns bilingual names and IDs. It does not describe ordering or pagination, but those are minor for a small static reference list.
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 definition is two tight sentences with no wasted wording. Scope and return content are front-loaded, so an agent can parse the essential information immediately.
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-only reference-list tool with no output schema, the description is complete enough: it states the domain, what is listed, and what is returned. No additional behavioral or parameter detail is needed to invoke it 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?
The tool has zero parameters, so there are no parameter semantics to explain. The description appropriately focuses on scope and return content instead, matching the baseline for a no-parameter tool.
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: list all industry classifications used in EDINET for Japanese listed companies. It clearly describes what the tool returns, but it does not explicitly contrast itself with sibling tools such as get_industry_overview or screen_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?
The phrase 'for use in company filtering' gives clear context for when to use the tool. However, it does not name alternative tools or explicitly state when not to use it, leaving sibling routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records a report that a figure or field for a listed company looks wrong or missing, with the filing, concept and context it concerns. Returns a report_id and status. The report stores only the text written in it and the account that sent it, and is reviewed by the Kabuken team.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | No | EDINET document id of the filing the figure comes from. | |
| concept_id | No | XBRL concept of the figure, such as jppfs_cor:NetSales. | |
| context_ref | No | XBRL context reference of the figure, such as CurrentYearDuration. | |
| description | Yes | What is wrong or missing, with the value shown and the value expected. Do not include personal data. | |
| entity_code | Yes | EDINET code of the company concerned, such as E02144. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false. The description adds real context beyond them: what gets stored (only the entered text and the sending account), that a report_id and status are returned, and that the Kabuken team reviews the report. It omits any mention of quota/auth constraints, which matters given the get_account_quota sibling.
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 sentences, front-loaded with the purpose, then the return value, then the storage/review caveat. No redundancy with the name or title, and every sentence carries new 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?
Return values are described inline in place of an output schema, and the storage/review behavior answers the main questions an agent would have about a write tool. Rate limits or duplicate-submission behavior are the only notable omissions.
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 five parameters are already documented with formats and examples. The description only frames them collectively ('the filing, concept and context it concerns') without adding format, priority, or optionality guidance, 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?
States a specific verb and resource: records a report that a company figure/field is wrong or missing, naming the filing, concept and context involved. That is concrete enough to distinguish it from every sibling tool, all of which are read/analysis operations. It stops short of explicitly contrasting with a sibling, so a 4 rather than 5.
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 by the phrase 'looks wrong or missing' – the agent can infer this is for suspected data errors, but there is no explicit when-to-use, when-not-to-use, or named alternative. Given that no sibling tool overlaps, the gap is small but real.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Japanese listed companies matching financial ratio filters (ROE, ROA, operating margin and others). Supported ratios: roe, roa, operating_margin (fractions, e.g. 0.15 means 15%), current_ratio and debt_to_equity (plain ratios, e.g. 1.5 means 1.5x). Multiple filters are combined with AND logic. Only the latest reported period per company is considered. Companies with negative equity are excluded by default. Banks, insurers and securities firms (statement_format bank, insurance, insurance_life, insurance_nonlife or securities, read from each filing whatever its accounting standard) are excluded by default, because their ratios measure a balance sheet that is the business itself and have no operating margin or current ratio; include_financials: true includes them. ROE and ROA divide net income by the average of the opening and closing balance (the 決算短信 convention); roe_basis and roa_basis are "average", or "year_end" when the opening balance is not available. Companies no longer on the JPX listed-company list are excluded by default; include_delisted: true includes them. Each result carries its statement_format. Source: EDINET (https://disclosure2.edinet-fsa.go.jp/), PDL 1.0 (https://www.digital.go.jp/resources/open_data/public_data_license_v1.0). Data is processed by Kabuken, not raw unprocessed FSA data. Figures are calculated by Kabuken from EDINET filings, not reported directly by EDINET. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1-100, default 20) | |
| cursor | No | Opaque next_cursor from the previous response; send it with the same filters, sort and limit to get the next page. total is returned on the first page only. | |
| filters | Yes | Array of ratio filters. Each filter specifies a metric, a comparison operator (gt, lt, gte, lte), and a numeric threshold value. | |
| sort_by | No | Optional metric to sort results by. Default sort is by entity_code. | |
| industry_id | No | Optional industry filter. Industry ID, e.g. ind_3700. The bare industry code (3700) is also accepted. | |
| sort_direction | No | Sort direction when sort_by is specified. Default: desc. | |
| include_delisted | No | Include companies that are no longer on the JPX listed-company list (delisted), which are excluded by default. Default: false. | |
| include_financials | No | Include banks, insurers and securities firms, which are excluded by default. Their ROE, ROA and debt_to_equity are not comparable with other companies', and operating_margin and current_ratio are null for banks and insurers. Default: false. | |
| exclude_negative_equity | No | Exclude companies with negative equity (inferred from a negative debt_to_equity ratio, since liabilities are never negative) from results. Default: true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the safe read-only annotations, the description discloses default exclusions (negative equity, financials, delisted), rationale for excluding financials, latest-period behavior, ROE/ROA averaging conventions, and data provenance. This is unusually rich behavioral context for invoking the tool correctly.
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 and dense with relevant information; most sentences earn their place, including the ratio conventions and exclusion rules. It is a long single paragraph, but the length is largely justified by the complexity of the screening semantics and provenance requirements.
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 rich input schema and safe annotations, the description covers the main invocation semantics: filters, defaults, exclusions, ratio computation, and source caveats. It is somewhat thin on the shape of returned company records, but the critical screening behavior is well 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%, so baseline is 3. The description adds meaningful semantics beyond the schema: filter AND logic, ratio units, latest-reported-period treatment, negative-equity default, financials inclusion rationale, and ROE/ROA basis. It does not explain every parameter, but it covers the critical screening behavior.
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: finding Japanese listed companies matching financial ratio filters. It names the supported ratios and scope, so an agent can distinguish it from lookup tools like get_company or search_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?
The description makes clear that this tool is for ratio-based screening with AND-combined filters and explains several default-inclusion decisions. It does not explicitly route the agent away from siblings such as search_companies or compare_companies, so it lacks full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Japanese listed companies by name and get their identifiers (entity code, ticker). Send query for one name, or queries (up to 20 names) to resolve many names in one call; each name returns its own list of matches. Returns matching companies with bilingual names and identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return per name (1-20, default 10) | |
| query | No | Company name text to search, English or Japanese | |
| cursor | No | Opaque next_cursor from the previous response; send it with the same query and limit to get the next page | |
| queries | No | Company name texts to search in one call, English or Japanese. Use instead of query. Not combined with cursor |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/openWorld/destructive profile, and the description adds useful behavioral context: bilingual company names, per-name result lists, and identifier returns. It does not discuss matching behavior (exact vs partial) or pagination in prose, but the added return-shape information is substantive.
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 dense sentences, front-loaded with purpose and followed by the key usage distinction. No wasted text, and every clause carries relevant 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?
With no output schema, the description does a reasonable job of conveying return content (matching companies with bilingual names and identifiers, per-name lists). Pagination via cursor is only covered in the schema, so minor incompleteness remains.
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 parameter meanings are already fully documented. The description reinforces the query/queries distinction and the 20-name batch limit, but mostly restates 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?
States a specific verb and resource ('Find Japanese listed companies by name') plus the returned identifiers (entity code, ticker). It is clear, but it does not explicitly differentiate itself from siblings such as get_company or screen_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?
Explains the two usage modes clearly: 'query' for one name and 'queries' (up to 20) for batch resolution, noting each name returns its own match list. It lacks explicit when-to-use guidance versus related siblings, but the single-vs-batch routing is well covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_segment_breakdown2 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "Opaque next_cursor from the previous response; send it with the same doc_id, fact_name, include_all_axes, view and limit to get the next page. The geographic table is returned on the first page only.",
+ "type": "string"
+}Input schema / properties / limit / descriptionPrevious value: -"Maximum number of segment records to return (1-500, default 100)"New value: +"Maximum number of segment records to return per page (1-500, default 100)"get_major_shareholders2 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "Opaque next_cursor from the previous response; send it with the same entity_code and limit to get the next page",
+ "maxLength": 512,
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "description": "Maximum number of shareholder rows to return (1-500, default 100)",
+ "maximum": 500,
+ "minimum": 1,
+ "type": "number"
+}screen_companies1 field changedInput schema / properties / cursorAdded value: +{
+ "description": "Opaque next_cursor from the previous response; send it with the same filters, sort and limit to get the next page. total is returned on the first page only.",
+ "maxLength": 512,
+ "type": "string"
+}search_companies3 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (1-20, default 10)"New value: +"Maximum number of results to return per name (1-20, default 10)"Input schema / properties / queriesAdded value: +{
+ "description": "Company name texts to search in one call, English or Japanese. Use instead of query. Not combined with cursor",
+ "items": {
+ "maxLength": 100,
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+}Input schema / requiredRemoved value: -[
- "query"
-]get_financial_facts1 field changedInput schema / properties / cursorAdded value: +{
+ "description": "Opaque next_cursor from the previous response; send it with the same doc_id, filters and limit to get the next page",
+ "maxLength": 512,
+ "type": "string"
+}list_documents1 field changedInput schema / properties / cursorAdded value: +{
+ "description": "Opaque next_cursor from the previous response; send it with the same entity_code and limit to get the next page",
+ "maxLength": 512,
+ "type": "string"
+}search_companies1 field changedInput schema / properties / cursorAdded value: +{
+ "description": "Opaque next_cursor from the previous response; send it with the same query and limit to get the next page",
+ "maxLength": 512,
+ "type": "string"
+}report_data_issueanalyze_documentcompare_companiesget_account_quotaget_calculation_treeget_companyget_company_financialsget_document_summaryget_financial_factsget_industry_overviewget_major_shareholdersget_risk_contextget_segment_breakdownlist_documentslist_industriesscreen_companiessearch_companiesCross-market (US/JP/KR) structured financials, segments, ownership & metrics, traceable to filings.
Remote MCP for Japan's EDINET DB — 3,800 listed companies' financials & filings (OAuth)
Japanese stocks from EDINET/TDnet filings: fair-value range, 6-axis score, DCF, earnings, screening
Japanese public records on 1-10 companies per call: FSA, MOF, EDINET, ISA, gBizINFO. Evidence only.
Add one secure layer between your agents and this server.
