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

With no annotations, the description does the heavy lifting: it discloses list ordering (최신순), that body calls return extracted PDF text, that long bodies must be continued via next_offset, that find returns offset plus surrounding context and ignores whitespace, and that one dataset is date-limited to 2001–2015. It does not cover permissions, failure behavior, or what list entries actually contain, so it is strong but not complete.

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?

Every clause carries new information and there is no filler; the parameter-driven behaviors are front-loaded in the first sentences. The prose is a dense run-on with several ideas packed into single sentences, which costs some scannability but not content.

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 9-parameter, no-annotation, no-output-schema tool, the description explains the two calling modes, both enums, the paging mechanism and the search helper, which is enough to call it correctly. It never describes what a list item returns (fields, IDs), leaving the agent to infer the r-/c- prefixes from the schema's doc_id note.

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%, so the baseline is 3, and the description genuinely adds meaning on top: kind's two values are explained with coverage and contents, doc_id's list-vs-body switch is stated, section=corrections is defined, and find/next_offset semantics are explained. Remaining parameters (year, query, limit, max_chars) are left entirely to the schema, so it falls short of a 5.

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 resource (국정감사 문서) and immediately splits it into two concrete modes (kind=result vs kind=correction) with the contents of each spelled out. It does not name any sibling tool (assembly_search, assembly_bill_reports, assembly_publications), so an agent cannot tell from this text alone which sibling to prefer, which keeps it at 4 rather than 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?

It gives explicit mode-selection rules: call without doc_id to get a newest-first list, with doc_id to get PDF body text, use section=corrections to jump straight to the correction/action section, and use find to locate terms like member names. It also warns that correction reports only exist for 2001–2015 audits, a real usage precondition. What is missing is any comparison against alternative sibling tools for overlapping needs (e.g., general search).

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 at all, the description carries the full behavioral burden and does disclose a genuinely important edge case: when the alternative cannot be matched by committee and processing date, the 'alternative' field degrades to a guidance string rather than data, and the agent must switch strategies. It never states read-only/no-side-effect status or how a missing bill is signalled, which is the remaining 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?

Front-loaded with the returned content before the conditional edge cases, and no sentence is redundant. The alternative-matching sentence is dense with nested parentheticals and reads closer to implementation detail than agent guidance, but it does justify why a lookup can fail.

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

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

With no output schema and no annotations, the description must describe the return shape, and it does so field by field while also handling the alternative-bill cases. The one real omission is that both parameters are optional in the schema yet the description never says at least one identifier is needed, leaving an agent able to call it with no arguments.

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% (bill_id as 의안ID/PRC_…, bill_no as 의안번호), so the schema already does the parameter work. The description only indirectly touches parameters, via the note that votes are keyed on the alternative's bill_id, and says nothing about when to prefer bill_id over bill_no or what happens if both are omitted.

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 resource and enumerates its contents (stage-by-stage dates/results, proposal reason, proposer list ordered with the lead sponsor first, committee deliberation meetings), so an agent knows exactly what a successful call yields. It never explicitly contrasts itself with the sibling assembly_bills list tool, which is what keeps it from 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?

It gives concrete downstream routing: for a vote, call assembly_votes with the alternative bill's bill_id, and if the alternative lookup fails, fall back to assembly_bills with proposer_kind=위원장. What it doesn't state is the primary selection rule (fetch details for one bill here vs. list/search bills in assembly_bills).

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 does disclose useful traits: text is PDF-extracted, long bodies are chunked and continued via next_offset, and 검토보고서 is a 전문위원 issue/pro-con analysis (a substantive quality signal about the content). It does not state whether offset beyond the end is an error, whether metadata/links are returned alongside text, or how bill_id vs bill_no interact.

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?

Four dense sentences, each carrying distinct information (what is listed, what 검토보고서 is, how to continue, how to handle 대안), with the core purpose front-loaded. No filler, though the verbless opening sentence costs a little immediate clarity.

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?

