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 implies a read-only lookup and discloses the returned fields, but says nothing about behavior on unknown/ambiguous identifiers, required auth, or whether the call is a single deterministic lookup.

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 blocks: the payload summary first, the parameter constraint second. No filler, and the field list earns its space by telling the agent whether this tool answers the question.

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?

An output schema exists, so return values need no elaboration, and the single parameter is fully explained. Only edge-case behavior (not found, ambiguous name matches) is left uncovered for a simple lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does by defining the accepted identifier forms with a concrete ticker example (005930) plus corp_code and name. It stops short of format rules for corp_code or ambiguity handling.

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 the resource (company overview) and enumerates exactly what comes back: name in English/Korean, CEO, market, industry code, address, website, fiscal year-end. That lets an agent separate it from financial, filing, and shareholder siblings, though it never explicitly contrasts with search_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?

The identifier note ('accepts a ticker, corp_code, or name') implies when the tool is usable, but there is no explicit when-to-use/when-not guidance and no mention of search_company as the alternative for discovering an unknown company.

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 usefully discloses that the data comes from a periodic report and that labels are Korean, including mappings for key dividend fields, but it does not state read-only behavior, permission needs, or response shape beyond the output 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 description is short and front-loaded with the tool's purpose before adding the Korean-label caveat. The field list and example mappings are useful, though there is minor repetition between the English field names and the Korean label examples.

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?

An output schema exists, so return values need not be fully explained. The description covers the dividend fields and Korean label issue, but with 0% schema description coverage and no annotations, it leaves parameter semantics and sibling differentiation underspecified.

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 0%, so the description should compensate for undocumented parameters. It does not explain the company, year, or period parameters, nor does it map period enum values to report types, leaving input semantics almost entirely to the bare schema titles.

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 identifies a specific resource and source: dividend data from a periodic report, including DPS, payout ratio, yield, and total paid. It is clear what kind of data the tool returns, though it does not explicitly distinguish this from sibling tools such as get_financial_statements.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for dividend data but gives no explicit guidance on when to use it instead of alternatives like get_financial_statements or get_recent_filings. There are no stated exclusions, prerequisites, or alternative-tool routing.

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 disclosure burden and does well: it states that filings are Korean, returns a table of contents with character offsets, flattens tables to ' | '-separated rows, and returns snippets when search is used. It does not discuss permissions, rate limits, or error behavior, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and identifier, then proceeds through pagination, search, table formatting, and citation guidance. Every sentence adds useful information without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no annotations, four parameters, 0% schema description coverage, and an output schema. The description covers most operational details, including output shape and search behavior, but omits max_chars and any mention of how to obtain rcept_no. It is nearly complete for correct invocation.

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 0%, so the description must explain all four parameters. It explains rcept_no, offset, and search well, including Korean keyword examples, but leaves max_chars completely undocumented. This compensates for most of the schema gap but not all of it.

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: read the original text of a filing, identified by a 14-digit rcept_no. It is clearly distinguishable from sibling tools that search companies or retrieve financial statements, because this one retrieves filing body text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete usage guidance: use offset to page through long filings, and pass search to get matching snippets instead of a page. It also tells the agent to translate as needed and cite url. It does not compare this tool directly with sibling filing-related tools, but the modes of use are clear.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the XBRL source, English labels, KRW units, consolidated-to-separate fallback, summary vs full scope, and the meaning of 'current' versus 'current_year_to_date' for quarterly income statements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then uses compact bullets to explain the parameters that most need clarification. Every sentence adds useful information without repetition.

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?

An output schema exists, so return structure need not be described. The description is complete for most parameters and data semantics, but the missing guidance on the required company parameter is a notable gap for an agent invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters, and it does for year, period, consolidated, and detail—including enum meanings and fallback semantics. It does not explain the required company parameter's expected format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns financial statements sourced from XBRL filings with English account labels. It distinguishes the resource from nearby filing-related siblings, though 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?

It gives useful usage context for period selection, including the explicit instruction to use 'annual' for Q4/full-year. It also explains the consolidated fallback behavior, but it does not say when to prefer this tool over siblings like get_filing_text.

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 usefully adds ordering ('newest first') and clarifies the report type via the SEC Form 4 analogy, but it never states that this is a read-only lookup, nor does it mention pagination, rate limits, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, front-loaded, and every sentence adds useful context: the report type, the SEC Form 4 analogy, the covered persons, and the sort order. Minor redundancy between 'executive and major-shareholder ownership reports' and 'holdings and changes by directors, officers, and 10%+ holders' keeps it from a 5.

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?

