Taiwan Legislative Yuan MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
多数工具按实体清晰区分，如法律、议案、委员会等，但list_gazette_agendas与get_gazette_agendas、list_law_versions与get_law_versions存在相似功能，可能造成轻微混淆。总体边界明确，仅少数重叠。
Naming Consistency5/5
所有工具均采用snake_case，并严格遵循list_<entity>和get_<entity>模式，关联查询如get_bill_meets也保持一致的动词+名词结构，命名统一且可预测。
Tool Count2/5
42个工具远超典型范围（3-15个），虽涵盖多类数据，但数量过多可能增加选择成本。根据校准，25个以上已属偏多，42个更接近极限，因此给2分。
Completeness5/5
工具集全面覆盖立法院核心数据域：法律、议案、委员会、公報、质询、IVOD、会议、表决、立法委员，且包括列表、详情、关联查询等关键操作，无明显缺失或死角。
Average 3.4/5 across 42 of 42 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- Last stable release on August 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It only says 'get', which implies a read operation, but doesn't mention output format, error handling, or access requirements. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but borderline under-specified. It conveys the core action but lacks useful context that could be added without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, so return values are covered, the description lacks information about usage context and behavioral nuances. Given the many sibling tools, this minimal description is not fully complete for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter (vote_id) with a description and example ('1150101_00002_55'). The tool description adds no additional semantic meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '取得特定表決紀錄' (Get specific vote record) essentially restates the tool name 'get_vote' without elaborating on what distinguishes it from sibling tools like list_votes or get_vote_meets. It provides a verb and resource but no differentiation, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as list_votes or get_vote_meets. The description lacks context about selecting this tool for individual vote retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states that the return is a JSON string and raises errors with Chinese messages. There is no mention of read-only nature, idempotency, authentication requirements, rate limits, or any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Raises sections. However, it redundantly lists all parameter descriptions that are already in the schema, making it longer than necessary. It is front-loaded with the purpose statement but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters (1 required) and an output schema exists, the description should guide on how to use the many optional filters effectively. It lacks information on typical combinations, error handling beyond a generic statement, and does not clarify the relationship between similar parameters (e.g., meet_id vs meeting_code_data).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (every parameter has a description), so baseline is 3. However, the description repeats the schema descriptions verbatim without adding new meaning (e.g., the difference between 'meeting_code' and 'meeting_code_data'). It provides no extra syntactic or semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the list of IVOD videos related to a specific meeting, distinguishing it from siblings like 'list_ivods' (likely general listing) and 'get_ivod' (single video). The verb '取得' (retrieve) and resource '特定會議相關的 IVOD 影片列表' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no explanation of which optional filter parameters are recommended. It simply lists parameters without context on their typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only states the purpose and does not disclose any behavioral traits such as read-only nature, pagination behavior, required permissions, or return format. The schema hints at pagination via page and limit, but the description adds no context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, but it is extremely sparse for a tool with 12 parameters. It is concise but lacks structure (e.g., bullets or separation of concerns). It does not front-load key information about capabilities or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, multiple filters, and an output schema), the description is severely incomplete. It provides only the basic purpose and leaves the agent to infer filtering, pagination, and output details from the schema. No guidance on common use cases or integration with other tools is given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as all 12 parameters have descriptions. The tool's description does not add any additional meaning beyond the schema, so the baseline score of 3 applies. It does not explain how parameters interact or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出立法院表決紀錄。' means 'List legislative voting records,' which clearly states the verb (list) and resource (voting records). It distinguishes from siblings like get_vote and get_vote_meets by indicating a list operation, though it does not elaborate on scope or specific type of votes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention when to use it, when not to, or any alternatives. Since sibling tools like get_vote and get_vote_meets exist, explicit guidance would be valuable but is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
沒有提供任何註解，描述未揭露行為特質，例如是否為唯讀操作、是否具有破壞性、回應格式細節或錯誤時的行為。僅有「例外時回傳中文錯誤訊息字串」此段，但不足以彌補缺乏的行為透明度。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述以簡短目的句開頭，後接參數列表，每個參數僅一行並附有中文說明，結構清晰且無冗言。雖然參數列表長，但必要信息已前置。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具包含 20 個參數和輸出 schema，但描述未說明參數如何彼此組合、分頁行為、預設值背後的邏輯，或輸出結構的實際內容。僅依賴輸出 schema，但很多參數（如 bill_status、proposal_source）的意義和互斥性未說明，上下文情報不足。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
輸入架構（input schema）已提供所有 20 個參數的說明，描述中的參數說明與架構重複，但加入範例值（如「院會-11-2-3」），略有加分。因 schema_description_coverage 為 100%，基線為 3，描述未進一步提供超出架構的語意。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明確指出「取得會議內的議案列表」，並以特定動詞「取得」加上資源「會議內議案」清楚定義目的，能區分於相同領域的其他工具（如 get_meet、list_bills）。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述僅陳述工具功能，未說明何時應使用此工具而非其他替代方案，也未提及任何排除條件或使用情境。雖然名稱中的「meet」暗示與會議相關，但缺乏明確指引。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'Raises: 例外時回傳中文錯誤訊息字串' (returns Chinese error messages on exception), which is some transparency. However, it does not disclose behavioral aspects like pagination behavior, response structure, idempotency, or whether it is a read-only operation. The description is mostly a parameter listing with minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Raises sections, which is positive. However, it is verbose, listing all 21 parameters explicitly with examples. This is not concise for an agent to parse quickly. It front-loads the purpose but then provides a long list that could be trimmed or summarized. The structure is good but the length reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (21 parameters, 2 required), the description enumerates all parameters and provides return/error info. An output schema exists, so return details are not required in the description. However, it lacks guidance on how the filter parameters are combined (e.g., are they all applied concurrently?) and does not explain when to use some parameters over others. It is complete in coverage but lacks operational semantics for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds examples for several parameters (e.g., 'term: 屆，例：11'), which aids understanding. However, it largely duplicates the schema descriptions without adding new semantic depth, such as explaining how multiple filters interact (e.g., AND vs OR) or the relationship between 'term' and 'bill_term'. It does not clarify the meaning of 'bill_flow_status' vs 'bill_status' which could be confusing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '取得委員為提案人的法案列表' (Get list of bills where the member is the proposer). This is a specific verb+resource combination. It implicitly distinguishes from the cosign tool by mentioning 'propose' but does not explicitly name the sibling 'get_legislator_cosign_bills' as an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description solely lists parameters and the return type. It does not mention that for bills where the legislator is a cosigner, one should use 'get_legislator_cosign_bills'. No context is provided for typical use cases or prerequisites beyond the required 'term' and 'name'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return format (JSON string) and error handling (Chinese error messages). It also mentions pagination parameters (page, limit). However, it does not explicitly state that the tool is read-only, nor does it address potential side effects, rate limits, or authentication requirements. Given no annotations, the description provides basic but incomplete behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, listing all 19 parameters in a bullet format that mirrors the schema. While structured, it could be significantly shortened by omitting the parameter list since the schema already provides that information. The first sentence is concise, but the rest adds bulk without value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (19 optional parameters) and the presence of an output schema, the description covers pagination, error handling, and return format. However, it does not explain which parameters are typically used together or how to construct a meaningful query, leaving the agent to guess at common use cases. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description largely repeats the parameter descriptions from the schema, adding only minor additional context (e.g., date format). It does not significantly enhance understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: '列出立法院議案列表' (list bills of the Legislative Yuan). It explicitly lists all parameters, making the purpose evident. However, it does not differentiate from sibling tools like list_laws or list_gazettes, reducing clarity in the broader toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any conditions or exclusions mentioned. The description simply states what the tool does, leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return type (JSON string) and error behavior (Chinese error message string), but does not mention key behavioral aspects such as how filters combine, pagination defaults (page=1, limit=20, max 100) are already in schema, or that output_fields customizes the result set. The Raises section adds minimal transparency about error handling, but the overall behavior remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a standard docstring structure (Args, Returns, Raises), front-loading the action in the first line. However, the Args list is redundant with the input schema, which slightly detracts from efficiency, but it's not bloated and each section is brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter filterable list tool, the description lacks context on how filters combine, what happens when no filters are provided, and what fields are available for output_fields. It also doesn't clarify the relationship with sibling tools like get_gazette_agenda. Even though an output schema is said to exist, the description itself doesn't explain the return structure beyond 'JSON format', making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's Args section repeats the exact schema parameter descriptions (e.g., gazette_id: 公報編號，例：1137701), adding no new meaning. Since the schema already documents all parameters with examples, the description doesn't compensate with additional semantics like parameter interdependencies or value constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with '列出公報目錄列表' (List gazette agenda list), clearly stating the verb (list) and resource (gazette agendas). The Args section further implies a filterable list interface, but the core purpose is not explicitly differentiated from sibling tools like get_gazette_agenda, so it stays slightly below a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It doesn't mention that get_gazette_agenda should be used for a single agenda, or how this list function relates to list_gazettes. The usage context is only implied by the tool name and parameter list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions return type (JSON string) and error handling (Chinese error messages), but does not disclose read-only nature, idempotency, or potential side effects. For a listing tool with no annotations, more behavioral context is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear purpose line followed by parameter definitions. It is reasonably concise but could be more compact by removing verbatim repeats of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return type and error handling, and an output schema exists. However, it lacks explanation of parameter dependencies (e.g., whether law_number or version_id is needed) and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description's parameter list essentially duplicates the schema's descriptions without adding new meaning or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '列出法條資料' (list law article data), which clearly indicates a listing operation. The name 'list_law_contents' and the parameter list (filters, pagination) reinforce this. However, it does not explicitly differentiate from sibling tools like get_law_content, though inference is possible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description simply lists parameters without explaining scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning a JSON string and Chinese error messages but does not disclose whether the tool is read-only, any authentication needs, rate limits, or side effects. For a listing tool, read-only behavior is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args, Returns, and Raises sections but is verbose due to repeating parameter descriptions. It could be more concise by summarizing or referencing the schema. The front-loading is adequate but not efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 100% schema coverage, and an output schema, the description covers the basics: return type, error handling. However, it lacks usage context, pagination details, and relationship to sibling tools, leaving some gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters have descriptions in the schema (100% coverage). The description repeats these descriptions with examples, adding minimal value. It does not explain how parameters interact or provide further semantic guidance beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists laws from the Legislative Yuan. The verb '列出' (list) and resource '法律列表' (law list) define the action and output. However, it does not distinguish from siblings like list_law_versions or list_law_contents, which also list law-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_law (for a single law) or list_law_versions (for versions). The description provides parameters but no context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It minimally states return type (JSON string) and error handling, but lacks details on pagination, rate limits, or what happens with invalid filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a lengthy parameter list with examples; it is verbose but structurally clear. It could be more concise by grouping related parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 13 parameters and presence of an output schema, the description adequately lists inputs and return type but lacks usage advice or complete behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description repeats the same examples, adding no new semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists meetings of the Legislative Yuan, with many filtering parameters. However, it does not explicitly differentiate itself from sibling tools like get_meet, which retrieves a single meeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only lists parameters without any usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the return type and error handling but omits safety (e.g., read-only), authentication needs, rate limits, or pagination behavior beyond parameter defaults. The 'Returns' section merely repeats the output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is functional with clear 'Args', 'Returns', and 'Raises' sections. However, the parameter list is redundant with the schema and could be condensed. The initial sentence is concise, but the overall length is bloated by repetitive examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, no annotations, and an output schema present, the description fails to explain parameter interactions or required combinations beyond the two mandatory ones. It does not clarify whether filters are additive or exclusive, leaving ambiguity for complex queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description repeats the same parameter examples and descriptions as the schema without adding new semantics (e.g., which parameters are filters vs. pagination, or how multi-parameter queries combine).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '取得委員出席的會議列表' (get list of meetings attended by legislators), specifying verb and resource. The tool name and description differentiate it from siblings like get_legislator (personal info) and get_meet (meeting details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_committee_meets or get_meet. The description only lists parameters without any context about filtering precedence or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions return type (JSON string) and error handling (Chinese error messages), but does not disclose if this is read-only, any authentication needs, rate limits, or side effects. Given that it's a listing operation, it is likely safe, but the description does not make this explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a clear docstring structure with Args and Returns sections. The main purpose is front-loaded. Every sentence adds value, though the parameter descriptions slightly overlap with the schema. No redundancy, but could be more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and an output schema (implied), the description adequately covers the return format and error handling. It includes pagination details (page, limit) but does not elaborate on pagination behavior like total count. Overall, it is fairly complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds value by providing examples (e.g., '例：羅智強') and a recommendation for limit ('建議不超過100'). However, these are minor improvements over the schema descriptions, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '列出立法院質詢列表' which means 'List the legislative interpellation list'. It identifies the tool as a listing operation with various filters. However, it does not explicitly differentiate from sibling tools like get_interpellation or get_legislator_interpellations, so it loses some points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter details but offers no guidance on when to use this tool versus alternatives (e.g., get_interpellation for a single item or get_legislator_interpellations for a specific legislator). There is no context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the return format (JSON) and error handling (Chinese error messages). It omits important traits like pagination limits, default ordering, read-only nature, or rate limits, which are critical for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with a clear initial sentence, but the parameter list duplicates the schema information and could be condensed. It is front-loaded with purpose but not optimized for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 filter parameters and an output schema. The description explains what the tool does and provides examples, but misses contextual details like how filters combine (AND/OR) or the default output structure. However, the existence of an output schema partly compensates for missing return information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing examples for all 11 parameters. The tool description repeats these examples but adds no significant additional meaning beyond the schema. Thus, the value added is minimal, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '列出 IVOD 影片列表' (list IVOD video list), specifying the verb (list) and resource (IVOD videos). It distinguishes from sibling tools like get_ivod (single item) and other list tools by focusing on IVOD videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 get_ivod or other list tools. It does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially fulfills the burden by stating the return format (JSON string) and error behavior (Chinese error messages). However, it does not disclose permissions, side effects, or other behavioral traits beyond basic get semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. The docstring format with Args/Returns/Raises is structured but not overly verbose for the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one parameter and an output schema implied, the description is complete. It covers purpose, parameter, return, and errors. No major gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter. The description adds an example but no additional meaning beyond the schema description. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information of a specific gazette. It uses a specific verb ('get') and resource ('specific gazette'), but does not explicitly differentiate from siblings like list_gazettes or get_gazette_agenda.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or when not to use it compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose behavioral traits such as idempotency, authentication needs, or side effects. It only mentions return format and error handling, which are minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with sections (Args, Returns, Raises). However, some elements like the title line are redundant given the tool name, and the content is brief but clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema is mentioned, but the description does not elaborate on the content of the JSON. For a simple single-parameter tool, it is minimally complete but lacks depth to fully inform complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full description coverage (100%), including an example. The description's 'Args' line adds no additional meaning beyond what the schema already conveys, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information of a specific gazette agenda, matching the tool name and distinguishing it from related siblings like 'get_gazette' or 'get_gazette_agendas'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks contextual hints about prerequisites or conditions, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states return format (JSON string) and error handling (Chinese error messages). It does not disclose read-only nature, rate limits, or other behavioral traits beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring with Args, Returns, Raises sections. It is front-loaded with the main purpose. However, the Returns section may be redundant given an output schema exists, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema. The description adequately conveys the basic functionality but lacks additional context about '未議決進度' (pending progress) or how it fits relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter law_id. The description repeats the schema's description without adding new meaning, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves unresolved progress for a specific law using the verb '取得' (get) and resource '未議決進度列表' (pending progress list). It distinguishes itself from sibling tools like get_law or get_law_bills by focusing on 'progress.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only mentions the required parameter law_id with an example but does not provide context for when to choose this over related law tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention any side effects, rate limits, authentication, or safety considerations. It is a read operation but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, including args, returns, and raises sections. It is not verbose and gets to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides return type (string containing JSON) and error handling (Chinese error message), but lacks details on the structure of the returned agenda list. Given the simplicity, it is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described with concrete examples (e.g., gazette_id: 1137701, meeting_date format). The descriptions add useful context beyond the schema, though they largely mirror the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the list of agendas for a specific gazette, using a specific verb and resource. It distinguishes from the generic list_gazette_agendas by specifying the gazette_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It relies on the parameter requirement of gazette_id, but does not mention conditions or when to prefer this over similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description does not disclose whether the operation is read-only, destructive, or requires specific permissions. It mentions returning JSON and error messages, but lacks details on side effects, rate limits, or postconditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but includes a verbose Args section that duplicates schema details. It could be streamlined by focusing on usage intent and omitting redundant parameter lists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters and an output schema, the description provides basic return format and error handling. However, it lacks details on sorting, default ordering, or pagination behavior beyond parameter defaults, leaving gaps for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's Args section largely repeats parameter descriptions, adding minimal value beyond stating '必填' for law_id. It does not enhance understanding of parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of historical version records for a specific law ('取得特定法律過往的版本紀錄列表'). Among sibling tools like 'get_law' (detail) and 'get_law_version' (single version), this tool's purpose is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing historical versions but does not explicitly state when to use this tool versus alternatives like 'list_law_versions' or 'get_law_version'. No when-not-to-use or contextual guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
無註解，描述必須承載行為揭露。描述提及傳回 JSON 格式及錯誤時傳回中文訊息，但未說明是否為唯讀、是否需要權限、分頁行為細節或其他副作用。相較於純粹的參數說明，僅增加少量行為資訊。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述簡潔，結構分明（Arg、Returns、Raises），資訊優先放置於開頭，無冗詞贅字，易於閱讀。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具參數多達 9 個，描述未說明關鍵參數之間的關係（如 term 與 term_query 的差異、name 與 interpellation_member 的用途），也未提供使用情境或與其他工具的對比。輸出 schema 雖存在，但描述本身對複雜度而言仍顯不足。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
輸入 schema 對所有參數皆有描述，覆蓋率 100%，因此基準分為 3。描述中的 Args 段落重複了 schema 的說明，僅加上實例，未增加額外的語意或參數間關係。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明確指出取得質詢列表，並限定委員為質詢委員，清楚區分於其他質詢相關工具。動詞 'get' 與資源 'interpellations' 具體，且與兄弟工具（如 list_interpellations、get_meet_interpellations）有別。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述未提供任何使用時機或與替代工具的比較，亦未說明當與其他質詢查詢工具搭配時該如何選擇。僅有功能說明，缺乏實用的指引。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral details. It only states the action without mentioning side effects, permissions, pagination behavior, or output format. The lack of any such information leaves the agent uncertain about the tool's runtime characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy. It directly conveys the tool's purpose without unnecessary details, making it efficiently scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (as indicated), so return value explanation is not required. However, the description lacks contextual information such as typical use cases or relationship to other tools, which would enhance completeness. Given the simplicity of the operation, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the description does not elaborate on parameters, the input schema provides detailed descriptions for all 14 parameters, achieving 100% coverage. Since schema coverage is high, a baseline score of 3 is appropriate; the description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: retrieving the list of meetings for a specific vote. It uses a specific verb ('取得' / get) and resource ('特定表決所屬的會議' / meetings belonging to a specific vote), distinguishing it from sibling tools like get_vote or list_meets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 get_vote, list_votes, or get_meet. It does not mention use cases, filtering preferences, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits. It only mentions that it returns JSON and may raise exceptions, but does not indicate if it's read-only, requires permissions, or has 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence plus organized Args/Returns/Raises sections. It is well-structured but could include more details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and existence of output schema, the description is adequate but minimal. It does not explain what '資訊' includes or differentiate from related tools like get_law_content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description in Args repeats the schema description. The description adds no new meaning beyond what the schema provides, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves specific law version information using the verb '取得' and resource '特定法律版本資訊'. It effectively distinguishes from siblings like get_law_versions and get_law_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description lacks context about when to choose get_law_version over other law-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions return type (JSON string) and error handling (Chinese error message), which adds some transparency. However, it does not state whether the operation is read-only, describe pagination behavior despite page/limit parameters, or disclose any side effects. The added value beyond schema is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description follows a clear docstring format (Args, Returns, Raises) and front-loads the purpose. While it is lengthy due to many parameters, each section is concise and relevant. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, 1 required) and presence of an output schema, the description is fairly complete. However, it omits discussion of parameter interactions (e.g., law_version_id vs law_number) and does not explain how pagination works beyond providing defaults. Annotations would have helped, but they are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description's Args section essentially repeats the schema descriptions without adding new meaning. No examples, constraints, or relationships between parameters are clarified beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of articles for a specific law version (取得法律版本包含的法條列表). The verb 'get' and resource 'law version contents' are specific. However, it does not differentiate from sibling tools like get_law_content or list_law_contents, which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters but provides no explicit guidance on when to use this tool versus alternatives, nor when to apply optional filters. Usage is implied by the parameter descriptions, but no when-not-to-use or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does state that the return value is a JSON-formatted string and that exceptions yield Chinese error messages, but it omits details about pagination behavior, empty results, sorting, or how filters interact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose statement followed by concise Args, Returns, and Raises sections. No redundant filler is present, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list endpoint with all-optional parameters, the description covers every parameter, the return format, and the error behavior. It would be more complete if it mentioned pagination semantics or distinctions from sibling tools, but the existing structure is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the Args section largely mirrors the schema descriptions verbatim, including the '建議不超過100' note for limit. The description adds almost no meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '列出' (list) and clearly names the resource '委員會列表', so the tool's basic purpose is unambiguous. It is implicit but not explicitly stated that this is the plural listing counterpart to get_committee, which prevents full differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_committee or get_committee_meets. The Args section only documents parameters; it does not explain selection context, filtering combinations, or when not to use this endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It specifies the return type (JSON string) and error handling (Chinese error messages). Pagination behavior is implied via 'page' and 'limit' parameters. However, it does not explicitly state that the operation is read-only, nor does it disclose any rate limits or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for Args, Returns, and Raises. It is appropriately detailed without unnecessary verbosity. Each parameter gets a line with an example, keeping it organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, all optional, and an output schema is present, the description adequately covers input details, return type, and error handling. It is complete for an agent to understand how to invoke the tool, though it could list possible values for 'action' or 'progress'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing concrete examples for each parameter (e.g., law_number: 90481, date: 1944-02-29), which clarifies format and usage beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '列出法律版本資料' (list legal version data), indicating a list operation. It enumerates filtering parameters, which distinguishes it from siblings like 'get_law_versions' that might retrieve a single version. However, it does not explicitly contrast with the similarly named sibling 'get_law_versions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'get_law_versions', 'get_law_version'). There is no mention of prerequisites, typical use cases, or scenarios where other tools 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description states the return format (JSON string) and error handling (Chinese error message). It implies a read-only operation but does not disclose any side effects, rate limits, or behavior when the interpellation is not found. Not exhaustive but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise Python-style docstring with Args and Returns sections. It uses clear language and includes a representative example. Every sentence is useful; no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, the description covers the purpose, parameter, return format, and errors. It is complete enough for an agent to understand usage, though it could mention its role relative to list_interpellations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%. The description repeats the parameter description from the schema ('質詢編號，必填，例：11-1-1-1'), adding no new meaning. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '取得' (get) and the resource '特定質詢的詳細資訊' (detailed info of a specific interpellation). It specifies the required parameter interpellation_id with an example, and the tool is distinct from sibling tools like list_interpellations or get_meet_interpellations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as list_interpellations (for listing) or get_meet_interpellations (for interpellations in a meeting). No prerequisites, when-not-to-use, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It states the return format (JSON string) and error handling (Chinese error message), but does not disclose whether the operation is read-only, requires authentication, or other behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences. It front-loads the Chinese purpose and includes return/error details. However, there is a minor redundancy in the English restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and a likely output schema, the description fails to specify what kind of statistical information is returned. The agent lacks context about the content and structure of the statistics, making the tool usage ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so no parameter documentation is needed. The baseline for 0 parameters is 4, and the description does not add any irrelevant parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'statistics' from the Legislative Yuan API. It distinguishes from sibling tools like get_bill or get_committee, which focus on other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to get statistics vs. getting individual bill or committee data. The description lacks any context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose return behavior (JSON string containing meeting info) and error behavior (Chinese error messages). However, it lacks context about permissions, rate limits, or the relationship between comt_cd and the committee list, which would be useful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear Args/Returns/Raises sections and is front-loaded with the purpose. However, it is lengthy and repeats the schema's parameter information almost verbatim, which is redundant for an agent that already has access to the input schema. A more concise description would omit the duplicated parameter lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters and no annotations, the description is fairly comprehensive: it states the purpose, documents all parameters with examples, describes the JSON return format, and notes error behavior. The presence of an output schema reduces the need to detail return fields further. It lacks explicit alternative guidance, but otherwise provides enough context to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description's Args section largely duplicates the schema's parameter descriptions, including examples and defaults, without adding additional meaning beyond what the schema already provides. It neither compensates for missing schema info nor adds new insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '取得委員會相關會議列表', which clearly states the tool returns a list of committee-related meetings. The verb '取得' (get) and resource '委員會相關會議列表' are specific, and the committee scope distinguishes it from sibling tools like get_meet (single meeting) and list_meets (all meetings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when committee meetings are needed by providing the required comt_cd parameter, but it does not explicitly state when to use this tool over alternatives such as list_meets, get_meet, or get_bill_meets. No exclusions or alternative recommendations are given, leaving usage to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states it returns a JSON string and raises exceptions with Chinese error messages, but lacks information on side effects, authorization, or performance. Since annotations are absent, more behavioral context would be beneficial but not critical for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with two sentences plus structured Args/Returns/Raises. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter retrieval tool with an output schema, the description adequately covers the function. The return format is specified as JSON, and error handling is noted. Could mention the output structure briefly, but output schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter law_content_id is described in the input schema (100% coverage) and the description repeats this description without adding new meaning, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information of a specific law article using a law_content_id. It is distinct from sibling tools like get_law (likely law-level info) and get_law_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_law or list_law_contents. No context for prerequisites 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
無 annotations 提供，描述必須承擔行為揭露。描述說明回傳 JSON 格式、錯誤時回傳中文錯誤訊息，但未說明是否為唯讀操作、是否需要特定權限、分頁行為等。由於該工具為查詢工具，且描述已說明基本回傳格式，尚可接受，但缺乏更多行為細節。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述簡潔，先說明目的，再列出參數與回傳說明。雖然參數列表長，但每個參數一行，結構清晰。無冗餘文字，每個句子都有功能。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
此工具參數眾多（21個），但描述已列出所有參數與說明，schema 覆蓋率 100%，有輸出 schema。然而描述未說明分頁的預設值與限制（雖然 schema 有），且未說明輸出欄位可自訂之細節。整體尚可，但對複雜查詢工具來說，可補充使用範例或組合建議，但未達不足程度。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema 描述覆蓋率 100%，包含每個參數的類型、範例或說明。描述中列出所有參數但僅重複 schema 內容，未額外添加語意（如哪些參數可組合使用、優先順序等）。但由於 schema 已提供充足資訊，描述並未增加額外價值，符合基準 3 分。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述清楚說明此工具是取得委員為連署人的法案列表，且列出多個參數可過濾，與兄弟工具如 get_legislator_propose_bills 有明確區隔（連署 vs 提案）。功能目標明確，動詞+資源+範圍都具體。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述未明確說明何時使用此工具而非其他工具（如 get_legislator_propose_bills），但從名稱和描述可推測用途。未提供排除情境或替代工具說明，但因此工具功能特定，使用情境相對清楚。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses return type (JSON string) and error handling (Chinese error messages) but does not mention read-only nature, data sources, or rate limits. Lacks detail beyond basic behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, Raises sections. It is concise, contains no redundancy, and every sentence adds value. The Chinese text is appropriate for the tool's locale.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (0 required) and an output schema, the description covers all parameters, return format, and error handling. It could mention pagination behavior or ordering, but overall it is sufficiently complete for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description largely repeats schema info with added examples (e.g., '1137701' for gazette_id). This adds modest value beyond the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists gazettes, matching the name. Among siblings, 'get_gazette' likely retrieves a single gazette, but the description does not explicitly differentiate; however, the verb 'list' and parameters imply bulk listing with filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The docstring provides parameter example values and constraints (e.g., limit ≤100), implying usage context. However, there is no explicit guidance on when to use this tool versus sibling alternatives like 'get_gazette' or 'list_gazette_agendas'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the return format (JSON string) and that errors return Chinese error messages. It does not disclose read-only nature, auth requirements, or behavior for missing IVOD. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, using a single sentence for purpose and structured Args/Returns/Raises sections. No fluff, but could be even shorter. Slightly more verbose than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though not shown), the description adequately explains return content. It covers parameters and error behavior. However, it lacks details on edge cases or prerequisites for a simple get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'ivod_id' is already described in the schema. The description repeats the same info in the Args section, adding no new meaning beyond the schema. Baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves detailed info for a specific IVOD video, using the verb '取得' and specifying the resource 'IVOD影片詳細資訊'. It distinguishes from sibling tools like list_ivods and get_meet_ivods by being the specific get-by-ID variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description does not explicitly guide when to use this tool vs alternatives. It only describes what it does; there is no mention of when to prefer this over list_ivods or get_meet_ivods. Usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format (JSON string) and error behavior (Chinese error messages). This is a read operation with no side effects mentioned, which is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and structured with clear sections (Args, Returns, Raises). It front-loads the purpose. Minor inconsistency: starts in Chinese but uses English headings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, existence of an output schema, and no nested objects, the description is appropriately complete. It covers purpose, parameter, return format, and error handling. No obvious gaps for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes meet_id with an example. The description's Args section repeats the same example, adding no new meaning. With 100% schema coverage, the baseline is 3, and the description does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed information of a specific meeting (取得特定會議的詳細資訊). The verb and resource are specific. However, it does not explicitly differentiate from siblings like get_meet_bills or get_meet_ivods, though the name and context imply the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting meeting details but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or prerequisites, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries burden. It mentions return format (JSON string) and error messages in Chinese, but lacks details on side effects, permissions, or rate limits. Basic transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence purpose, then args/returns/raises. No wasted words, front-loaded, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simplicity (one param, output schema exists), description covers return format, parameter, and error handling. Lacks example of JSON structure but adequate for a basic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for bill_no. Description repeats schema info ('必填，例：203110077970000'), adding minimal value. Baseline 3 appropriate as schema already explains the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states '取得特定議案的詳細資訊' (get detailed information of a specific bill) and enumerates the contents (basic info, proposer, process, laws). Distinguishes from sibling tools like get_bill_doc_html, get_bill_meets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for bill details but no explicit guidance on when to use versus alternatives (e.g., get_bill_doc_html for HTML version). No when-not-to-use or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 useful behavior details: returns a JSON-formatted string with related type/number, and raises a Chinese error message string on exceptions. However, it does not explicitly state that the operation is read-only or describe any edge cases (e.g., empty results), which would be valuable for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse and well-structured: one-sentence purpose plus simple Args/Returns/Raises sections. Every line earns its place, no fluff, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, the description covers purpose, argument, return format, and error handling. It adequately supports invocation. It lacks usage context beyond the obvious, but the output schema (if present) and the clear purpose compensate for this. Minor gap: no mention of what '相關議案' means in scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the Args block repeats the schema's property description verbatim ('議案編號，必填，例: 203110077970000'), adding no new semantic information beyond what the input schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with '取得特定議案的相關議案列表' — a specific verb ('取得') and resource ('特定議案的相關議案'), clearly distinguishing it from siblings like get_bill (single bill) or list_bills (all bills). No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The purpose implies usage (when you need related bills for a given bill), but it does not contrast with sibling tools like get_bill or list_bills, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return format (JSON with basic info, member info) and error behavior (raises Chinese error message). Lacks mention of idempotency or side effects, but sufficient for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with structured sections (Args, Returns, Raises). No unnecessary words, but could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with output schema, the description is fully complete: explains return format, error handling, and parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema has 100% coverage with description matching the description. Description adds no extra meaning beyond what schema already provides, warranting baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'specific committee information', distinguishing it from sibling tools like list_committees (listing) and get_committee_meets (meetings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. It implies a specific committee code is needed, but does not mention when not to use (e.g., when listing is needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses return type (JSON string) and error handling (Chinese error messages), but does not mention any side effects, authorization needs, rate limits, or pagination behavior beyond parameter defaults. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Raises sections, making it easy to scan. It is concise without unnecessary text, though some parameter descriptions repeat the schema exactly. Overall efficient for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, one required) and presence of an output schema, the description adequately covers all aspects: parameter details, return format, and error handling. It is self-contained for an agent to understand usage without needing to inspect the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds examples inline with parameter descriptions but largely mirrors the schema. It provides context for defaults (e.g., page=1, limit=20) but no additional semantic meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '取得會議內的質詢列表' (get list of interpellations within a meeting), specifying the action and resource. It distinguishes from sibling tools like get_interpellation (single interpellation) and list_interpellations (general list) by focusing on meeting context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear parameter details but does not explicitly state when to use this tool versus alternatives like get_interpellation or list_interpellations. Usage context is implied by the name and parameters, but no when-not-to-use or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It describes the return format (JSON), error handling (Chinese error messages), and possible empty responses with reasons. It does not explicitly state read-only behavior or side effects, but the description implies a safe read operation. This meets basic transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns, notes, raises). It is front-loaded with the goal. However, the Args and Returns sections are redundant with the schema, making it slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers the key aspects: purpose, usage pattern, return format, and error cases. The recommendation to check existence adds context. It is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter bill_no with full description coverage. The description repeats the same example without adding new semantics or constraints beyond the schema. Thus, it adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the HTML content list of documents for a specific bill. It uses the verb '取得' (get) and specifies the resource as '文件 HTML 內容列表'. This distinguishes it from siblings like get_bill (bill details) and get_bill_meets (meetings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Notes section recommends using get_bill_detail first to confirm bill existence, providing explicit usage guidance. However, it does not elaborate on when not to use this tool or alternatives beyond that one suggestion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the return format (JSON string) and error behavior (Chinese error message), which is helpful. However, it doesn't disclose pagination behavior, rate limits, or whether the tool is read-only (though it's clearly a query tool). The description adds some value but could be more explicit about the nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Raises sections. It's concise and front-loaded with the purpose. The parameter list is a bit long but necessary given 14 parameters. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 params, output schema present), the description is fairly complete. It explains the return format and error handling. The output schema exists, so return values are covered. It could mention pagination behavior more explicitly, but overall it's adequate for a query tool with good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 14 parameters with descriptions and examples. The description repeats the parameter list but adds no new meaning beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves meeting records related to a specific bill (特定議案的相關會議列表), with a specific required parameter (bill_no) and example. It distinguishes from siblings like get_meet_bills (which likely retrieves bills for a meeting) and get_bill (bill details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists all filter parameters and provides examples, making it clear when to use this tool (to get meetings for a bill). It doesn't explicitly state when not to use it or name alternatives, but the sibling context and the tool's purpose are clear enough. A slight deduction for not explicitly contrasting with get_meet_bills or get_bill_related_bills.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return format (JSON with detailed info) and error handling (returns Chinese error string). Annotations absent, so description carries burden; adequate for read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded main sentence with structured Args/Returns sections; no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Single-parameter tool with simple output; description explains return format and error handling, sufficient given existing schema and complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description repeats example from schema; no additional semantic details beyond parameter format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb '取得' (get) and resource '特定法律' (specific law), distinguishing from sibling tools like get_law_bills or get_law_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no exclusions or context provided despite many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly documents the return type ('str: JSON 格式'), the general content ('包含該法律相關的議案資訊'), and error behavior ('例外時回傳中文錯誤訊息字串'). The read-only nature is also clear from the wording '取得...列表', even though permissions and rate limits are not discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a one-sentence purpose summary, then uses a clear structured list of Args followed by Returns and Raises. It is long due to 20 parameters, but each parameter line is direct and the structure is easy to scan without unnecessary prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 20 parameters and no annotations, the description covers all parameters, marks the required one, documents defaults for pagination, specifies the return type, and notes error behavior. It does not explain parameter interactions or provide an example call, but this is a reasonably complete reference for a read-only query tool, especially with an output schema available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The Args section largely duplicates the schema descriptions rather than adding new semantic meaning, such as filter combination logic, value constraints beyond examples, or output_fields formatting rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase '取得特定法律相關的議案列表' clearly states a specific verb (取得/list), resource (議案/bills), and scope (特定法律/related to a specific law). It is immediately distinguishable from sibling tools such as list_bills or get_bill because it emphasizes law-specific filtering via the required law_id parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for querying bills associated with a specific law, especially since law_id is required. However, it does not explicitly state when to prefer this tool over list_bills or get_bill, nor does it mention any exclusions or alternative tools for different query needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It mentions returning a JSON string and raising exceptions, but lacks details on pagination behavior, data freshness, or side effects. Basic transparency is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with an intro, parameter list, returns, and raises. It is front-loaded with the purpose. Some parameter details could be streamlined, but overall clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 optional parameters and an output schema (true but not shown), the description covers returns and error messages. It lacks details on filtering logic (AND/OR) or output field names, but is adequate for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters are described in the schema (100% coverage). The description adds value by providing concrete examples for each parameter and recommending a limit (not exceed 100), which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '取得立法委員列表' (get list of legislators), specifying the action and resource. It distinguishes from siblings like 'get_legislator' which retrieves a single entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters with examples but does not explicitly state when to use this tool versus alternatives like 'get_legislator'. No when-not-to-use or context cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return format (JSON string) and error handling (Chinese error messages), but lacks details on data freshness, authentication, or output structure beyond what the output schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single-line purpose followed by structured Args, Returns, and Raises sections. Every sentence is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description covers purpose, parameters, return format, and error handling. It lacks only minor contextual details like prerequisites or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description repeats the same examples as the schema ('term: 11, name: 韓國瑜'), adding no new semantic meaning beyond what's already in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '取得特定立法委員的詳細資訊' (get detailed info of a specific legislator), identifies the verb and resource, and includes parameter examples, distinguishing it from sibling tools like list_legislators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying required parameters (term and name) with examples, but does not explicitly state when to use this tool vs alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ly-mcp MCP server](https://glama.ai/mcp/servers/narumiruna/ly-mcp/badges/card.svg)](https://glama.ai/mcp/servers/narumiruna/ly-mcp)

Score Badge

Copy to your README.md:

[![ly-mcp MCP server](https://glama.ai/mcp/servers/narumiruna/ly-mcp/badges/score.svg)](https://glama.ai/mcp/servers/narumiruna/ly-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/narumiruna/ly-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server