No output schema and no annotations mean the description must be self-sufficient, and it covers document types, PDF extraction, and pagination. It remains silent on how bill_id and bill_no are expected to combine (zero required params, so at least one is presumably needed), what the listing response looks like, and when the body is truncated. Adequate but with clear gaps for a five-parameter tool.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it explains what 검토보고서 actually contains, ties next_offset to the offset parameter for continuation, and warns that 대안 must be re-fetched via original_bills' 의안번호. The one blemish is naming the field 'next_offset' while the schema parameter is 'offset', which could momentarily confuse an agent.

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 the exact resource (의안 첨부 문서 목록 + 선택 문서 본문) and enumerates the document types returned (의안원문, 검토보고서, 심사보고서, 체계자구검토보고서) along with the format (PDF/HWP 링크, PDF 추출). It is specific enough to distinguish from generic bill tools, though it never names a sibling like assembly_bill_detail to draw the boundary. The first sentence lacks an explicit verb, which slightly blurs the 'what it does' framing.

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

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

Usage is implied rather than stated: the reader infers this is the tool for reading a bill's attached documents, and the last sentence routes 대안(위원회안) lookups back through original_bills' bill number. There is no explicit 'use this instead of X when Y' statement versus assembly_bill_detail or assembly_bills. The doc/offset guidance is deferred to the schema rather than restated as when-to-use advice.

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 exist, so the description carries the full burden, and it does disclose the two highest-risk behaviors: a silent default scope filter that hides chairman and government bills, and the fact that the 'total' figure ignores the from/to period. Remaining gaps are output shape and pagination semantics.

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?

Five short sentences, each front-loaded with a distinct fact: scope, sort order, default filter, escape hatch, and the total caveat. Nothing is repeated from the schema and no sentence is 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?

With 8 optional parameters, no annotations, and no output schema, the description covers search semantics and the main filtering trap well. The one real omission is return-value shape (what a bill record contains), which an agent cannot get from an absent output schema.

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

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

Schema coverage is 100%, so baseline is 3, and the description earns above baseline by explaining proposer_kind's listing source and the automatic '…위원장' detection that links proposer to proposer_kind. It also clarifies that from/to do not affect total, which the schema does not say.

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

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

States a specific verb and resource ('제22대 법률안 검색') plus scope and ordering, so an agent immediately knows this is a search/list endpoint for 22nd-Assembly bills. It does not explicitly contrast itself with the sibling assembly_bill_detail, but the search-vs-detail split is inferable from naming and behavior.

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 concrete usage rules: default returns only member-proposed bills, and chairman/government bills require proposal_kind (with an auto-detect fallback when proposer ends in '…위원장'). That is a clear when-to-use path, though no sibling alternative is named for drilling into a specific bill.

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 so well: it discloses the ~1-week publication lag, the audit-specific behavior (list appears first, full text later), and the data quirk that audit minutes have class '국정감사 회의록' with empty agenda fields. This is exactly the context an agent could not infer from structured fields.

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

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

Three sentences, front-loaded with the resource and return shape, then the edge cases. Every sentence carries information, though the parenthetical about audit publication lag is dense enough to slow reading slightly.

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?

No output schema and no annotations, so the description must explain returns and it does (grouped by confer_num with agendas). Combined with a fully documented schema this is nearly complete; only the semantics of committee filtering are left unstated.

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%, so the schema already documents from, to and committee including the 62-day range error. The description only implies date-range filtering and adds no syntax or semantics for the committee filter, so baseline 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?

Names a specific resource (위원회 회의록 목록) and states exactly what is returned: meetings in a date range grouped by confer_num together with agendas. It also distinguishes itself from the sibling assembly_speech_clips, so an agent can route correctly without opening a schema.

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

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

Explicitly routes the agent to assembly_speech_clips for recent meetings, with the reason (minutes are published ~1 week later, and for audits only the list appears first). It gives clear positive usage context but does not mention the other near sibling, assembly_meeting_speeches.

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 and does disclose key behaviors: already-indexed items are skipped (idempotent), force re-indexes, and the meetings range is capped at 62 days — the latter is not in the schema. It omits permissions/auth and any return 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?

