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

Annotations already declare readOnlyHint=true, so the safe read-only nature is known. The description adds valuable behavioral detail: 'Every label on the page is also returned verbatim in raw_fields', which is not in the schema and gives insight into the output structure.

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 opens with a clear, front-loaded summary sentence, followed by a detailed field list and the raw_fields note. It is informative without redundant fluff, though the field enumeration is slightly lengthy.

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, single-parameter tool with an output schema, the description is sufficiently complete. It covers the scope (PSE-listed), returns a comprehensive field list, and highlights the raw_fields behavior. No critical usage context 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?

The schema has 0% description coverage for the single parameter 'symbol'. The description compensates partially by mentioning 'PSE-listed company', implying symbol refers to a PSE ticker, but it gives no format, examples, or validation guidance, leaving some ambiguity.

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 the tool's function: 'Get a PSE-listed company's profile' and enumerates the specific contents (sector, incorporation, auditor, contacts). This distinguishes it from sibling tools like get_stock_quote and get_financial_highlights, making the purpose unambiguous.

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?

Clear context: the tool is for retrieving a company profile for PSE-listed stocks. It does not explicitly state when not to use it or point to alternatives, but the sibling tool names and the clarity of purpose make the appropriate usage obvious.

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?

Beyond the readOnlyHint annotation, the description discloses that published disclosures are immutable and cached permanently, that the tool is metadata-only (no file bytes), and that repeated calls cost nothing upstream. This significantly enriches the behavioral model.

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 a clear purpose sentence, then logically progresses to parameter semantics, usage alternatives, and caching behavior. Every sentence adds value; there is no fluff 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?

It covers the input provenance, return content, pagination, caching, immutability, and a clear note that file content requires resources/read. Even with an output schema present, this description leaves no relevant gap for an AI agent to select and invoke the tool correctly.

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

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

The input schema has zero description coverage, but the description defines edge_no as the 32-character hex ID from search_disclosures and explains max_files with default (20) and max (100), plus the truncation behavior. This fully compensates for the bare schema.

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

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

The description starts with a specific verb+resource: 'Get one disclosure's details and attachment links by its edge_no.' It clearly scopes the tool to retrieving a single disclosure by ID, which distinguishes it from the search siblings (e.g., search_disclosures, search_disclosure_fulltext).

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 tells the caller where to obtain edge_no (from search_disclosures) and when to use resources/read instead for file contents. It also gives guidance on handling truncation by increasing max_files, which is actionable usage 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?

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds valuable behavioral context by explaining that empty lists mean Edge lists none for this company, and that each record includes an edge_no linking to the announcement disclosure. This goes beyond the annotations and does not contradict them.

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

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

The description is a single focused paragraph, front-loaded with the core purpose. Each subsequent detail—field lists, edge_no linkage, empty-list interpretation—adds value without redundancy. Every sentence earns its place.

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

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

Given the tool's simplicity (one parameter, output schema present, readOnly, openWorld false), the description covers all relevant aspects: what data is returned, how to link to the disclosure, and how to interpret empty results. This is sufficient for an agent to correctly invoke and understand the tool's output.

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 schema has a single parameter 'symbol' with no description, and schema description coverage is 0%. The description only says 'a company's' and does not explain the symbol format, validation, or any additional semantics, leaving the parameter under-specified and requiring the agent to infer what 'symbol' means from the context.

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

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

The description opens with 'Get a company's declared dividends and stock rights offers,' using a specific verb and resource that clearly distinguishes it from sibling tools like get_stock_quote or get_disclosure. It further elaborates on the fields included for dividends and rights, making the tool's scope unmistakable.

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

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

The description implies when to use this tool by stating it retrieves dividend and rights data. It also provides a clear usage tip: pass the returned edge_no to get_disclosure for the full notice. However, it doesn't explicitly mention alternatives or when not to use the tool, so it falls short of a 5.

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?

