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

No annotations are provided, so the description carries the burden of explaining behavior. It discloses that the tool aggregates several data sources into a single report and describes the return value. It does not mention side effects or limitations, but for a read-oriented report generator this is a reasonable level of 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 concise, front-loaded with the main purpose, and uses a clear Args/Returns structure. Every sentence adds useful information without unnecessary 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?

The description covers purpose, integration behavior, both parameters, and the existence of a return value; the output schema handles the detailed return structure. It is slightly incomplete in that it does not address sibling-tool tradeoffs or potential error/edge cases, but it is sufficient for a moderately complex analysis 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 provides no parameter descriptions (0% coverage), but the description fully compensates: topic is explained as a legislative issue/keyword with examples, and limit is defined as the number of related bills to search with a default value. This adds meaning well beyond the bare input 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 the tool's specific action: generating a comprehensive legislative analysis report on a given topic. It also enumerates the integrated components (bill search, bill details, committee minutes, key lawmakers), which distinguishes it from sibling tools like analyze_voting_trends or search_bills.

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 makes the intended use clear: providing a one-stop comprehensive analysis of a legislative issue. However, it does not explicitly mention alternatives or state when not to use this tool, so it stops short of full routing guidance.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses that it provides summaries of passage and vote stats, but does not disclose data source scope, time range, aggregation method, or whether results are limited to certain plenary sessions. It also does not mention what the output summary includes beyond vague 'recent bills'.

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 a clear definition and example. The Args section is a slight structural redundancy since it's already in the schema, but overall it earns its place by giving the example.

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

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

The output schema exists, so return values are covered. The tool is fairly simple (one param), but the description could be more complete regarding what 'recent' means, which bills are included, and how the trend analysis is computed. A 3 reflects the adequate but not thorough guidance.

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 topic parameter, and the description compensates well by defining topic as a subject/keyword and giving two concrete examples. This is enough for an agent to understand what to pass, though it doesn't specify format constraints (e.g., exact bill title vs keyword).

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 it analyzes plenary voting trends for bills related to a keyword, summarizing passage status and yes/no statistics. It distinguishes itself from sibling tools like get_bill_voting_results (which likely returns raw results) and analyze_legislative_issue (broader issue analysis), though it doesn't name the closest sibling 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?

The description implies use when one wants voting trend analysis by topic, and the sibling list shows alternatives like get_bill_voting_results and get_member_voting_history. However, it does not explicitly state when to choose this over those alternatives, nor does it specify limitations like recency or scope of bills covered.

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 adds meaningful behavioral context: the output is a normalized timeline of a specific event set, and the presence of confidence fields implies some data is scored rather than fully authoritative, which is useful for the agent. But it never states read-only safety explicitly, explains why confidence varies, or discloses behavior around the 'age' parameter, leaving the disclosure partial.

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 compact sentences with the primary function front-loaded and the sibling differentiation in the second sentence; there is no wasted or duplicated content. It loses a point only because the comparative phrasing ('기존 get_bill_history보다...') requires the agent to infer what the older tool lacks rather than stating it directly.

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 zero annotations and 0% schema parameter coverage, the description must carry the full context burden, and it leaves a notable gap: the 'age' parameter is entirely unexplained, and the when-to-use vs get_bill_history guidance is implicit rather than a crisp decision rule. The existence of an output schema mitigates return-value explanation, but an agent still lacks enough information to invoke the tool with full confidence.

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 the schema's silence on both parameters. It only implicitly maps bill_id to '특정 의안' (a specific bill) and says nothing at all about 'age' — an optional string parameter defaulting to null whose meaning (legislative term, data freshness, etc.) is completely ambiguous to an agent. The description does not adequately compensate for the missing 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 names a specific verb and resource: '특정 의안의 발의, 위원회 회부, 회의, 본회의 표결, 최종 처리 이벤트를 정규화된 타임라인으로 반환합니다' (returns a normalized timeline of a bill's introduction, committee referral, meeting, plenary vote, and final processing events). It explicitly distinguishes itself from the sibling get_bill_history by citing the added event_type/source_tool/confidence fields, so an agent can tell them apart 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?

