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

Annotations already declare read-only, non-destructive, and closed-world behavior. The description adds useful validation semantics: missing fields remain unknown and quote presence is checked, but factual interpretation and attribution are not validated. It still omits return format, but the annotations carry safety 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?

Three sentences are front-loaded with purpose and constraints. Every sentence adds a distinct constraint (source, missing fields, validation scope) with 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?

For a tool with a required 2–4 item array of case objects and no output schema, the description gives the high-level input contract but leaves key details implicit. It does not explain the nested case fields or what the built comparison returns, so an agent still needs to infer much from the schema.

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 carry parameter meaning. It explains that 'cases' are 2–4 newly researched cases with exact quotes from specific reader tools, but it does not explain the nested fields (budget, result, target, operation) or the optional 'title' parameter.

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 ('Build a comparison') and constrains the inputs to 2–4 cases with exact quotes from read_open_document or read_official_source. It distinguishes the tool from the listed reader siblings by being a downstream composer, though it does not explicitly contrast with search/research alternatives.

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 prerequisite context: the cases must come from newly researched sources and quotes must be returned by read_open_document or read_official_source in this process. However, it does not say when to prefer this tool over research_policy or the search siblings, nor does it 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.

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), yet the description adds substantial non-obvious behavior: no OCR, max 300-page scan, six-result cap, HWP/HWPX citations being document-level with page=null requiring page=1, up to three official-domain redirects, and an untrusted-data warning. These are real operational constraints an agent cannot infer from the schema or 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?

Telegraphic and front-loaded with the verb and resource, then limits and edge cases. Every fragment carries information, though the clipped phrasing makes some sentences (HWP/HWPX citation rules) slightly harder to parse than a fuller sentence would be.

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 still names the return fields (sourceId, quoted text, PDF page numbers, official links) and covers format-specific caveats, page limits, result caps and redirect behavior. An agent has enough to invoke and interpret this 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?

Schema coverage is 0%, so the description must carry the load, and it does explain q (finds matching excerpts) and page (starts PDF scanning, bounded by the 300-page cap). The required url parameter's semantics (HTTPS go.kr only) are only implied by the format list rather than stated explicitly.

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 (Fetch) plus the resource (official HTTPS go.kr HTML, text PDF, HWP/HWPX), so the scope is unambiguous and clearly distinct from the generic read_open_document sibling. An agent can tell immediately this is the official-source-specific reader.

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 domain restriction (official HTTPS go.kr) and format list give clear context for when this tool applies, and the q/page hints describe the intended retrieval modes. It never names the alternative sibling (read_open_document) or states when NOT to use this tool, so it stops short of explicit 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?

Annotations already declare readOnly/openWorld/non-destructive, and the description adds real behavioral context beyond them: nonpublic files are not downloaded, provider failures are explicit, the download goes through a privacy-filter workflow, and HWP extraction is limited to page=1. These are genuine operational constraints an agent needs.

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 with the core purpose, which is good, but the prose is telegraphic and dense ('q/page focus extraction; HWP page=1 only') and the sentence 'never infer missing budgets' is oddly placed for a document-reading tool, adding noise relative to signal.

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?

There is no output schema, so mentioning that sourceId is returned and enables build_research_brief is valuable. However, with four parameters, a required 'url', and no schema descriptions, the definition is not complete enough about inputs and return shape for an agent to call it confidently.

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 carry parameter meaning. It explains fileId (download trigger), q/page (focus extraction, HWP page=1 only), and mentions the returned sourceId, but leaves the required 'url' parameter and its expected format entirely 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?

Names a specific verb+resource ('Read open.go.kr document metadata and available attachment IDs') and adds scoped capabilities (download via fileId, extract PDF/HWP/HWPX). It distinguishes itself from pure search tools but does not clarify how it differs from the similarly named siblings research_open_document and read_official_source.

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

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

Gives implied usage: pass a fileId to download, use sourceId to feed build_research_brief. But it never states when to choose this over search_open_documents or research_open_document, so the selection logic among the many open.go.kr siblings is left to inference.

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 annotations (readOnly/openWorld/non-destructive), it discloses real behavioral constraints: one-level depth only, a hard cap of three attachment candidates, possible excerpt truncation, and that it reports per-file failures and remaining links. This partial-failure and truncation behavior is exactly what an agent needs and is not in the schema or 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?

Three dense sentences, front-loaded with the core action and scope, with the return contract and constraints appended. 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?

