Server Quality Checklist

Tool Scores

• list_recent_filingsA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It states 'Returns metadata only' implying read-only behavior and mentions 'Free', but it does not explicitly confirm safety, idempotency, or authentication requirements. The description is mostly adequate but lacks explicit transparency on side effects.

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

  Conciseness5/5

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

  The description is concise (6 sentences), well-structured with clear sections (purpose, return type, args, returns), and front-loads the primary purpose. Every sentence earns its place, with no fluff.

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

  Completeness5/5

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

  Given the tool's simplicity (2 optional parameters) and the presence of an output schema, the description is adequately complete. It covers metadata-only return and cross-references other tools, providing sufficient context for an agent to use this tool correctly.

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

  Parameters5/5

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

  The description fully documents both parameters (limit and since_hours) with ranges and defaults, compensating for 0% schema description coverage. This adds meaning beyond the bare input schema, enabling precise agent decisions.

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

  Purpose4/5

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

  The description clearly states that the tool browses recent DART filings for Korean companies and returns metadata only. However, it does not differentiate itself from the sibling tool 'get_recent_filings', which has a similar name and purpose, creating potential ambiguity.

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

  Usage Guidelines4/5

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

  The description hints at a usage flow by referencing get_disclosure_summary for paid calls, but it does not explicitly state when to use this tool versus alternatives like get_recent_filings. It provides some context without clear when-to-use or when-not-to-use guidance.

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

• get_pricingA
  4.5/5.0
  Behavior4/5

  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 discloses the call is free and returns specific fields (x402 wallet address, network, USDC contract, price in USDC). This gives good behavioral context, though it doesn't mention authentication or rate limits, which are likely unnecessary for a free, parameterless call.

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

  Conciseness5/5

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

  Three sentences with no wasted words. First sentence states purpose, second details output, third gives usage guidance. It is appropriately sized and front-loaded.

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

  Completeness5/5

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

  Given zero parameters and the existence of an output schema (though not shown), the description mentions what the call returns and explains when to use it. It covers the necessary context for a simple tool.

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

  Parameters4/5

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

  There are no parameters, and schema coverage is 100%, so baseline is 4. The description adds no extra parameter info because none exist, but that's appropriate.

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

  Purpose5/5

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

  Description clearly states the tool fetches current per-endpoint pricing for koreafilings.com. The verb 'Fetch' and resource 'current per-endpoint pricing' are specific. Sibling tools are about filings and disclosures, so this tool is distinct.

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

  Usage Guidelines4/5

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

  Description explicitly notes it's a free call and useful for confirming the payer will settle on the expected chain before spending. This implies when to use it, though it doesn't provide explicit exclusions or alternatives. Nevertheless, the context is clear.

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

• find_companyA
  4.6/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses it is free, returns a list of dicts, and states behavior on no results ('Empty list... never raises'). Does not mention side effects but no issues expected.

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

  Conciseness5/5

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

  Description is concise with organized sections (intro, usage link, Args, Returns). Every sentence adds value without redundancy.

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

  Completeness5/5

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

  Given the simple tool (2 params, no enums, has output schema), description covers purpose, usage, params, return format, and edge case (empty list). No gaps for the agent.

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

  Parameters5/5

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

  Schema coverage is 0%, but description adds examples for query (English, Korean, ticker) and specifies limit range (1-50, default 20), providing crucial context beyond schema.

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

  Purpose5/5

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

  The description clearly states the tool searches the KRX directory for Korean listed companies, specifies the use case (getting a ticker from a company name), and distinguishes from siblings by mentioning passing to get_recent_filings or get_disclosure_summary.

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

  Usage Guidelines4/5

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

  Explicitly says 'Use this as the first step when you have a company name... but not the six-digit KRX ticker.' and provides follow-up usage, though does not explicitly state when not to use it.

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

• get_disclosure_summaryA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses the real USDC cost, settlement conditions, error handling, and return value structure including payment proof. This exceeds expectations for transparency.

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

  Conciseness4/5

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

  The description is well-structured with sections and front-loaded with purpose and cost warning. It is somewhat lengthy but every sentence serves a clear purpose, earning a 4.

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

  Completeness5/5

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

  Given one parameter and an output schema, the description covers input, output structure, errors, cost, and use case. It is complete and leaves no gaps for the agent.

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

  Parameters5/5

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

  The single parameter rcpt_no is documented with a 14-digit format, an example, and sources for discovery. Schema description coverage is 0%, but the description compensates fully, adding significant meaning.

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

  Purpose5/5

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

  The description clearly states the tool fetches an AI-generated English summary of a Korean DART disclosure. It specifies the resource (disclosure summary) and action (fetch), and is distinct from sibling tools like find_company or get_pricing.

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

  Usage Guidelines4/5

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

  The description explains when to use (need a summary), provides cost and failure details, and tells how to discover receipt numbers. It lacks explicit when-not or alternative tools, but the context is sufficiently clear.

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

• get_recent_filingsA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description fully carries the burden, disclosing real USDC cost (0.005 per filing), payment on success only, return structure including payment tx hash, and RuntimeError on failure.

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

  Conciseness5/5

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

  Every sentence is purposeful: purpose, cost warning, usage hint, parameter descriptions, return shape, error handling. No redundancy or fluff.

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

  Completeness5/5

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

  Given the tool's complexity (paid API with cost, two parameters, custom return), the description covers behavior, cost, error handling, and return shape comprehensively, despite no annotations or rich output schema in prompt.

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

  Parameters5/5

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

  Despite 0% schema description coverage, the description adds crucial details: ticker format with example, limit range (1-50) and default, and cost per unit, far exceeding schema's plain type info.

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

  Purpose5/5

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

  The description clearly states the verb 'Fetch' and resource 'AI summaries for one Korean ticker', distinguishing it from siblings like find_company (resolves name to ticker) and list_recent_filings (likely just lists without costs).

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

  Usage Guidelines4/5

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

  Explicitly advises to call find_company if only a company name is available, providing an alternative. No explicit when-not, but the cost implication implicitly guides against overuse.

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