The second sentence directly names the alternative (get_bill_history) and states the differentiator: it exposes event_type/source_tool/confidence fields to make LLM follow-up verification easier, which gives clear context for when to prefer this tool. However, it stops short of explicitly declaring when NOT to use this tool or the precise condition that would route an agent to get_bill_history instead, so it falls just below the 'explicit when/when-not' bar.

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

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

With no annotations, the description carries the full behavioral burden. It discloses pass-through behavior (no transformation), the UNIT_CD '1000xx' format trap, and the raw JSON string return. It does not mention auth, error behavior, or side effects, but for a read-style API caller the disclosed behaviors are useful.

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 longer than average but every block earns its place: purpose, usage procedure, format caution, and parameter definitions. The most important operational caveat (input passthrough and UNIT_CD) is prominent.

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 raw API gateway tool, the description covers the full invoke path: how to find the service ID, how to pass params, and what is returned. Since an output schema exists, the description does not need to enumerate response fields; still, a note on error behavior would make it fully complete.

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, and it does: service_id is explained with a concrete example and params is described as a JSON query string with example. The critical UNIT_CD format is explicitly called out, which is exactly the kind of semantic detail the schema omits.

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+resource: calls National Assembly OpenAPI directly, and clearly positions itself as the raw/low-level sibling to high-level tools like get_member_info and get_meeting_records. The 'universal backdoor' phrase and procedure make its role 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?

Gives explicit when-to-use: consider this route whenever the intended high-level feature is missing, and provides a procedure (list_api_services → get_api_spec → call here). It does not explicitly state when not to use it or which high-level tool should be preferred for a given case, 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?

No annotations are provided, so the description carries the behavioral burden. It transparently frames the tool as a safe, read-only guide retrieval operation using '반환합니다' and explains the content domain. Since there are no parameters, no mutation, and the output schema exists, the description sufficiently discloses the tool's behavior without omitting critical 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 exactly two sentences: the first states what the tool returns, the second states when an LLM should use it. It is front-loaded with the core purpose and contains no filler or redundant information.

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 zero-parameter reference guide tool with an output schema available, the description is complete. It explains the content of the guide, its relationship to call_api_raw, and the intended invocation timing. Nothing essential is missing for an agent to decide whether and when to call this 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 tool has zero parameters, so there is no parameter behavior to document. The baseline for zero-parameter tools is 4, and the description appropriately focuses on purpose and usage rather than inventing unnecessary parameter detail.

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

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

The description clearly states that the tool returns a guide for code values commonly used in the National Assembly API, with concrete examples such as 대수 and 처리상태. It also distinguishes itself from call_api_raw by framing itself as the pre-call reference for deciding parameter values, so an agent can identify its role among the sibling 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 explicitly says to consult this tool before calling call_api_raw when determining parameter values. This gives a clear and actionable usage trigger. It does not enumerate exclusions relative to other reference-type siblings like get_api_spec, but the primary use case is well specified.

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 and does it well: it explains that the tool returns full parameter constraints, fetches one real data record for preview, and generates parameter hints from actual data. It does not discuss error conditions, permissions, or rate-limit effects of the data preview, but the core read behavior is 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 well-structured with '기능', '워크플로우', 'Args', and 'Returns' sections, making it easy to scan. The main purpose is front-loaded, and the workflow and feature details are directly actionable with little 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 one required parameter, an output schema, and no annotations, the description supplies all essential invocation context: parameter semantics with an example, return summary, and an explicit workflow connecting sibling tools. Missing edge-case details are not critical for this read-oriented lookup tool.

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

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

The input schema only says service_id is a required string with 0% schema description coverage. The description compensates by labeling it as the service ID and giving a concrete example ('O4K6HM0012064I15889'). It does not provide format rules or constraints beyond the example, but for a single parameter this is sufficient.

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 '특정 API 서비스의 상세 스펙을 조회합니다', naming a specific verb and resource, then lists endpoint URL, request parameters, and response structure. It also distinguishes itself from high-level tools by saying it is useful when dynamically exploring API details that high-level tools do not provide, which separates it from siblings like list_api_services and call_api_raw.

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?

An explicit three-step workflow is provided: use list_api_services to find the service ID, call this tool for parameter details, then use call_api_raw. It also states that it is useful for dynamic API exploration. It does not spell out an explicit 'when not to use' condition, but the workflow gives strong contextual 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?