Despite no output schema, the description explains the return payload (sourceIds, per-file failures, remaining links) and the depth/truncation limits, which is strong. The remaining gap is the undocumented url parameter, which is the one thing an agent must supply 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 single 'url' parameter has 0% schema description coverage, so the description must carry the meaning, yet it only implies the target ('an official notice') without stating expected URL format, host, or whether it must point to a notice versus an attachment. The burden is not met.

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 (read) and resource (an official notice plus up to three directly linked attachment candidates), and specifies supported formats (HTML/PDF/HWP/HWPX). It stops short of naming the apparently related siblings (read_official_source, read_open_document), so sibling differentiation is left implicit.

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

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

Gives a clear use context (returns sourceIds meant for build_research_brief) and an explicit boundary (does not search the web or infer facts). It does not state when to prefer this over the similar-sounding read_official_source or read_open_document siblings, so routing is partially inferred.

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 establish a safe, open-world read, yet the description adds substantial behavior beyond them: a three-file attempt cap, up to two extra six-page ranges per PDF, no OCR, truncation/scan status in readingCoverage, and explicit caveats that heuristics are not semantic verification and evidence needs_review is not verified relevance. This is unusually rich disclosure of limits.

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 action is front-loaded, but the remainder is a dense, run-on block that interleaves execution heuristics, interpretation warnings, and output description without separation. Most sentences carry information, so it is not padding, but the lack of structure makes it hard 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?

With no output schema, the description does the heavy lifting by enumerating the return payload (attempts, labelled excerpts, organizations, budget context notes, remaining files, readingCoverage, field quotes, page locations, original links) and warning against claiming an embedded preview. The only notable gap is the undocumented required url parameter.

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 carry the burden, and it only clarifies one of two parameters ('Pass requestedQuery with the user research intent'). The required url parameter is never explained (presumably the portal/attachment URL), leaving half the input 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 opening clause states a specific verb+resource (read portal metadata and its plan/budget attachments) and adds the distinctive research behavior of trying up to three files. It is distinguishable from the plain read_open_document sibling by the prioritization/heuristic framing, though it never names that sibling or states the contrast 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 heavily implied through context ('Follows an explicit Seoul disclosure link', 'Pass requestedQuery with the user research intent') but no alternative tool is named and no when-not condition is given. The 'supporting_document is not a primary case' line is a classification rule for the caller, not tool-selection 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 only declare read-only/open-world, yet the description discloses a large amount beyond them: per-expression page caps, a fifteen-request ceiling, a six-to-seven document budget, retry rules for failed institutions, arithmetic-only funding checks, deduplication, reviewFlags, partial failures, and title_inferred vs body-supported distinctions. No contradiction with readOnlyHint/destructiveHint=false is present.

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 ~330-word block of telegraphic, comma-chained rules with no paragraphs, bullets, or headings, mixing search-budget limits, funding arithmetic warnings, and presentation instructions. Front-loading is fine, but the density makes several sentences ('a failed institution may be retried with another candidate') hard to parse, and much of the detail belongs in structured fields or docs.

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 properly explains the returns: evidenceMap stage paths, budgetEvidenceLinks, conservative project bundles with title year, compact-field presentation with original-document links, and partial failures. It covers behavior, parameters, defaults, and outputs for a complex tool, leaving only minor ambiguity about the exact response shape.

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 only 20% schema description coverage, the description carries the load: it explains that 'queries' accepts 1-3 host-generated semantic search expressions, that 'question' is passed as-is, and that startDate/endDate must both be supplied to honor user dates (default: past two years). It adds real meaning over the bare schema, though it never states the YYYYMMDD format encoded in the pattern.

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 opening sentence 'Start here for a short municipal policy question' gives a clear entry-point scope, and the body implies a research/orchestration tool that searches, screens candidates, and returns bundles and evidence. The verb+resource is implied rather than crisply stated, and it never contrasts itself with siblings such as search_budget_projects or build_research_brief, only with 'comparison' and 'document references' modes.

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?

Strong entry guidance ('Start here for a short municipal policy question'), query-supply rules ('host AI can supply 1-3 semantic search expressions'), default-vs-user-supplied date handling, and a routing hint ('use comparison for a short ... table; use document references for details'). It lacks explicit when-not-to-use guidance against the other seven sibling tools, so it stops 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?