The description goes well beyond the readOnlyHint annotation by disclosing critical behavioral details: figures are never rescaled, each period has its own currency_units label, the two sections may disagree (with a concrete observed example), and the scale should be treated as uncertain if labels conflict. This is exactly the kind of contextual information an agent needs to avoid misinterpreting results.

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 efficiently structured: purpose first, then return structure, then the critical units warning, then scope clarification. Each sentence earns its place, and the units warning is front-loaded for safety. Despite being relatively long, it is highly informative and not verbose.

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 tool's complexity (annual vs quarterly sections, currency unit inconsistencies, line-item labels), the description covers the key aspects of return format, data source limitations, and the critical unit caveat. Since an output schema exists, return values are further specified, making the description complete for an agent to invoke the tool correctly and interpret results safely.

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 schema has only one parameter 'symbol' with no description. The tool description does not explain the symbol parameter's format or examples, despite low schema coverage (0%). The phrase 'for a company' indirectly implies the parameter is a company identifier, but it does not compensate for the lack of explicit parameter documentation.

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 ('Get') and resource ('financial highlights PSE Edge publishes for a company'), and details the return structure (annual/quarterly sections with balance sheet and income statement). This clearly distinguishes it from siblings like get_stock_quote or get_company_profile.

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

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

The description gives clear context about data scope and an important exclusion ('Only the highlights Edge serves as data are here — this server does not parse filed PDF statements'). This implicitly tells when not to use the tool, but it does not name alternative tools explicitly, leaving some ambiguity for agents unfamiliar with sibling tools.

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

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