The description does disclose that this tool returns basic server status, which is a behavioral trait. However, it spends most of its text on meta-advice and a broad API-access workflow, so the transparency is muddled. No annotations are present, so the description carries the burden but only partially clarifies 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 poorly structured: it starts with a generic instruction block, includes a bold directive against saying features don't exist, and only at the end mentions what the tool actually returns. The text is longer than needed and buries the actual 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?

For a zero-parameter tool with an output schema, the description could simply state the server status fields. Instead, it conflates tool-level instructions with system-level guidance, leaving the agent uncertain about the tool's actual purpose and relationship to siblings.

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 0 parameters, so parameter semantics are essentially moot. The schema already makes this clear with an empty properties object. The description adds a bit of context by mentioning 'basic server status', which is enough for a zero-parameter tool.

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 is internally contradictory. The tool name is 'get_assembly_info' and it says 'Returns basic server status', but the description mostly contains a meta-guide about using the full 270+ National Assembly OpenAPI via list_api_services → get_api_spec → call_api_raw. It does not clearly state a distinct purpose, and it reads like a system prompt rather than a tool description.

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 provides some usage guidance ('don't say this feature doesn't exist', use the combination workflow), but it does not clearly specify when to call get_assembly_info versus siblings. It actually introduces a separate workflow for other tools without tying it to when this specific tool should be used.

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 disclosure burden. It discloses that the result includes MAJOR_CONTENT and PROPOSE_REASON, and that null is returned when no bill is found. This is sufficient transparency for a simple read-only lookup, though it doesn't discuss errors or rate 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 description is well structured with a purpose statement, usage steps, argument explanations, and return behavior. Every section earns its place and nothing is redundant or 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 output schema exists, the description doesn't need to detail return fields extensively. It provides the required workflow, parameter semantics, and null behavior, making it complete for an agent to call 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 0%, so the description must compensate. It clearly explain that bill_id accepts either an ID like PRC_... or a number like 2200001, and that age is an optional assembly term. This adds meaning beyond the raw schema fields.

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 it retrieves detailed information for a specific bill and lists key contents (MAJOR_CONTENT and PROPOSE_REASON). It identifies a distinct resource and action, but doesn't explicit differentiate itself from sibling tools like get_bill_history.

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 an explicit workflow: use search_bills first to obtain the bill ID, then pass it to this tool. It give clear context for when to use it, though it doesn't mention exclusion or when a sibling would be more appropriate.

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 burden. It reveals useful behavioral traits: it consolidates multiple major events including meetings, and it orders them by date (날짜순). It also implies a read-only operation without saying so. However, it does not disclose output size limits, pagination, or whether the returned data is limited to major events only, which could matter for an agent deciding whether this tool satisfies a query.

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 Korean description is compact: two sentences of behavior and then a concise Args section. The main behavior is front-loaded in the first sentence, and the parameter explanation is short. No filler or repetition. It loses one point because the Args line is somewhat redundant with the schema (bill_id appears both places), but it earns its place by adding the format alternatives. Overall, every sentence contributes.

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 an output schema present and the tool has a single parameter, so the description need not explain return values in detail. It explains what it returns (all major history including meetings, ordered by date), which is the key behavior an agent needs. Gaps are minor: no mention of page size, date range limits, or whether 'major history' excludes certain event types. Still, for a read-oriented lookup with one parameter and an output schema, it is sufficiently complete.

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 only declares bill_id as a string with no description, and schema coverage is 0%, so the description must compensate. The description does so by explaining bill_id can be either an 의안 ID like 'PRC_...' or a 의안 번호 like '2200001', and gives a realistic example. That is genuinely useful semantic information beyond the schema. It would be even better if it clarified how to distinguish the two formats or what happens if an invalid ID is provided, but for one parameter it is quite 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 a specific verb ('통합하여 조회합니다' — integrates and retrieves) and resource (특정 의안의 모든 주요 이력). It also specifies the exact scope: '발의부터 현재까지' and '회의 포함', which distinguishes it from sibling tools like get_bill_voting_results, get_bill_details, or bill_timeline. Even without reading schemas, an agent can infer it returns a chronological consolidated history of a bill rather than a single detail.

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 explains the tool is useful for '타임라인 생성이나 연혁 분석' (timeline creation and history analysis), giving a clear usage context. It does not explicitly list when NOT to use it or name alternative sibling tools, so it misses the full when/when-not guidance. But the use-case hint is enough to route an agent appropriately among the many legislative 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?