An output schema exists, so return values need not be explained. However, for a tool with no annotations and 0% schema description coverage, the description is incomplete: it omits the company identifier format, the limit semantics, and any differentiation from get_major_shareholder_changes.

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 0%, so the description must explain the parameters, but it says nothing about the required 'company' identifier format (ticker, name, Korean company name?) or what 'limit' controls and its maximum. It only broadly implies the domain, leaving both parameters semantically underspecified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific resource (executive and major-shareholder ownership reports) and a useful analogy (Korea's SEC Form 4), with clear scope (directors, officers, 10%+ holders). It does not, however, explicitly distinguish this from the sibling get_major_shareholder_changes, which appears to overlap.

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 content implies when the tool is relevant, but there is no explicit 'use this when' guidance and no exclusion or alternative named. Given the overlapping sibling get_major_shareholder_changes, the lack of routing guidance is a meaningful gap.

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 more burden, but 'get' and the periodic-report framing imply a read-only retrieval operation. It discloses the data content and temporal scope (start and end of period), but does not discuss permissions, limitations, or response behavior beyond what the output schema may 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 two short sentences with the core resource and temporal scope front-loaded. There is no redundant or wasted wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so return-value details need not be in the description. However, for a three-parameter tool with no annotation or schema parameter documentation, the description is incomplete because it does not explain parameter usage or clarify sibling-tool selection.

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 0%, so the description must compensate, but it does not explain the company, year, or period parameters. It mentions 'periodic report' and 'start and end of the period,' which weakly relates to the period parameter, but required company and year semantics remain undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource as largest shareholder and related-party stakes from a periodic report, including the Korean term. It distinguishes the data from broad company search or filing retrieval, though it does not explicitly contrast with the sibling get_major_shareholder_changes.

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 'as of a periodic report' and the focus on chaebol control structure, but there is no explicit guidance on when to use this versus get_major_shareholder_changes, get_insider_trades, or get_company_profile. The agent must infer the appropriate selection context.

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

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

With no annotations, the description carries the behavioral burden and usefully discloses returned fields and 'Newest first' ordering. However, it does not state that the operation is read-only, explain limit/pagination behavior, or mention auth/rate-limit constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core definition, then adds the SEC analogy, returned fields, ordering, and signal value. Every sentence adds useful context with no wasted language.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema covers return values, and the description adequately explains the dataset and sort order. However, for a tool whose company parameter has 0% schema description coverage, it is not fully complete because it never clarifies what company identifier format is expected or what limit controls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description never mentions the company or limit parameters, and schema description coverage is 0%. With two undocumented parameters and no compensating explanation, an agent must infer meaning entirely from parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and scope: 5% block-holding reports showing who crossed or changed a 5%+ stake. The SEC Schedule 13D/13G analogy makes the dataset immediately understandable and distinguishes it from a general largest-shareholders 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 clear usage context by calling it a 'Key activist/M&A signal,' which tells the agent when this data is valuable. It does not explicitly name alternatives such as get_largest_shareholders or get_insider_trades, so sibling routing is left implicit.

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 still discloses useful behavioral traits: newest-first ordering, incomplete English title coverage, and the 3-month market-wide search limit. It omits pagination behavior and any auth/rate-limit notes, so it is strong but not complete for an annotation-free tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded summary sentence followed by tight bullets, each earning its place with concrete enum glosses. Slightly dense but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be explained, and the description does cover the high-value parameters. However, with 8 parameters and 0% schema coverage, the four undocumented parameters — particularly the semantically ambiguous include_amended_originals — leave real gaps an agent must guess at.

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 0%, so the description carries the burden. It does well on the non-obvious ones — company accepts ticker/corp_code/name, filing_type enum values are explained with examples, and start_date/end_date format is given — but days, page, limit, and especially include_amended_originals get no explanation at all.

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 ('List DART filings'), the sort order ('newest first'), and a data caveat ('English titles where known'). It also names the sibling get_filing_text and the handoff key (rcept_no), so an agent can distinguish listing from reading without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to omit company (market-wide) and attaches the resulting constraint (DART limits market-wide searches to 3 months). It also states that start_date/end_date override days and that get_filing_text should be used for filing bodies, which is clear 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 behavioral burden. It usefully discloses that listed companies rank first and that ambiguous names may match multiple entities, but it does not cover match semantics, no-result behavior, or other operational details beyond the ranking hint.

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, front-loaded with the core search capability and then the key usage guidance. Every sentence adds information without repetition.

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?

An output schema exists, so return-value details are not required in the description. For a simple three-parameter search tool with no annotations, the description covers the main query semantics and usage context, though the limit and listed_only parameters remain unexplained.

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 0%, so the description must compensate. It does well for the required query parameter by naming accepted identifier formats, but it says nothing about limit or listed_only, leaving two of three parameters undocumented.

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: find Korean companies on DART. It lists the exact lookup forms (English name, Korean name, KRX ticker, corp_code), making the tool's scope immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use this first when unsure which entity a name refers to, with a concrete ambiguity example. It lacks explicit when-not-to-use guidance or named alternatives, but the usage context is clear.

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

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

No annotations are provided, so the description carries the burden and does meaningful work: it discloses the unknown-term behavior (returns null), and that no API call is made, which tells the agent there is no rate limit, latency, or network failure mode. It stops short of stating whether results are positionally aligned to the input array or whether partial hits are possible.

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 paragraphs, zero filler, front-loaded with the core action. The inline Korean examples earn their space by making the jargon scope concrete rather than abstract.

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?

An output schema exists, so return values need no explanation, and the description covers scope, failure mode, and cost. The remaining gap is directionality: 'look up Korean terms' leaves ambiguous whether Korean is the input or the output, which an agent needs in order 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 0% for the single `terms` parameter — the schema only says array of strings. The description implies batch semantics and per-term resolution ('Returns null for unknown terms'), which is genuinely useful, but it never states input language direction, ordering of results, or case/whitespace handling.

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: look up Korean disclosure, accounting, and governance terms in a curated glossary. It also scopes the domain (DART jargon) with concrete examples, so an agent knows exactly what class of string this tool handles versus the sibling filing/financial 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?

Explicitly positions itself against the alternative an agent would otherwise reach for (generic translation), and gives the selecting condition: DART jargon such as 유상증자 or 전환사채. No sibling tool overlaps, so the lack of a named MCP alternative or explicit when-not clause is a minor gap rather than a missing one.

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