Front-loads the overall purpose, then packs each action into a compact clause with no wasted prose. Dense but well-organized around the action enum.

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 7-param, multi-action tool with no annotations and no output schema, it explains each action and its scoping constraints (62-day cap, skip/force, default today). Slightly incomplete on what status returns in structured terms, but overall 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?

Schema description coverage is 100%, so a baseline 3 applies. The description reinforces which params map to which action (meetings dates, captions date/xcode, committee name), but adds little syntax or default 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?

States a specific verb+resource (manage the local search index) and enumerates three distinct actions (status, meetings, captions) with what each does. It is clearly a management/indexing tool, distinguishable from read-oriented siblings like assembly_search.

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?

Each action's role is explained and it notes that other tools (meeting minutes, captions, reports) already auto-index, which signals when manual indexing is/isn't needed. It stops short of explicitly contrasting with assembly_search or stating when to prefer manual over automatic.

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 behavioral burden, but it only says this is a current live list. It does not disclose permissions, pagination, return shape, or what only_live defaults to.

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 or repetition. Every word contributes to identifying the resource and listing behavior.

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 list tool with one optional parameter and full schema coverage, the core purpose is adequately conveyed. However, without annotations or an output schema, more context about the result shape or behavior would help.

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 single optional parameter is already documented in the schema. The description adds no additional meaning about only_live, but with full schema coverage the baseline is 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 states a specific resource and output type: the current list of National Assembly live broadcasts. It is clear enough to identify a listing operation, though it does not explicitly differentiate itself from nearby live-caption 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?

There is no guidance on when to use this tool versus the related assembly_live_captions tools, nor are there stated exclusions or prerequisites. The optional only_live parameter is documented only in the schema.

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 it well: it discloses that speakers are inferred from the chair's designation or self-introduction, that captions contain recognition errors, and that member is null with heard populated when the chair's name is not in the roster. It omits operational traits such as auth requirements, rate limits, or truncation behavior for max_chars.

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?

Four sentences, front-loaded with the core operation, then the block shape, then the use case, then the caveat. Dense but every sentence carries information; slight compression loss from the parenthetical notation.

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 7-parameter, no-output-schema tool, the description covers purpose, output shape, and accuracy caveats well, but leaves the xcode parameter completely unexplained and says nothing about default time ranges or what happens when the result exceeds max_chars. Those gaps matter for correct invocation.

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 86%, so the schema already documents date/from/to/member/committee/max_chars, and the description adds no filtering syntax or format guidance. It does mention the member-block concept, giving indirect meaning to the member filter, but the undocumented xcode parameter is not explained anywhere.

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 resource (recorded live-caption STT) and a specific operation (grouping into per-member blocks), and clarifies that each block carries member/party/district plus timestamped transcript. It does not explicitly name the sibling tools it differs from (e.g., assembly_live, assembly_meeting_speeches), so it stops short of full 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?

It clearly states the intended window of use: 'before minutes are published, for same-day verbatim remarks'. That implies the alternative (assembly_meeting_speeches after minutes exist) but does not name it or state an explicit exclusion.

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 exist, so the description carries the full burden and does well: it discloses that the recorder runs as a separate process, that it stops itself when the relay ends, and that recording must precede the relay to be complete. It omits permission requirements, whether an in-progress recording can be stopped or duplicated, and what a status response contains.

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

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

Purpose is front-loaded in the first clause, and each following sentence supplies a distinct fact (why pre-record, process lifecycle, parameter sourcing, no-arg behavior). Slightly dense but no redundant restatement of the name.

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 side-effecting tool with no annotations and no output schema, the description covers the critical surprises: a separate process is launched and self-terminates, and the no-arg call returns status. Whats missing is how to inspect or stop an active recording and any permission notes, but nothing essential to a correct first call is absent.

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% so the baseline is 3, but the description adds real value by telling the agent that xcode values come from assembly_live, and by clarifying that all=true covers both currently and future relayed broadcasts. That cross-tool sourcing hint is not in 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?