Annotations only cover the safety profile (readOnly, non-destructive, closed-world), so the description adds substantial extra context: row count (326289), known coverage gaps, the reconciliation each row passed, and the crucial unit clarification that amounts are thousand-KRW appropriations rather than benefits or spending. It also sets a citation obligation ('Cite source plus PDF page or HWP table/row; never fabricate a page') and warns that an empty result is not proof of absence — exactly the behavioral caveats an agent needs.

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?

Purpose is front-loaded in the opening sentence and essentially every clause carries load-bearing information (coverage limits, units, citation rules). The telegraphic, comma-spliced style is dense to the point of being hard to parse, but nothing is redundant 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?

There is no output schema, so the description has to characterize results itself — and it does, describing what a row represents, the unit of measure, and the reconciliation provenance. Pagination behavior (limit max 20 / offset) is not described, which is the main remaining gap for a 4-parameter search 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 carries the full burden, and it explains the two non-obvious parameters well: q is 'space-separated AND business-name keywords' and institution 'filters region' (a non-obvious mapping given the parameter name). Only limit/offset are left implicit, which is acceptable for standard pagination, so the meaningful gap is small.

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 gives a specific verb (Search) plus a tightly scoped resource: 'indexed 2026 original-budget general-account BUSINESS expenditure rows.' An agent can tell this apart from the totals/notice/document siblings by the 'indexed original-budget rows' scope. It stops short of naming the nearest sibling (search_verified_budget_totals) explicitly, so differentiation is inferential 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?

It names one alternative with a condition ('Use research_policy for plans/execution') and supplies caveats about coverage ('some municipalities and departments are not covered', 'No hit does not prove absence'). However, it never says when to prefer this over the closely-related search_verified_budget_totals, leaving the most important routing decision to inference.

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 only declare readOnly/openWorld/non-destructive; the description adds operationally useful facts the annotations cannot: no API key required (auth), ten raw results per page (pagination), and that counts refer to documents rather than policies (result semantics). It also discloses the default three-way result split, which is real behavioral 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?

Purpose is front-loaded and each clause carries information, but the body is three long semicolon-chained run-ons where enum semantics, pagination, and counting caveats are packed together. Dense enough that a reader must re-parse, though nothing is truly wasted.

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 search tool with no output schema, it goes beyond the minimum by describing the default return groups (items, reviewItems, relatedDocuments) and warning that counts are documents. It stops short of describing what a result item contains (e.g., whether a URL/id is returned for follow-up with read_open_document).

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 description coverage the description must carry all six parameters, and it does explain startDate/endDate format (YYYYMMDD, mandatory), both enums, and page usage. The q parameter gets only strategy advice ('present actual candidate project types, not arbitrary documents') rather than an explicit statement of query syntax or title-only matching, leaving a small gap.

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 ('Live search of ... municipal document titles') and bounds the corpus (Korean information-disclosure portal). It explicitly distinguishes itself from the sibling read_open_document by routing attachments/evidence there, so an agent can separate the two without opening a 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?

Gives condition-based routing: purpose 'projects' for candidate separation vs 'documents' for everything, scope 'original' vs 'all', and 'Inspect up to three pages if needed' as a stopping rule. It also names the alternative tool for attachments, covering when not to use this one.

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 a safe read (readOnlyHint=true, destructiveHint=false, closed-world). The description adds non-obvious behavioral context: results carry sources and limitations, and a no-hit result means missing coverage rather than zero budget. That negative-result semantics is exactly the kind of thing annotations cannot convey.

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 compact sentences, front-loaded with the verb and scope, then caveats, then the sibling disambiguation. No filler, though the opening noun phrase is dense enough to require a second read.

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 return-value burden and does so by noting sources and limitations accompany results. Scope, negative-result meaning, and sibling disambiguation are covered; only parameter-level behavior is left thin.

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 for three undocumented parameters (limit, offset, institution). It only indirectly hints at the institution domain via '245 covered institutions' and says nothing about pagination semantics for limit/offset, leaving the schema's numeric bounds to do all the work.

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 (Search) plus a precisely bounded resource: reconciled 2026 original-budget general-account municipal expenditure totals for 245 institutions. It also explicitly contrasts itself with the indexed business-level expenditure search, so an agent can separate it from siblings like search_budget_projects without opening schemas.

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

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

Gives clear when-not guidance: municipality totals are not individual project budgets, benefits, or actual spending, and the indexed business-level search is a separate tool. It does not name that sibling explicitly (only describes it), so it falls just short of a 5, but the exclusion signals are strong.

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