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

No annotations are provided, so the description carries the burden of disclosing behavior. It explicitly states the tool performs parallel searching across four tracks and merges results, which is a key behavioral trait. While it doesn't explicitly say 'read-only' or address side effects, search operations are inherently non-destructive, and the disclosure of the parallel/merge behavior adds value beyond what schema provides.

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: the first states the purpose and behavior, the second gives clear guidance for alternatives. It is front-loaded, concise, and every word 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 moderate complexity (4 params, all with schema descriptions) and no output schema, the description adequately covers the core functionality and directs the agent to individual tools for deeper exploration. It lacks details on the exact return format, but this is not critical for a search aggregator and is appropriately left to the individual tools.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant parameter semantics beyond what the schema already provides; it mentions the query is applied to all four tracks, which echoes the schema's parameter description. No additional syntax, format, or nuanced behavior is covered.

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 is the 'primary entry point' for accounting question search, with a specific verb ('search') and resource (4 tracks combined). It explicitly distinguishes itself from the individual search tools by listing them and explaining it searches all four in parallel and merges results.

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 explicit when-to-use guidance ('primary entry point') and when-not-to-use: it tells the agent to call individual tools (search_standards/search_qna/search_audit_case/search_sanction/get_paragraph/get_qna/get_audit_case/get_sanction) for deeper or more detailed queries. This is direct and actionable.

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 burden of behavioral disclosure. It openly states that the tool may open a browser window for login, and explicitly mentions that it only reports cookie/localStorage key names and never exposes token values. This is thorough and transparent for a tool with 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.

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

The description is concise and well-structured: the first sentence states the primary purpose, the second describes the side effect, and the third discloses data handling. Every sentence adds meaningful information with no unnecessary words.

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 output schema, so the description should clarify what the tool returns. It mentions 'reports key names' but does not specify whether the return is a boolean, a list, or a structured object. The side effect is described, but the exact output format remains ambiguous, leaving a gap for the 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 input schema is empty. According to the rubric, a zero-parameter tool gets a baseline score of 4. No parameter-specific meaning is needed, and the description does not need to compensate for missing schema details.

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 purpose: checks login status for kifrs.com. It also mentions the side effect of opening a browser window if not logged in, which adds scope. No sibling tool has a similar login-related function, so it is well distinguished.

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 usage is implied: one would call this before performing authenticated operations on kifrs.com. However, the description does not explicitly say when to use it, when not to, or mention any alternatives, leaving the guidance implicit rather than direct.

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 behavioral disclosure burden. It clearly explains the process (extract citations, fetch full text, append to answer) and notes the contrast with verify_citations. It does not mention edge cases like 'no citations found' or error handling, but the core behavioral mechanism is transparent and consistent.

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 long, well-structured, and front-loads the core functionality in the first sentence. The second sentence adds valuable usage guidance without redundancy. Every word earns its place, and there is no filler or 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?

For a tool with 4 parameters, no output schema, and no annotations, the description provides a solid overall picture: what it does, how it differs from a sibling, and when to use it. The only minor gap is that it does not explicitly describe the exact return format (e.g., whether it returns the appended answer as a string or a structured object), but the phrase '답변에 붙여 반환합니다' strongly implies the output is the modified answer.

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

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

Schema description coverage is 100% and every parameter (text, placement, max_body_chars, include_inquiry) has a detailed description. The tool description adds only general context about the tool's purpose but no additional parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

Description clearly states the tool's function: automatically extracts K-IFRS/K-GAAP standard and Q&A document citations from an LLM answer draft, fetches the original text, and appends it to the answer. It also distinguishes itself from the sibling tool verify_citations, which only checks existence, making the tool's unique 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?

The description explicitly says when to use this tool ('when the user asks to show the original text' or when citation basis must be clearly shown) and provides an explicit alternative (verify_citations for existence-check only). This gives strong usage context and avoids confusion with siblings.

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 burden of behavioral disclosure. It discloses that include_pdf_text defaults to true and extracts the actual finding reason and judgment basis from attached PDFs. However, it does not mention potential performance implications, the return structure, or behavior when include_pdf_text is false.

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: the first states the primary purpose, the second clarifies the key optional parameter. It is front-loaded and contains 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 simple detail-lookup tool with two parameters and no output schema, the description covers the core functionality and the notable PDF extraction option. It falls short of explaining the response format or cautioning about potentially large PDF text outputs, but it is adequate for an agent to make an initial call.

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 already has descriptive text for both parameters, including the default value and purpose of include_pdf_text. The description's second sentence merely restates the schema's information without adding new semantic detail, so it adds no value beyond the schema.

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

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