Opens with a specific verb+resource pair ('의사중계 AI 자막 녹화 시작/상태' – caption recording start/status) that is clearly distinct from the read-only sibling assembly_live_captions. The follow-up sentence explains the resource context (relayed captions) so the agent knows exactly what is being recorded.

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

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

Gives a concrete use condition: the caption server only emits sentences after connection, so recording must be started before/while relaying to capture the full meeting. Also states the zero-argument behavior (status only) and the all=true breadth. It does not explicitly name a sibling alternative to use instead in any 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 full burden, and it discloses unusually specific behavior: per-member grouping, transcript paragraph formatting ([안건N] 발언, ↳ 답변자), and truncation with a truncated=true signal tied to max_chars_per_member. It does not cover permissions, rate limits, or ordering guarantees, which keeps it from a 5.

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?

Four sentences, front-loaded with the core action, then output shape, then the truncation caveat, then the members modifier. Every sentence carries information, though the middle two could be merged for tighter structure.

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

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

With no output schema and no annotations, the description must explain the return shape, and it does: party/district plus per-agenda transcript blocks, reply lines, and a truncated flag. What remains uncovered is modest, mainly ordering and whether non-member attendance data is included.

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%, so baseline is 3, but the description adds real meaning beyond the schema: selecting members changes the default behavior of both with_replies and the truncation budget. It does not explain include_chair or the truncation boundary semantics, so it is above baseline but not exhaustive.

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

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

States a specific verb and resource: groups 회의록 전문 (record.assembly.go.kr) by 의원 and returns 발언 원문. This is clearly distinguishable from data-oriented siblings like assembly_bills or assembly_votes, though it never contrasts itself with the closest sibling, assembly_speech_clips.

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 through the members behavior ("특정 의원을 members 로 고르면 장관·증인 답변(replies)도 함께 준다"), which tells the agent one useful invocation pattern. However, it never says when to use this instead of assembly_speech_clips or other speech-related siblings, and gives no prerequisites beyond the schema's confer_num reference.

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 exist, so the description carries the full behavioral burden. It discloses only the no-filter-returns-all behavior; nothing about result size, pagination, read-only nature, or response shape is stated. For a tool that can return an entire legislature's membership, that is a meaningful 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?

Two compact sentences with zero waste; the resource and searchable facets come first, and the no-filter behavior follows. Nothing could be removed without losing 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?

The tool is conceptually simple (a filtered list), and there is no output schema to explain. Still, an agent lacks guidance on whether filters combine as AND, how partial matching works for name/party, and whether '전원' results are paginated or truncated.

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 50%: district and committee have inline descriptions (partial match, examples), while name and party are bare. The description's field list confirms party/district/committee as filterable, partially compensating, but it says nothing about name matching semantics or whether party accepts partial strings.

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

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

States a specific verb and resource: searching personal information of 22nd National Assembly members, and enumerates the searchable facets (party, district, committee, election count, contact). It is distinguishable from resource-specific siblings like assembly_bills or assembly_votes, though it does not address overlap with the generic assembly_search.

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?

"조건 없이 부르면 전원" implies that calling with no filters returns the full roster, which is useful. However, it never says when to prefer this over assembly_search or the other assembly_* tools, and offers no exclusions or prerequisites.

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 behavioral burden, but it only states that this is a generic OpenAPI call and marks required request variables with an asterisk. It does not disclose pagination behavior, authentication requirements, rate limits, error handling, or what the response contains.

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 opening sentence is front-loaded and states the tool's role, but the body is a very long bullet list of service IDs and fields without grouping or formatting aids. The list appears necessary given the generic schema, yet it is dense and not optimally organized for quick scanning.

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?