With no annotations, the description itself must convey behavioral traits. It communicates the scope (본회의/plenary) and the output aggregation by party, which is useful. However, it does not disclose potential limitations like missing data for certain bills, input format requirements beyond the example, or any errors, leaving some behavioral ambiguity.

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 single sentence states the purpose and output scope, followed by a one-line parameter definition. Every sentence earns its place without wasted text.

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 one-parameter query tool with an output schema present, the description covers the essential input (what bill_id is and its format) and the core output content. It does not explain selection criteria versus siblings, but that gap is already accounted for in usage_guidelines.

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?

Although the schema has no description for bill_id (0% coverage), the tool description directly explains it as the bill ID and provides a concrete format example ('PRC_...'). This meaningfully compensates for the empty schema and is sufficient for the single 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 clearly identifies the action (조회한다/query) and the resource (본회의 표결 결과 for a specific bill, including yes/no/abstention counts and party voting tendencies). It is specific and likely distinguishable from siblings like get_member_voting_history, but it does not explicitly name or differentiate against those 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?

The description provides no guidance on when to use this tool versus alternatives such as analyze_voting_trends or get_member_voting_history. There is no mention of use cases, exclusions, or conditions that would route an agent to this tool over a sibling.

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, but it only says the tool 'retrieves' data and lists arguments/returns. It does not explicitly state read-only behavior, what happens when both committee_name and committee_code are omitted or passed together, or any auth/rate-limit constraints.

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

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

The description is short and front-loaded with the core purpose, and the Args section is tidy. The Returns sentence is nearly an exact repetition of the first sentence, which is mild redundancy, but otherwise every line 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?

The tool is simple and has an output schema, so the description covers the basic call signatures. However, it leaves open how the optional parameters interact (e.g., committee_name + committee_code together, or neither) and provides no guidance on list vs. detail selection conditions.

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%, and the description fully compensates: it gives each parameter a Korean label, provides an example for committee_name, specifies the code format (HR_DEPT_CD), and explains page/limit meaning. This is well 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 uses a specific verb ('retrieves') and names the resource (committee info), and it distinguishes two modes: list vs. specific committee with member roster. It is clear, but it does not explicitly differentiate the tool from sibling tools like get_committee_work_summary.

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?

There is no guidance on when to use this tool versus alternatives; no alternative tools are mentioned and no exclusion criteria are given. The agent must infer from the description alone that this is for committee list/detail lookup, with no comparison to 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?

There are no annotations, so the description carries the behavioral burden. It does add context by saying it maps related data between entities and provides objective information, and the verb '조회' implies a read-only query. But it does not state side effects, failure behavior, or what the mapping process entails beyond that brief phrase.

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: two purpose sentences plus one parameter explanation. The main function is front-loaded, and there is no filler, repetition, or irrelevant 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?

For a single-parameter query tool with an output schema, the description covers the core needs: what it returns, the input meaning, and the tool's general behavior. It omits edge-case or failure-mode guidance, but at this low complexity that is not a critical 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 description coverage is 0%, so the description must compensate. It does: the Args section names committee_name, defines it as '위원회명', and gives concrete examples such as '법제사법위원회' and '환경노동위원회'. This adds real meaning beyond the bare string type, though it is not exhaustive about constraints.

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: retrieving a specific committee's current activity status (pending bills, related reports, etc.). It is distinct from siblings like get_committee_info in function, but it does not explicitly name or contrast alternatives, so it stops short of a 5.

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 'current activity status... at a glance' implies a summary use case, so an agent can infer when to call it. However, there is no explicit when-to-use/when-not-to-use guidance and no reference to sibling tools such as get_committee_info or get_legislative_reports.

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 must carry the behavioral burden. '조회합니다' indicates a read-only search action and the limit parameter clarifies result-count behavior, but the description does not disclose ordering, pagination, error behavior, or any access limitations.

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 purpose-first: one sentence for scope, one for use case, and a short Args list. Every sentence contributes without 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?