The description uses the specific verb '조회합니다' (retrieves) and identifies the resource as '심사·감리지적사례 상세' (audit/review finding case details), clearly distinguishing it from sibling search tools like search_audit_case. The mention of PDF text extraction further clarifies its scope.

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 retrieving a specific audit case detail, but does not explicitly state when to use it over alternatives such as search_audit_case or get_qna. The schema's parameter description for ntt_id hints at the prerequisite search, but the tool description itself offers no usage guidance or 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?

With no annotations provided, the description carries the full burden. It discloses that the tool returns the original text in HTML/plain text and related Q&A numbers, but it does not clarify output format selection, error behavior for invalid paragraph numbers, or any prerequisites. This is adequate but not rich; a score of 3 reflects minimal transparency for a simple read operation.

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, front-loaded sentence that directly states the tool's primary function and additional return value. It is concise, avoids redundancy, and contains no fluff.

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 low complexity (two parameters, no output schema), the description is nearly complete: it states the input (through schema) and the output (original text and Q&A numbers). It lacks explicit formatting details or error behavior, but for a straightforward retrieval tool, this is sufficient. It earns a 4 because the description could mention what happens if a paragraph is not found or whether both HTML and plain text are returned simultaneously.

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 already provides detailed descriptions for both parameters with examples and cross-references to get_standard_index. With 100% schema coverage, the description adds no additional parameter meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly specifies the action ('retrieves the original text') and the exact resource ('specific paragraph from K-IFRS/K-GAAP/Audit Standards'), and it distinguishes itself from siblings like get_standard_index (which lists indexes) and get_qna (which returns Q&A details) by noting it also returns related Q&A numbers.

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 implies when to use this tool: when you need the original text of a specific standard paragraph. It provides context by mentioning the standards covered and the return of related Q&A numbers, but it does not explicitly state exclusions or alternatives (e.g., 'use get_qna for full Q&A details'), which is why it's a 4 rather than 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?

No annotations are provided, so the description carries the burden. It discloses that the tool returns the full text body and performs a single lookup, which implies a read operation. However, it does not explicitly state read-only behavior, error handling, or any prerequisites such as authentication. It adds some context but misses potential behavioral details.

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 one concise sentence, front-loaded with the action and resource. It avoids unnecessary detail while conveying the essential purpose.

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 (1 parameter, no output schema, no annotations), the description plus parameter guidance is largely complete. It clarifies the return type (full text) and source of the document number. However, it could have mentioned error behavior or output structure, but these are not critical for such a simple 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?

The schema already provides 100% coverage for the single parameter, but the parameter description goes further by giving an example format and instructions to reuse docNumber from search_qna or faqDocNumbers from get_paragraph results. This adds practical guidance beyond the schema, earning above-baseline score.

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 a single Q&A detail record (full text) by document number. The verb '조회' (retrieve) and resource '질의응답 상세' distinguish it from siblings like search_qna (search) and get_paragraph (paragraph retrieval).

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?

While the main description does not explicitly mention alternatives, the parameter schema provides strong usage guidance: it tells the agent to use docNumber from search_qna results or faqDocNumbers from get_paragraph results. This implies when to use the tool (after a search or paragraph retrieval) and gives a clear trigger context, though it lacks explicit exclusions 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.

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds value by disclosing that include_pdf_text=true extracts actual violation facts and sanction amounts from attached PDFs, and it provides a critical semantic warning about not translating the content into strong conviction language. However, it does not describe the return format, errors, or permissions.

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: the first sentence states the core purpose, the second explains the optional PDF extraction, and the third delivers an important usage warning. Every sentence earns its place with no redundancy or unnecessary detail.

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 there is no output schema, the description should explain what the tool returns. It describes the detail query and the extra PDF-extracted information, but it does not specify the overall return structure or metadata fields. The warning about language nuance is helpful, but the description is not fully complete for an agent to anticipate the response.

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 100% parameter description coverage, so the baseline is 3. The description adds a small amount of value by clarifying the default of include_pdf_text and reiterating what it extracts, but it does not add meaning beyond what the schema already provides for the required parameters.

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

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