This is a high-complexity generic API caller with no annotations, no output schema, and 0% schema description coverage, so the description needs to explain more than service IDs and request fields. It omits return format, pagination semantics, error behavior, and how the generic tool relates to its many specialized 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?

With 0% schema description coverage, the description compensates substantially by listing accepted service IDs and the per-service request variables, including which variables are required. It still does not explain the page and size parameters or the expected types and formats for the nested params values.

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 this is a generic OpenAPI caller for the Open Assembly Information service and lists concrete service IDs with their Korean resource names, so the agent can identify what each call retrieves. However, it never distinguishes this generic caller from the many dedicated sibling tools such as assembly_members, assembly_bills, and assembly_votes.

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 how to invoke the tool by passing a service ID and request variables, but gives no guidance on when to choose this generic tool over the dedicated sibling tools or when not to use it. There are no exclusions, prerequisites, or alternative-selection criteria.

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 and does disclose non-obvious behavior: title/div use partial matching and results are sorted by 작성일 descending. It does not mention pagination beyond the schema's limit, or whether date filters are inclusive, but the matching and ordering semantics are the important traits here.

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

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

Three compact sentences, front-loaded with what is searched and where, then matching/sorting behavior, then the div filtering tip. Dense but every clause carries information; 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 six-optional-parameter, no-annotation, no-output-schema read tool, the description covers scope, matching rules and result ordering, which is what an agent needs to call it correctly. Minor gaps (date inclusivity, page-vs-limit behavior) remain but are low-risk.

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% so baseline is 3, but the description adds real value: it clarifies that query (제목) and div (구분) are partial-match fields, and it names concrete div values (이슈와 논점, NABO Focus, 최신외국입법정보) that go beyond the schema's single example. Date range and source semantics are left to 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?

Names a specific verb (검색) and resource (국회 소속기관 발간물) and enumerates the five issuing institutions, so the agent knows exactly what corpus is searched. It doesn't explicitly contrast itself with siblings like assembly_bills or assembly_search, but the resource is distinctive enough to separate them.

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

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

Usage is implied by the description (search publications, filter by institution via source, by category via div), and the div examples give practical routing hints. There is no explicit when-to-use/when-not statement or comparison to assembly_search or assembly_bills, so the agent must infer the boundary.

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 exist, so the description carries the full burden and it says nothing about read-only behavior, response shape, or failure modes. The only noted operational constraint (a ~150,000-character result limit forcing month-level splitting) lives in the schema, not the description.

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?

A single compact sentence with a clear head term (국회 일정 통합) front-loaded, followed by the scope enumeration. No filler, though the brevity borders on under-specification rather than economy.

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 tool with no annotations and no output schema, the description omits error behavior, result limits, and how to combine date with kind/committee. An agent would need to open the schema to avoid the documented overflow error.

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 67%, and the description adds no parameter meaning at all. The date parameter carries detailed format and size-limit guidance in the schema, but the committee parameter has no description anywhere and the interaction between date granularity and kind/committee narrowing is only hinted at in 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?

States a specific resource (국회 일정) and enumerates the aggregated event types (본회의·위원회·국회행사·세미나), which signals an integrated calendar view. It implicitly distinguishes itself from narrower siblings like assembly_committee_meetings, but never names them, so the differentiation is left to inference.

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 no guidance on when to use this aggregated schedule versus assembly_committee_meetings or assembly_live. Nothing states prerequisites, typical callers, or when-not-to-use.

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 substantial work: it discloses that the local index is limited to previously fetched content, that remote matching is morphological so terms may split-match, that auto defers remote until local is empty, and that verification requires opening url/offset. Auth, rate limits, and result-size behavior are not covered, so not a 5.

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 front-loaded in the first phrase, then two numbered mode blocks plus a default-behavior clause and a verification clause. Every sentence carries payload; density is high for a single paragraph but nothing is redundant with the schema.

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

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

For a 12-parameter hybrid local/remote search with no annotations and no output schema, the description supplies the mode-selection logic, matching semantics, fallback behavior, and citation-verification procedure via hit.url/offset and next_offset. What remains (per-field filtering, pagination sizes) is covered by the rich schema.

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

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