Given only two simple parameters and an output schema, the description covers purpose, use context, and parameter semantics sufficiently. It could be more complete by mentioning ordering or filtering behavior, but nothing essential is missing for a straightforward keyword search.

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%, but the description's Args section defines both parameters: keyword with example values ('종합부동산세', '인공지능') and limit as result count with default 5. This adds practical meaning beyond the bare schema types.

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 ('조회합니다') with a concrete resource: National Assembly professional reports (e.g., NABO Focus) and news related to a topic or bill. It also clarifies the distinguishing value ('전문가의 분석 시각'), though it does not explicitly name sibling tools to differentiate from.

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 a clear context for use: '단순 법안 정보를 넘어 전문가의 분석 시각을 제공할 때 유용합니다.' This tells an agent when the tool is valuable, but it does not explicitly state when not to use it or name concrete 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 behavioral disclosure burden. It explains that the tool returns guidance, naming rules, compatibility policy, and failure-marker meanings, making its informational nature clear. It does not explicitly state that it has no side effects, but the read-only introspective role is strongly implied.

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

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

The description is front-loaded with the tool's core purpose and then uses three focused bullet points to enumerate the returned content. Every sentence adds useful information 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?

The description is complete for an onboarding/meta tool: it explains the tool's purpose, what it returns, and the key categories of information an agent will receive. Since an output schema exists and there are no parameters, the description gives sufficient context for correct invocation and expectation-setting.

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%, so there is no parameter documentation burden on the description. The description correctly implies a parameterless invocation by describing it as an entry-point tool that returns a contract.

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 and resource: it returns the public tool surface and workflow contract for LLM clients first calling AssemblyMCP. The three bullet points further specify exactly what this includes, distinguishing it from data-fetching siblings like get_bill_details or search_bills.

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 states this is for an LLM/client calling AssemblyMCP for the first time, which is a strong context signal for when to invoke it. It does not explicitly name alternatives such as get_api_spec or list_api_services, but the onboarding purpose is clear enough.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the return type ('list of member information') and implies a read-only lookup via 'search'. However, it does not mention potential multiple matches, exact-match requirements, error behavior, or any limitations. This is acceptable for a simple lookup but leaves some behavior uncovered.

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 concise, front-loaded with the primary action, and organized with Args/Returns sections. Every sentence contributes useful information 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 single-parameter lookup tool with an output schema available, the description covers the essential aspects: what it does, when to use it, the parameter meaning, and the return shape. The presence of an output schema means return details need not be duplicated. Minor gaps like handling of identical names or required-field errors remain, but they are not critical for correct use.

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 the bare 'name' string parameter. It does so by defining 'name' as the member name and providing an example ('홍길동'), which is clear and actionable. It could add details like whether partial names are accepted, but the example and Semantics are sufficient for correct invocation.

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: it searches detailed National Assembly member information. It also gives concrete use cases (sponsor, party, constituency), which clearly convey the tool's purpose. However, it does not explicitly differentiate from sibling tools like get_member_voting_history or get_committee_info, so it stops short of a 5.

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 the tool: 'when identifying who the sponsor is, affiliated party, constituency, etc.' This gives an agent a direct cue for selecting it. It does not mention similar alternative tools or state when not to use it, so it 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?

No annotations are provided, so the description carries the burden. It does reveal that this is a read-only lookup ('조회') and that limit caps at 100, which is useful. However, it does not describe behavior when both name and bill_id are provided, when neither is provided, or what shape of data is returned beyond the existence of an output schema.

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

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

The purpose is stated in one sentence, and the Args list is compact and front-loaded. Each line earns its place. The format is slightly redundant with the parameter names, but it is still efficient and readable.

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 two common query modes and all parameter meanings, but leaves an important gap: all parameters are optional in the schema, yet the description never states whether at least one of name or bill_id must be provided. It also does not mention pagination limits beyond the limit parameter, but the outpt schema helps retern.

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%, and the description fully compensates. Each parameter gets a Korean explanation with usage context: name for a member's history, bill_id for who voted how on a bill, age for assembly session, and page/limit for pagination with max 100. This is more meaningful than the schema alone.

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

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