The description clearly states the tool retrieves sanction disclosure details ('제재공시 상세를 조회합니다'), using a specific verb and resource. It implicitly contrasts with the sibling search_sanction tool by focusing on '상세' (details), but does not explicitly name the alternative or differentiate beyond that.

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 usage context through the include_pdf_text parameter, noting the default behavior and that PDF text extraction is optional. The input schema parameters clearly reference search_sanction results, indicating this tool is meant to be used after search_sanction, but the description itself does not explicitly state when to use it versus alternatives.

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 burden of disclosing behavior. It states that this tool returns only the table of contents (with refs) and not the actual body text, which is a meaningful behavioral trait. This goes beyond a simple 'retrieves index' and helps set expectations.

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 core purpose, and every sentence earns its place. The second sentence adds actionable guidance about using get_paragraph, with no waste.

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 tool without an output schema, the description fully explains what is returned (TOC with hierarchy and ref ranges) and provides the next step (calling get_paragraph). It is complete in the context of sibling tools and the domain.

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 already provides full coverage for the single parameter std_num, including an example and a pointer to search_standards. The tool description itself adds no additional parameter semantics beyond the schema, so the baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves the table of contents of a standard (chapter/section hierarchy with paragraph range refs). It distinguishes itself from get_paragraph by explicitly noting that actual body text is read via get_paragraph, making the scope 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: use this tool to get the structural index, then call get_paragraph to read content within the ref ranges. It names the alternative (get_paragraph) and implies when to use each, but doesn't explicitly state exclusions or other alternatives.

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 burden. It discloses that saves are local, that they overwrite existing explanations, and that they are reused via get_paragraph's cached_explanation field. This is meaningful behavioral transparency, though it omits error cases or permission requirements.

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

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

The description is three concise, front-loaded sentences. It starts with the core action, then explains the reuse mechanism, then gives a usage scenario. Every sentence adds value without fluff.

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 save tool with three fully described parameters and no output schema, the description is sufficiently complete. It covers purpose, persistence, overwrite semantics, and how the saved data is later used. It lacks detail on error handling or authentication, but these are not critical for this tool's basic operation.

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

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

Schema description coverage is 100%, and the schema already documents all three parameters clearly. The description adds context that std_num and para_num match get_paragraph usage, but this is minor. Overall it provides limited additional meaning beyond the schema.

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

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