Schema coverage is 92%, so the baseline is 3, but the description adds real meaning beyond the schema for the query tokenization (spaces ignored, AND of all terms, quoted phrases) and especially for remote=auto (remote consulted only on zero local hits), which the schema only labels '기본 auto'. Parameters like speaker, committee, and sources get no prose treatment and rely entirely on schema descriptions.

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 (통합 전문 검색) and explicitly enumerates what is searched: 이 MCP로 가져온 회의록 발언·자막·검토보고서·국감 보고서 본문 plus remote 국회도서관 회의록. The '이미 가져온 것만' scoping implicitly separates it from the fetch-oriented siblings, but no sibling is named, so an agent must infer the boundary with assembly_meeting_speeches or assembly_index.

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

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

Gives clear context for each mode: local for anything already fetched regardless of date, remote for meetings never fetched, and the default auto only falls back to remote when local returns 0 hits. It also tells the agent to open hit.url/offset to verify before citing. No explicit alternatives or 'do not use when' routing to sibling tools, which keeps it below 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?

With no annotations, the description carries the full burden and does so well: it discloses publication latency (evening of the meeting day through the next day), states what is absent (no transcripts), and describes how the response expands when member is supplied (답변자·길이·영상 링크). It omits pagination, result caps, and any auth/rate context, keeping it from a 5.

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?

Five short sentences, each adding a distinct fact (timing, payload, exclusion, member behavior, title caveat), with the core purpose front-loaded. The telegraphic style is dense but nothing is wasted.

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

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

For a three-parameter, annotation-free tool with no output schema, the description covers what comes back, when the data exists, what it excludes, and a title-filter pitfall. Only the absence of pagination/result-size information leaves a small 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 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it explains that member switches the output to per-segment video data (answerer, length, link) and warns that audit meeting titles contain only the audited institution, not the committee name. That is real guidance the schema does not convey.

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 resource (국회의원 발언영상 목록) plus the shape of the payload (per-meeting counts and minutes per speaker), and explicitly excludes transcripts ("발언 원문은 없다"), which implicitly separates it from assembly_meeting_speeches. It never names a sibling tool outright, 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?

Usage is implied through the data-availability window (회의 당일 저녁~다음 날 공개) and the no-transcript caveat, and the note that audit meeting titles carry only the audited institution is a real operational hint for the title filter. However, it never says when to prefer assembly_meeting_speeches or assembly_live_captions instead, leaving the routing to inference.

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

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

With no annotations at all, the description carries the full behavioral burden but discloses almost nothing: not that it is a read-only lookup, not whether party/member act as filters or grouping dimensions, not whether results are paginated or capped, and not what happens when a bill has no recorded vote. Only the data facets are stated.

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?

A single front-loaded sentence naming the resource first, then the returned facets. Zero filler, though the compressed noun-phrase style makes the parameter roles harder to parse than a short clause would.

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 does substitute somewhat for the absent output schema by enumerating what comes back (tally plus party and member breakdowns). But for a 3-parameter read tool with no annotations and only one documented parameter, an agent is left guessing about filtering behavior and result shape.

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

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

Schema coverage is 33% — only bill_id (의안ID, PRC_…) is documented. The description partially compensates by naming 정당별 and 의원별, which maps to the otherwise undocumented party and member parameters and implies they narrow or group results. It does not say whether they are filters or groupings, nor whether they can be combined.

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 resource and scope: plenary vote results, with per-bill yes/no tallies plus party-level and member-level breakdowns. An agent can tell this is the vote-record endpoint rather than a member, bill-text, or speech endpoint. It lacks an explicit verb and does not name a sibling it differs from, 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?

There is no guidance on when to use this versus alternatives, even though assembly_bill_detail plausibly also surfaces vote information for a bill. No prerequisites, no exclusions, no indication of whether bill_id is mandatory for all queries despite it being required in the schema.

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