The description clearly states that the tool retrieves a legislator's plenary voting record or a specific bill's individual member voting status. The verb '조회합니다' and the resource '표결 기록/표결 현황' are specific. It does not explicitly distinguish itself from sibling tools like get_bill_voting_results, so it misses a point for sibling differentiation.

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 Args section gives useful context for when to use name vs bill_id, but this focuses on parameter selection rather than tool selection. It never mentions alternatives among siblings or states when not to use this tool. Usage context is present but not complete.

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 and it adds meaningful context: empty results are frequent, and queries can be broadened by changing or omitting unit_cd. It also notes that omission may return all records. It does not mention auth or rate limits, but for a get-style lookup with an output schema, the disclosed quirks are sufficient.

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, front-loaded with the main action, and followed by a brief behavioral caveat and parameter list. There is some redundancy—unit_cd appears twice—and the Service ID is low-value noise, but overall the structure is easy to scan.

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 3-parameter read-only schedule lookup with an output schema, the description covers every parameter and the main data-absence quirk. It is complete enough for an agent to call correctly, though it could more explicitly indicate when to choose this tool over sibling search or meeting 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 0% and the schema only provides types and defaults, so the description must compensate. It does so by explaining unit_cd as '대수' with an example, describing omission behavior, and labeling page/limit as pagination controls. The page/limit explanations are minimal but 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 opens with '본회의 일정을 조회합니다' (queries plenary session schedule), which clearly states the tool's verb and resource. It identifies a specific object—plenary schedule—but does not explicitly compare itself with sibling tools like search_meetings.

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 practical guidance: unit_cd is important, empty results are common, and users should try changing or omitting unit_cd when no data is returned. However, it does not state when to prefer this tool over alternative schedule or meeting tools, so the selection context remains implied.

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?

There are no annotations, so the description carries the burden. It says the tool 'provides' a report, which implies a read/compute operation without side effects, and it enumerates report contents. However, it does not explicitly state that it is safe, non-mutating, or describe behaviors like caching, rate limits, or failure handling.

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 well-structured: it leads with the core purpose, then lists report components, then documents the parameter with an example. There is no redundant restatement of schema information.

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 one-parameter report tool with an output schema present, the description sufficiently explains what the tool does, what the report contains, and what input is required. It does not discuss not-found or error behavior, but the output schema covers return structure, so nothing essential for tool selection 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 input schema only defines member_name as a string, so the description's '국회의원 성명 (예: "추경호")' adds essential semantic meaning and a concrete example. It could additionally explain exact-name matching or disambiguation, but for the single parameter the description 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 generates a comprehensive legislative activity report for a specific National Assembly member and lists the exact content areas included. The phrase '한 번에 제공합니다' distinguishes it from narrower sibling tools like get_member_info or get_member_voting_history.

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 when a consolidated overview of a member's activities is needed, but it does not explicitly say when to prefer this tool over sibling tools or exclude cases like looking up a single voting history. The usage context is inferable but not explicit.

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 sub-query failures are preserved as [PARTIAL] warnings, which is a useful behavioral trait. However, it does not state whether the operation is read-only, mention potential latency or rate limits, or describe what happens on total failure. The partial-failure note adds some transparency but not full behavioral coverage.

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

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

The description is two short sentences. It front-loads the main purpose and then lists the combined data sources and the partial-failure behavior. Every sentence adds value, with no fluff. It is well-structured and efficient.

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 tool's high-level function and partial-failure handling, and an output schema exists to define the return format. However, it does not explain the parameters or clarify jurisdictional scope (though 'National Assembly' implies Korea). Given the complexity of a workflow tool and the lack of parameter documentation, more detail is needed for full completeness.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It only implicitly references 'topic' via 'legislative topic' but does not describe the 'age' or 'limit' parameters at all. Their purpose (likely filtering by age and result cap) is left entirely to inference. This is a significant gap for a tool with undocumented 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 generates a 'workflow-type brief' on a legislative topic and enumerates the data sources it combines (bills, committees, schedules, reports, voting signals). This distinguishes it from single-purpose siblings like get_bill_details or search_meetings, which focus on one data type. The purpose is specific and actionable.

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?

No explicit guidance is given on when to use this tool versus alternatives. The description does not mention scenarios where a user should prefer a specific sibling tool (e.g., 'use get_bill_details for a single bill'). The usage context is only implicitly that this is for a comprehensive brief, but no exclusions or alternative routing are provided.

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 must carry behavioral disclosure itself. It does reveal the output shape (nodes, edges, mermaid, top_followups) and the supported target_type values, which helps. However, it does not clarify read-only behavior, how target_type=auto resolves, or any limits/edge cases, so behavioral disclosure is partial.

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

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