The description clearly states a specific verb and resource: saves an explanation for a particular standard paragraph locally. It distinguishes itself from siblings by explicitly tying to get_paragraph's cached_explanation behavior, making the tool's unique role obvious.

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 on when to use it: to save helpful or frequently used practical explanations for reuse. It also explains the overwrite behavior. It does not explicitly say 'use this instead of X', but the connection to get_paragraph provides adequate usage 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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that search results contain nttId and that get_audit_case is needed for actual reasons and judgment bases, implying results are summaries. It also explains that keyword_variants increases recall, adding beyond the schema. The page-ignoring behavior for keyword_variants is not mentioned here but is in the input schema, so the description does not contradict nor fail to disclose any critical 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 two sentences, both purposeful. The first sentence front-loads the main purpose, and the second sentence efficiently covers the follow-up call and keyword_variants guidance. There is no fluff or repetition of schema details.

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 search tool with no output schema and 5 parameters, the description covers the essential flow: search, then use the returned nttId with get_audit_case for full details. It also addresses a specific edge case (approximate knowledge) and how to handle it. It does not describe the result list structure or pagination, but the schema provides parameter details, so the description is sufficiently complete for a non-destructive search operation.

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 80%, so the baseline is 3. The description adds genuine meaning to keyword_variants: when to use it, why (recall), and provides a concrete example with multiple search terms. This elaborates on the schema's description, which already detailed the parameter, but the main description makes the use case clearer, elevating it to a 4.

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 with a specific verb and resource: '금융감독원 심사·감리지적사례(회계처리 위반 지적 사례집)를 검색합니다' (searches FSS review/supervision noted cases). It also differentiates from siblings by immediately linking to get_audit_case, showing the follow-up workflow and peculiar use.

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 explicit context for when to use keyword_variants: '회사명·정확한 쟁점을 모르고 사건 내용만 대략 아는 경우' (when you don't know the company name or exact issue and only roughly know the case). It also advises to call get_audit_case with the nttId for full PDF details, giving a clear next step. However, it does not explicitly mention when not to use this tool or contrast it with alternative search tools like search_sanction.

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 full responsibility for behavioral disclosure. It reveals non-obvious behaviors: results include fullContent, a vintage_warning is appended when cited standards have been revised, and an automatic similar-term retry occurs on zero results. These details go well beyond a generic 'search' description, though it does not address safety or permission aspects.

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

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

The description is three sentences, front-loaded with the core purpose, followed by two sentences containing high-value behavioral details. No redundant or filler wording is present.

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 captures critical search-specific behaviors (fullContent inclusion, vintage_warning, auto-retry) and context (7 categories). It does not detail the full response shape, but no output schema exists and page/rows are defined in the schema, so the level of completeness is adequate for a 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 80% (page lacks a description, but types, keyword, rows, and standard_filter have detailed descriptions). The tool description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('검색합니다' = searches) and resource ('K-IFRS/K-GAAP 관련 질의응답' = Q&A), clearly distinguishing it from standard search tools like search_standards. The mention of 7 categories (회계기준원·금융감독원·IFRS해석위원회 등) further scopes the tool's purpose.

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 use for searching Q&A content but does not explicitly state when to use this tool over siblings like get_qna or accounting_search. No exclusions or alternative tool references are provided, leaving usage guidance 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 carries full behavioral disclosure. It warns that the search only provides '제재 확인 사실' not a definitive violation assessment, explains that keyword_variants causes multiple searches merged with page ignored, and informs that results contain the keys needed for detail retrieval. This is thorough and transparent.

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 concise, using a warning icon and clear formatting. Every sentence adds value: purpose, follow-up flow, interpretative caveat, and search strategy tip. No redundancy or fluff.

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 or annotations, the description covers the search scope, key result identifiers, follow-up tool, and a recall-maximization technique. It does not detail standard pagination behavior beyond keyword_variants, but given the tool's moderate complexity, this is a minor gap.

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 80%, but the description adds significant value beyond the schema by explaining the intended use of keyword_variants (parallel search for recall, page parameter ignored) and connecting the result fields to get_sanction. The start/end/page parameters are left to the schema defaults, which is adequate.

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: '금융감독원 검사결과제재(제재공시)를 검색합니다' (searches FSS examination sanctions). It distinguishes itself from the sibling get_sanction by explaining that search results provide exam_mgmt_no+em_open_seq for follow-up detail retrieval, and differentiates its search behavior with keyword_variants for improved recall.

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 explicitly tells when to use keyword_variants (when the company name/exact reason is unknown but the case details are roughly known) and how to proceed to get_sanction for full PDF details. It does not explicitly list alternatives to avoid, but the context is clear enough that this is the search tool, while get_sanction is for fetching details.

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 fully carries the behavioral disclosure burden. It discloses three non-obvious behaviors: automatic expansion of industry abbreviations, automatic synonym retry on zero results, and default exclusion of unapproved drafts. This goes well beyond the schema.

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

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

The description is concise and well-structured: it opens with the main purpose, then covers key behaviors and follow-up usage. Every sentence provides useful information without padding.

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 search tool with no output schema, the description provides sufficient context: it mentions the result contains stdNum, explains the zero-result retry behavior, and clarifies draft filtering. This is complete enough for an agent to invoke and chain 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?

Schema description coverage is 100%, so baseline is 3. The description adds semantic value by explaining that abbreviations in the keyword are automatically expanded to standard terms, and it echoes the include_drafts behavior. This extra context justifies a 4.

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 across standard types (K-IFRS, K-GAAP, etc.) and returns counts of keyword occurrences. It specifies the exact behavior (whole search, counts) and even provides follow-up tool guidance, distinguishing it from sibling search tools.

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

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

The description implies usage context clearly: use this to find which standards contain a keyword, then chain with get_standard_index or get_paragraph. It does not explicitly mention when not to use it relative to alternatives like search_qna, but the context is unambiguous.

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 burden of disclosing behavior. It explicitly states the data is stored locally at a specific path and not transmitted externally, plus clarifies the token selection rule. This provides useful context beyond the schema, though it doesn't address authentication or 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.

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

The description is two sentences, front-loaded with the primary purpose, and every sentence adds value. It avoids redundancy and is appropriately concise for the tool's simplicity.

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 covers the essential purpose, token semantics, and data handling. Given the tool's low complexity and schema coverage, it is sufficiently complete. It doesn't mention response behavior, but that's not critical for a feedback submission 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 100%, so the schema already explains all parameters. The description adds context about local storage and token usage, but doesn't significantly enhance parameter meaning beyond what's in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: leaving a rating and comment about the quality of MCP answers. It uses a specific verb (leaves) and resource (feedback), and the purpose is distinct from all sibling tools, which are search/verification tools.

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

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

The description implies when to use this tool (after receiving an answer, to rate its quality) and provides specific instructions on what to include in the tokens parameter (only _feedback_token actually used). It doesn't mention alternatives because none exist, so no exclusions are needed.

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 full burden. It discloses the core behavior (re-query and compare) and the anti-hallucination purpose, which is useful. However, it does not state whether the tool is read-only, what happens on mismatch, or any side effects. The description adds some context but lacks completeness for a tool with no annotation support.

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 concise sentences, front-loaded with the action and purpose. It avoids redundancy and earns every word, mentioning both the mechanism and the recommended usage scenario.

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 no output schema, the description should explain return values or match criteria, but it does not. It also has conditional parameters (standard vs qna) that are not explicitly explained in the description, though the schema covers them. The tool's complexity is moderate, but the description omits critical behavioral details like what constitutes a successful verification.

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 high (83%), so the baseline is 3. The description adds minimal value beyond the schema: it maps source parameter values to get_paragraph/get_qna, but the schema already explains the enum (standard/qna). Claim's requirement for exact quoting is also already in the schema, so the description does not meaningfully enhance parameter understanding.

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 re-queries and compares quoted sentences against K-IFRS sources (get_paragraph/get_qna), with a specific verb and resource. However, it does not distinguish itself from the similarly named sibling 'verify_citations', leaving ambiguity about whether it handles single vs. multiple citations.

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 suggests using this tool after writing reports for key citations, which gives a clear usage context. However, it does not explicitly mention when not to use it, nor does it differentiate from the sibling 'verify_citations' which likely overlaps in functionality. The alternative tools get_paragraph/get_qna are referenced only as data sources, not as alternatives.

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?

Without annotations, the description carries the full burden. It explains the core behavior (extract all citations and check existence) and batch processing, but does not disclose output format, side effects, or any safety profile. Since it's a verification tool, the risk is lower, but the lack of return-value or side-effect disclosure leaves a transparency gap.

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: the first explains the purpose and scope, the second provides usage conditions and an alternative. Every sentence contributes new information with no waste, and the alternative is tucked into a parenthetical for compactness.

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 tool with no output schema and no annotations, the description covers the purpose, usage timing, and alternative tool. It does not mention return values or error handling, but given the low complexity and strong schema, the description is nearly complete; only minor details about results are 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?

Schema coverage is 100% with a detailed parameter description ('the full text of the report/answer draft to extract and verify citations from'), so the schema already handles parameter meaning. The description adds only a slight nuance ('long text') but does not significantly exceed the schema, earning the baseline score of 3.

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

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

The description clearly states the tool's function: automatically extracting and batch-verifying K-IFRS standard/paragraph citations and Q&A document number citations from long text. It distinguishes itself from the sibling tool verify_citation by explicitly noting it handles batch verification vs single-citation content checks.

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 explicit when-to-use guidance: 'before outputting answers with 3+ citations or when accuracy is important.' It also names the alternative for single-citation content comparison ('verify_citation'), covering both inclusion and exclusion criteria.

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