Annotations already signal read-only (readOnlyHint=true) and deterministic (openWorldHint=false), but the description adds significant behavioral context: the sign conventions (change and change_percent are signed, direction is up/down/flat derived from PSE Edge's color/arrow), the caching policy (at most once per boundary window), and the meta.as_of field for snapshot timing. This substantially goes beyond the annotations, delivering high transparency.

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 moderately sized (4 sentences) and front-loaded with the main purpose. Each subsequent sentence adds necessary detail (coverage, sign semantics, caching) without fluff. It could be slightly more compact, but it remains efficient and relevant, earning a 4 rather than 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?

With no parameters and an output schema present, the description covers all essential contextual aspects: what data is returned, which indices are included, the interpretation of direction fields, and the staleness/caching behavior. The existence of an output schema handles return field details, so the description is complete for an agent to select and invoke the tool correctly.

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

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

The tool has zero parameters, and the schema coverage is 100% (vacuously). The baseline for zero-parameter tools is 4 per the rubric. The description adds no parameter info (not needed), so the score reflects the absence of complexity.

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 the tool retrieves PSEi and PSE sector index levels with daily change. The verb 'Get' and specific resource 'PSEi and sector index levels' is explicit, and it naturally distinguishes from siblings like get_stock_quote (single stock) and get_market_summary (broader market metrics).

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

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

The description clearly indicates the scope (which indices are covered) and the context (cached until 15:00 Manila close), which helps decide when to use it. However, it does not explicitly mention when not to use it or suggest alternatives, so it falls short of a 'when/when-not' distinction. Still, the clarity of purpose provides strong implicit 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds substantial context: how feeds are keyed (group labels), what each entry carries (symbol, timestamp, circular number, edge_no), and a critical limitation (PSE Edge publishes no gainers/losers/most-active data anywhere). This goes beyond the structured annotations and helps the agent interpret results and avoid misstatements.

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 first sentence is a concise summary. The second paragraph lists the feed keys and their fields, which is necessary detail given the tool's output scope. The limitation note is important and earns its place. Slightly dense but well-organized; no filler.

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

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

Given the output schema exists, the description doesn't need to list return fields, but it still provides essential context: feed structure, key labels, and the data limitation. With zero parameters and a rich output description, an agent has enough to invoke the tool and interpret results without ambiguity.

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

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

The input schema has zero parameters, and the description itself doesn't mention parameters, which is appropriate. With no parameters, the schema coverage is trivially 100% and the baseline is 4. The description adds no param semantics because none exist.

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

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

The description uses a specific verb ('Get') and resource ('market-wide snapshot') with concrete scope: index levels plus PSE Edge's homepage feeds. This clearly differentiates it from siblings like get_indices (indices only) and search_disclosures (disclosure search), so purpose is unambiguous.

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 provides clear context for when to use this tool (for a market-wide snapshot) and includes an important behavioral instruction: if asked for gainers/losers, explicitly state PSE Edge doesn't publish them rather than implying missing data. It doesn't explicitly name alternatives or exclusions, but the context is enough for an agent to select this tool appropriately.

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?

Beyond the readOnlyHint annotation, the description adds valuable behavioral details: the data is EOD-frozen from PSE Edge's chart endpoint, and a one-time fetch may include a live bar flagged stale=true with an explanatory meta.note. This discloses caching and freshness behavior not captured by annotations.

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 compact and front-loaded: a one-sentence purpose, followed by a terse paragraph of relevant details. Every sentence adds value—date format, default window, data source, staleness caveat—with no redundancy.

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

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

The tool has an output schema and simple parameters; the description covers the essential context: data source, time zone or date format, default window, and the stale-bar edge case. This is complete for a read-only historical data 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 for parameters is 0%, but the description compensates by documenting date format (ISO YYYY-MM-DD), default range (~6 months), and symbol identity (PSE stock symbol). This gives the agent meaning for all three parameters beyond the bare schema.

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

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

The description opens with a specific verb-resource statement: 'Get daily OHLC price history for a PSE stock symbol.' This clearly identifies the tool's function and scope, and differentiates it from sibling tools like get_stock_quote (current quote) and 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 establishes clear usage context: daily OHLC historical data for PSE symbols, with default date range and ISO format. It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for an agent to select it for historical OHLC requests.

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?

Beyond the readOnlyHint annotation, the description explains a subtle behavioral detail: there is no meta block because meta is a data-freshness contract and a version has no as_of or valid_until. This adds valuable context not available from annotations alone.

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 compact and front-loaded, with the primary purpose in the first sentence. The subsequent sentences add relevant detail about what the version refers to and the absence of a meta block, with no redundancy or 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?

For a simple, parameterless tool with an output schema and safe read-only annotations, the description fully covers the tool's purpose, scope, and return behavior. It even explains why a typical data-freshness field is absent, making it complete for an agent.

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, and the schema is empty (100% coverage). The description correctly notes the absence of a meta block but doesn't need to explain parameters since there are none. Baseline for zero parameters is 4, and this description adequately addresses the tool's scope.

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 the tool's function: 'Get the deployed version of this MCP server (pse-edge-mcp).' It explicitly distinguishes itself from sibling data tools by noting it returns the server's own release version, not PSE Edge data.

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 provides clear context for when to use this tool: when you need the server's deployed version. It also clarifies that this is not for PSE Edge data, effectively excluding data-related use cases, and points to alternative sources (health endpoint, serverInfo) for the same value.

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?

Beyond the readOnlyHint annotation, the description discloses the EOD-frozen nature of the data and details the special case where an uncached symbol during market hours returns only identity plus previous_close with null fields and stale=true. This is substantial additional behavioral context that the annotation alone does not provide.

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 compact yet covers the core function, included fields, and a critical caching caveat in a single well-organized paragraph. Every sentence adds actionable information without filler or redundant repetition of the schema.

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 description fully covers the tool's behavior, including the edge-case stale response and a pointer to the meta field in the output schema. Since an output schema exists, return values are documented, and the description complements it with usage-level detail.

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 schema's symbol parameter has no description (schema description coverage 0%), but the tool description specifies it is a PSE stock symbol and gives valid examples (SM, AREIT, BDO). This compensates for the missing schema description and gives the agent concrete formatting guidance.

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 phrase 'Get the latest end-of-day quote for a PSE stock symbol' and includes concrete examples (SM, AREIT, BDO). This clearly distinguishes it from siblings like get_price_history by focusing on the latest EOD snapshot rather than historical time series.

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 for obtaining current EOD quotes but does not explicitly discuss when to prefer this tool over alternatives like get_price_history. No exclusions or when-not-to-use guidance is provided, leaving the agent to infer the appropriate context from the sibling names.

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?

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds valuable context by specifying the return fields (company_id, name, symbol) and how to use the output with other tools, going beyond what annotations provide.

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

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

The description is two sentences, front-loaded with the purpose, then gives output and usage guidance. Every sentence earns its place with no redundant or vague 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?

For a simple one-parameter search tool with an output schema, the description covers purpose, input semantics, output structure, and integration with sibling tools. It is complete and leaves no major gaps.

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

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

The schema provides no description for the 'query' parameter, but the description fully defines it as a name or ticker symbol, completely covering the semantics. This compensates for the 0% schema description 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 clearly states a specific verb+resource: 'Search PSE-listed companies by name or ticker symbol.' It distinguishes this tool from sibling tools like search_disclosures or get_stock_quote by focusing on company lookup and explicitly mentioning the use of the symbol with other 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 phrase 'Use the symbol with the other tools' gives clear context that this is the entry point for obtaining company symbols, but it does not explicitly mention when not to use it or name alternatives such as search_disclosures. It implies usage well but lacks explicit exclusions.

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?

The description discloses critical behavioral traits beyond the readOnlyHint and openWorldHint annotations: the partial index coverage (2023–2025, nothing from 2026), relevance-ordered results, 10 per page, and the inclusion of a coverage_note. It also instructs the agent to relay the limitation, which is rich, actionable context.

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 appropriately sized and front-loaded with the core function, followed by usage guidance and a key limitation note. Every sentence provides value, and the structure is easy to parse.

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 tool's complexity (6 params, output schema, annotations), the description covers the essential context: purpose, alternative usage, index limitations, ordering, pagination, and the coverage_note. With an output schema present, the description need not elaborate on return values beyond what is already provided.

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 adds meaning for the main parameter 'keyword' by indicating the search term for wording inside filings, but it does not explain optional parameters like symbol, dates, or subject_title. The schema titles provide minimal semantics, so the description only partially compensates for the lack of parameter documentation.

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 the tool performs full-text search inside disclosure attachments and returns matching snippets, distinguishing it from sibling search_disclosures by explicitly noting the alternative use case. The verb 'search' and resource 'disclosure attachments' are specific and unambiguous.

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?

Explicit usage guidance is given: 'Use this to find wording within filings' and 'For "what did company X disclose recently", use search_disclosures instead.' This directly instructs when to use this tool versus the sibling, satisfying the criteria for alternatives and exclusions.

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?

Annotations declare readOnlyHint and openWorldHint, but the description adds significant behavioral context: caching until next 15:00 Manila close, pagination specifics (total/pages/has_more), and the fact that a query may serve stale data if already cached. No contradiction with annotations.

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 appropriately sized, uses bullet points for clarity, and every sentence adds value. It is well-structured and front-loaded with the core purpose, then expands into usage and caching details without 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?

Given the tool's complexity (5 optional parameters, pagination, caching, output schema), the description covers all essential aspects: what it returns, how to paginate, parameter semantics, and behavioral nuances. The output schema exists and the description complements it without needing to explain return values in depth.

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 fully compensates by explaining all five parameters: symbol (company's full history), start_date/end_date (ISO YYYY-MM-DD, date range), template (free-text filter), and page (implicitly via 'request the next page directly'). Every parameter is semantically clarified.

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 the tool searches PSE company disclosures (announcements, material information, notices), specifies it returns disclosure metadata, and distinguishes it from get_disclosure by noting edge_no is for attachment links. This is a specific verb+resource+scope with clear differentiation from siblings.

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?

Provides detailed usage patterns: symbol-only, date range, template filter, defaults when neither symbol nor dates are supplied, pagination approach (50 results per page, next page directly), and caching behavior. It also implies alternatives (get_disclosure for attachments) and clarifies when results appear relative to the Manila close.

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?

The description goes well beyond the readOnlyHint annotation by detailing exact matching behavior ('case-insensitive... "areit" and "AREIT" both resolve'), unknown-symbol handling ('valid: false with null fields, not an error'), and caching ('Cached after the first lookup and refreshed daily'). These are non-obvious behaviors an agent needs to know.

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 compact yet information-dense, using short paragraphs and a front-loaded purpose statement. Every sentence adds value—purpose, cost hint, usage alternative, return behavior, matching rules, and caching—with no repetition or 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?

Despite having an output schema, the description still explains the key return components (valid flag, company name/id, null fields) and error behavior. It also covers caching, performance, and provides differentiation from the most relevant sibling, making it complete for decision-making.

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?

With 0% schema coverage, the description compensates by defining the sole parameter ('ticker symbol') and illustrating semantics with case-sensitivity examples. It does not provide exhaustive format restrictions, but the examples and matching rules give sufficient meaning for correct use.

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 clear, specific purpose: 'Check whether a ticker symbol is a real PSE-listed company.' It uses a strong verb ('check') and explicitly differentiates from the sibling tool search_companies by contrasting the return type (valid true/false vs. ranked list of near-matches).

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 guidance is explicit: 'Use this — NOT search_companies — when you only need to know whether a symbol is valid before calling another tool, or to confirm a symbol a user typed.' It also names the alternative and explains why this tool is preferred, giving clear decision criteria.

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