Two sentences with no filler; the core purpose is front-loaded and the result structure is given compactly. It is appropriately short, though the brevity comes at the cost of parameter semantics.

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 annotations and a 0%-described input schema, the agent lacks enough to invoke correctly: target format is unspecified, target_type values are not explained, and limit/age semantics are absent. The output keys in the description help, but the required input contract is incomplete.

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%, and the description only adds that target_type supports auto/topic/bill, without defining what each value means or what format target should take. It adds nothing for the required target, limit, or age parameters. This is insufficient compensation for a schema that provides zero 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?

States a specific verb ('generates') and resource ('relationship graph of bills, committees, legislators, reports, voting signals') centered on a topic or bill. The graph output makes it structurally distinct from sibling search/detail tools, but it never names a sibling or an alternative, so differentiation is implicit rather than explicit.

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?

No guidance on when to choose this tool over siblings like analyze_legislative_issue, search_bills, or analyze_voting_trends. It only lists target_type values, leaving the agent to infer the right context from the tool name.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly signals a read-only search operation, states the matching scope (service name or description), and describes the return items as containing id, name, and description. It does not mention default-keyword behavior or pagination, but the operation is a simple search and the description is sufficiently 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 compact and well-structured: a one-line summary, a short actionable workflow list, then Args/Returns. Every sentence adds useful information, with no filler 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 simple one-parameter discovery tool, the description provides enough context: what it searches, how to use the results, and what the return items contain. The presence of an output schema reduces the need to detail return structure. A minor gap is the unspecified behavior when keyword is empty/default, but overall the tool is adequately contextualized.

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%, but the description fully compensates by explaining the keyword parameter: 'Keyword to search in service name or description.' It also enriches usage by advising broad keyword attempts, including Korean/English and partial substring matching. With a single parameter, this is complete semantic 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 opens with a specific verb and resource: '모든 OpenAPI(총 270여 개) 메타데이터를 검색합니다' (searches metadata for all ~270 OpenAPIs). It also differentiates this tool from high-level tools by framing it as the low-level fallback for finding service IDs, making its purpose 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 gives explicit guidance on when to use it: '고수준 툴에 없다고 끝내지 말고, 여기서 서비스 ID를 찾은 뒤 get_api_spec → call_api_raw로 직접 호출하세요.' This states the condition, the action, and the follow-up workflow. It also adds practical search strategy by telling the agent to try Korean/English, spacing variants, and partial substrings.

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 burden. 'Check if server is alive' clearly indicates a non-mutating status check, but it does not specify what 'alive' means (e.g., reachability, response time, HTTP status) or note any access 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 a single, front-loaded sentence with no filler. 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?

For a parameterless health check with an output schema, the description is nearly complete. It only lacks a brief note on when to use it relative to the surrounding data 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?

The tool accepts zero parameters, so parameter documentation is moot; the baseline of 4 applies because there is no schema information the description needs to supplement.

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 clear action and target: 'Check if server is alive.' This is specific enough to distinguish it as a health-check tool from the legislative data siblings, though it does not explicitly contrast with any sibling.

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?

There is no guidance on when to call this tool versus alternatives, no mention of using it before other API calls, and no exclusions. The description implies a connectivity check but leaves the decision context unstated.

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 transparency burden. It does disclose important non-obvious behaviors: returning an empty array for no results and the automatic fallback to a previous assembly term. However, it does not address read-only nature, rate limits, permission requirements, or any side effects, leaving some behavioral uncertainty.

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 well-structured with separate sections for 기능, Args, and Returns, and it front-loads the main purpose before detailing parameters. Each bullet and parameter listed earns its place, and the length is justified by the eight optional parameters and four usage modes. There is minimal 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?

Because an output schema exists, the description does not need to explain return value structure. It covers the main invocation modes, parameter semantics, and the empty-array behavior, which is enough for a search tool. Remaining gaps include no examples of valid proc_status values and no explicit routing to sibling detail tools, but the overall context is adequate.

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 0% description coverage, so the Args section in the description is the sole source of parameter meaning. It explains all eight parameters, including that keyword refers to bill title, bill_id accepts either unique ID or bill number, propose_dt uses YYYYMMDD, and proc_status is a processing status code. This fully compensates for the schema 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?

The description opens with a specific verb-resource pair, '의안을 검색하거나 목록을 조회합니다', and identifies the tool as an integrated search tool for bills. It clearly enumerates four search modes, making the core purpose unmistakable. It does not explicitly name sibling alternatives, but the resource and action are specific enough to distinguish it from detail/history 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 four numbered call modes provide explicit guidance: keyword-only, filter combinations, no-params latest list, and automatic fallback from the 22nd to the 21st assembly. This goes well beyond a vague 'use for searching'. It lacks explicit 'when not to use' or pointers to alternatives like get_bill_details, but the usage context is clear.

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

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

The description discloses that the tool returns a list of minutes and schedules ('회의록 및 일정 목록'), which is useful behavioral context. However, with no annotations available, the description does not fully carry the burden: it omits details such as read-only nature, authentication needs, default date-range behavior, or pagination edge cases. For a simple search tool this is acceptable but not comprehensive.

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 well-structured with an introductory sentence, Args block, and Returns block. It is appropriately sized for the tool and every line adds value. There is no padding 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?

The description is complete enough for a caller to invoke the tool correctly: all parameters are explained, defaults are stated, and the return type is summarized. An output schema exists, so detailed return fields do not need to be enumerated. It lacks contextual guidance about alternatives, but that is a separate dimension.

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, and it does. Every parameter is described with meaningful detail: bill_id has an example, committee_name has an example, date parameters have an explicit format, and page/limit have default values. This far exceeds what the schema alone provides.

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 for committee meeting information ('위원회 회의 정보를 검색합니다') and lists relevant filters. It is a clear action+resource statement, though it does not explicitly differentiate itself from sibling tools such as get_plenary_schedule or get_committee_info.

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?

No guidance is provided about when to use this tool versus alternatives. There is no mention of when this should be preferred over related tools, nor any exclusion conditions or complementary use cases.

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 and does well: it discloses accepted input formats, automatic sequential checking of bill/member/committee candidates, and the exact failure markers ([NOT_FOUND], [AMBIGUOUS], [VERIFY_FAILED], [API_FAILED]). It does not mention rate-limit or side-effect details, but the tool is inherently a read-only verification and the API_FAILED marker covers external dependency.

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 organized: one purpose line, a labeled input-format list with examples, and a brief failure-behavior note. Each piece earns its place, though the multiple examples add a little length over a pure one-liner.

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 input formats and failure markers, and an output schema exists to carry the return shape, but it leaves age and limit unexplained and gives no success-path description. An agent could call it correctly for simple text input but would be guessing on the optional parameters.

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 parameter semantics rest on the description. It gives concrete examples for the required citations_or_text parameter (JSON array, JSON object, plain text) but never explains the age and limit parameters. This partial compensation is useful but incomplete.

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 and resource: it verifies claims or citations about bills, members, committees, and votes against National Assembly OpenAPI data. This clearly distinguishes it from sibling retrieval/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 first line establishes the intended scenario—there is a legislative claim or citation to check—and the input-format section tells the agent how to package citations. It does not explicitly name alternatives or state when-not-to-use, but the verification purpose supplies clear context.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It explains that the tool returns an action plan and a list of next MCP calls rather than performing legal analysis. This is meaningful transparency about output type, though it does not specify whether the tool itself executes those calls or if any side effects occur.

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 function, and the second adds a valuable clarification about non-legal output. No unnecessary repetition or filler 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?

For a simple generative tool, the description covers purpose and output type, and the output schema presumably handles return-value documentation. However, parameter semantics for 'age' and 'limit' are missing, and there is no explicit guidance on selecting this tool over siblings. The description is adequate but not fully complete.

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 the missing parameter documentation. It mentions '특정 입법 주제' which maps to the 'topic' parameter, but it provides no guidance about 'age' or 'limit'. Since two of three parameters are completely unexplained, the description only partially compensates.

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 action ('generates an action plan and list of next MCP calls') and a specific subject ('track changes on a specific legislative topic'). It also disambiguates itself from legal advice by clarifying it returns a monitoring procedure. This makes the tool's purpose very clear.

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

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

The primary usage context is explicitly stated: use this for tracking changes on a specific legislative topic. The description does not name alternative sibling tools or explicitly say when not to use it, but the purpose-driven framing gives solid guidance. The note about not being legal advice also helps set expectations.

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