open-assembly-mcp

Server Quality Checklist

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

Latest release: v0.6.0
Disambiguation5/5
Each tool has a clearly distinct purpose. Potential overlaps like get_bill_review and get_bill_committee_review are explicitly differentiated in descriptions. Tools cover different aspects of legislative data without ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_bill_detail, search_bills, get_member_votes). No mixing of conventions.
Tool Count4/5
20 tools is slightly above the typical 3-15 range but justified by the comprehensive scope of the National Assembly API. Each tool serves a specific, non-redundant function.
Completeness4/5
Covers major areas: bills (search, detail, review, proposers, pending), members (info, committees), votes (results, member votes, cohesion), schedules, hearings, reports, petitions, and API discovery. Minor gaps like bill text are acknowledged as API limitations.
Average 4.7/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavior: it is a read operation returning member details with pagination (page, page_size, has_more). It does not mention side effects, rate limits, or authorization, but for a read-only tool, the transparency is 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 well-structured with a summary, usage guidelines, arguments, and returns. It is front-loaded with the purpose, but includes both Korean and English text, making it slightly longer than necessary. Removing redundancy would improve conciseness.
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 presence of an output schema, the description adequately covers pagination and return fields. It differentiates from siblings like 'get_member_info' and 'get_bill_committee_review'. Missing details about error handling or edge cases are minor given the simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates thoroughly: it explains each parameter with default values, ranges, examples ('법제사법위원회'), and special behavior (None for committee returns all members). This adds substantial value beyond the bare 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 explicitly states the tool retrieves the roster of a National Assembly committee with party breakdown, using a specific verb ('Get') and resource ('committee roster'). It clearly distinguishes from 'get_member_info' by noting this is more direct for committee rosters.
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 'When to use' section provides three clear scenarios: listing members, party composition analysis, and as a more direct alternative to 'get_member_info'. However, it does not explicitly state when not to use or list alternatives for other use cases, leaving some ambiguity.
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 implies a read-only operation by describing a query and return of data, but does not explicitly state that no data is modified, deleted, or created. It would benefit from stating that the tool is idempotent and safe to call.
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 clear sections (English summary, when-to-use, args, returns). Every sentence adds value. The bilingual format is not redundant; the Korean targets local users. There is no wasted 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?
Given the tool has no annotations and many siblings, the description provides comprehensive context: purpose, parameter semantics, return value details (including fields like BILL_ID, count, total_count, has_more), and usage guidance distinguishing it from search_bills. The output schema is implied but not shown; however, the description covers return fields adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds complete meaning to all six parameters: assembly (required, example '22'), bill_name (keyword filter), committee (e.g., '환경노동위원회'), proposer (representative proposer), page (default 1), and page_size (default 10). This fully compensates for the missing schema descriptions.
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 'bills currently pending', and explicitly distinguishes pending bills from those already passed, rejected, or withdrawn. This precision makes the tool's purpose unmistakable and differentiates it from related tools.
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 provides explicit use cases: 'To see what legislation is currently active in a policy area' and 'To find unresolved bills on a topic'. It also directly contrasts with search_bills, which covers all outcomes. However, it lacks explicit when-not-to-use guidance, such as situations where pending bills are not relevant.
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 full burden. It does not disclose any behavioral traits like mutability, permissions, or rate limits. However, it clarifies the input parameter expectations (BILL_NO vs BILL_ID) and mentions the return of LINK_URL, which adds some 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 (Korean/English, when to use, not this tool, args, returns). It is informative without being overly verbose, though slightly on the longer side.
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 (one parameter, output schema present), the description covers all necessary aspects: input parameter details, usage guidance, alternative tools, and limitations (bill text not available). It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides rich context: explains what bill_no is (의안번호), gives an example, states it's required, clarifies it must be the 7-digit BILL_NO from other tools, not BILL_ID. This fully compensates for the bare 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 comprehensive bill metadata including processing dates, committee referral, promulgation info, and a link to the official bill page. It differentiates from siblings by specifying what it does and does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after search_bills) and when not to use (for timeline use get_bill_review, for co-sponsors use get_bill_proposers). Also addresses missing functionality (bill full text) and suggests an alternative.
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?
The description discloses the read-only nature by mentioning it retrieves information, and explains pagination behavior via has_more. However, it does not explicitly state that the tool is non-destructive or mention any authentication requirements, though these are implied.
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 sections for Korean/English, usage, args, and returns. It is concise but includes bilingual repetition, which slightly reduces efficiency.
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 existence of an output schema, the description lists return fields and pagination details. However, it does not cover error scenarios or prerequisites, making it somewhat incomplete.
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?
With 0% schema description coverage, the description compensates by explaining each parameter (assembly as required, session as optional filter, page and page_size with defaults). It adds context like 대수 and 회기 번호, but could provide more detail on valid formats.
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 bills on the plenary session agenda ("Get bills placed on the plenary session agenda") and distinguishes it from the sibling tool get_pending_bills by noting that pending bills are in committee while plenary agenda bills are ready for floor vote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ("To see what bills are scheduled for the next plenary vote") and how it complements get_pending_bills, providing clear guidance on when not to use this tool.
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 fully discloses behavioral traits: it mentions the specific endpoint, potential unreliability of the keyword filter, pagination via has_more, and return fields. The troubleshooting note adds transparency about possible issues.
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, types, usage, args, returns, note). It is somewhat lengthy due to bilingual content, but every sentence adds value 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and an existing output schema (which may document returns), the description covers purpose, usage context, parameter details, return fields, pagination, and troubleshooting. It is fully complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries full burden. It provides a detailed 'Args' section with meanings, examples (e.g., '인공지능', YYYYMMDD format), and constraints (max page_size=100), adding significant value beyond the basic 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 specifies the verb 'search' and the resource 'NARS reports', listing specific publication types (research reports, issue briefs, etc.). It distinguishes from sibling tools like search_bills and search_hearings by focusing on legislative research publications.
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 explains that NARS reports are useful for understanding legislative context. It provides a fallback suggestion to use query_assembly with discover_apis if the keyword filter fails, offering alternative usage guidance. However, it does not explicitly state when not to use this tool.
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 internal chaining, truncation at 500 bills, and handling of name ambiguity (first result, all matches). It does not explicitly state read-only behavior, but the composite nature and 'analyze' verb imply no 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 well-structured with labeled sections (When to use, Note, Args, Returns). It is longer than minimal but each sentence adds value; no filler.
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 complexity (chaining two tools, multiple return fields), the description covers all important aspects: usage, return structure with examples, error handling, and limitations. The output schema exists, but description still adds clarity on specific fields.
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?
Despite context showing 0% schema coverage, the description provides detailed parameter guidance: name is required with Korean examples, assembly has default '22' and supported range. This adds meaning beyond the schema's basic title.
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 is a one-shot legislator profile that chains get_member_info and search_bills, providing a complete picture. It distinguishes from sibling tools by naming the chained tools and explicitly positioning itself as an alternative to separate calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (needing complete picture in one call) and when not to (instead of separate calls). Also includes a note about the 500-bill limit, helping the agent set expectations.
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, but description discloses endpoint selection logic, committee filter constraint, and raw_response for non-standard formats. It is a read operation and no destructive behavior is implied.
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?
Well-structured with sections and bilingual summary, but slightly verbose with redundant translations. Core purpose 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?
Covers input parameters thoroughly, notes output fields, and provides fallback advice. Without the output schema, we cannot fully assess, but the description seems sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description adds comprehensive explanations for each parameter: assembly is required with example, schedule_type values are listed with mapping to endpoints, committee with example and condition, page and page_size with defaults.
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 queries the National Assembly schedule, listing specific types (plenary, committee, hearings). It distinguishes from sibling tools like query_assembly by specifying when to use the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use this tool vs alternatives: if filtering fails, use query_assembly. Also explains schedule_type determines endpoint usage and committee filter only applies for committee type.
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 the description carries full burden. It discloses pagination behavior with 'has_more: True이면 page+1로 재호출' and lists all return fields. However, it does not explicitly state that the tool is read-only or mention any authentication requirements. Still, the behavior is well covered overall.
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 long but well-structured: a brief purpose statement, workflow steps, a 'NOT this tool' clarification, then parameter and return sections. It front-loads the purpose and workflow. While it contains useful detail, it could be slightly more concise without losing value.
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 has 5 parameters, no output schema provided, and no annotations, the description is remarkably complete. It explains the workflow, parameter semantics, return fields including pagination, and how it relates to sibling tools. No gaps remain for effective 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?
Schema coverage is 0%, but the description compensates with detailed parameter explanations: it clarifies that 'assembly' is required, 'bill_no' is BILL_NO (number) not BILL_ID, 'bill_name' is a keyword filter, and provides examples. The return section also helps understand parameter usage. Could be more precise on data types for optional parameters.
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 explicitly states the tool's function: 'Get plenary vote results by bill (aggregate yes/no/abstain counts).' It distinguishes itself from the sibling tool 'get_member_votes' by clarifying that this tool is for aggregate results and that individual member votes require a different tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines a clear workflow: step 1 is this tool, step 2 is get_member_votes. It explicitly states when not to use this tool ('For individual member votes → use get_member_votes') and explains that get_member_votes requires BILL_ID from this tool, providing clear guidance on tool sequencing.
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 burden. It's a read operation implied by 'get' and description, and it details return fields. Lacks explicit safety info but sufficient for a read-only tool.
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?
Structured with sections, bilingual, clear. Slightly verbose due to bilingualism but front-loaded with purpose. Efficient overall.
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 output schema exists, description adequately explains return fields and usage context. Provides complete guidance for a single-parameter tool with no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0% but description includes an 'Args' section explaining bill_id in detail, with format example and critical distinction from BILL_NO. Adds significant value beyond 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?
Clearly states it retrieves committee meeting records for a specific bill. Distinguishes from sibling get_bill_review by specifying it returns individual meeting records rather than high-level timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (to see committee discussions) and when not (for high-level timeline, use get_bill_review). Also warns about BILL_ID vs BILL_NO, providing alternatives.
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 pagination behavior (has_more flag with instruction to call page+1) and lists return fields including processing result codes. However, it does not mention error handling, rate limits, or authentication needs. Despite these omissions, the core behavioral aspects are adequately covered for a read-only query tool.
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 (Korean/English summary, NOT lists, when to use, args, returns). It is slightly verbose but each sentence contributes value. Front-loading the purpose and use cases helps quick scanning.
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 has 5 parameters (1 required), no enums, and an output schema exists (though not shown), the description provides a thorough overview. It covers purpose, parameter semantics, return fields, pagination, and sibling differentiation, making it fully informative for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining each parameter's purpose, type, and constraints. It clarifies that bill_no is a numeric BILL_NO (not BILL_ID), provides examples for assembly and committee, and distinguishes optional from required fields. This adds substantial meaning beyond the raw 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's purpose: retrieving bill processing timeline information. It uses both Korean and English summaries ('의안 처리·심사정보를 조회합니다', 'Get the high-level processing timeline') and explicitly distinguishes itself from sibling tools with a 'NOT this tool' section listing alternatives like get_bill_committee_review, get_bill_detail, and get_member_votes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool description provides explicit guidance on when to use it ('To see the overall legislative timeline', 'To filter bills by committee') and when not to use it, with direct references to sibling tools for specific use cases. This enables the AI to select the correct tool based on the task.
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 bears the full burden. It explains the Rice index calculation (excluding abstentions from denominator), handling of abstainers, and that it is a research-only tool. However, it doesn't mention idempotency or side effects, but for a read-only analysis tool this 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 well-structured with sections for purpose, algorithm, workflow, args, and returns. While slightly long, every part adds value. Could be slightly more concise by merging some lines, but overall efficient.
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 complexity (multiple metrics, dissenters, error handling) and the presence of an output schema, the description completely covers input, output, algorithm, and usage workflow. No gaps remain for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It fully explains bill_id (required, PRC_... format with example) and assembly (required, example '22'), adding format and context beyond 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 it computes per-party voting cohesion for a bill, with specific metrics like Rice index, dominant position, and dissenters. It distinguishes itself from sibling tools like get_vote_results and get_member_votes by focusing on aggregate party analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a typical workflow: use get_vote_results to get BILL_ID, then call this tool. Explicitly warns that BILL_ID (PRC_...) is required, not BILL_NO, and gives clear prerequisites.
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 full burden. It discloses that authentication is automatic, pagination is handled via page/page_size, and the response structure is detailed (rows, count, total_count, has_more, raw_response). However, it does not explicitly mention idempotency, safety, error handling, or rate limits, which would strengthen 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 structured with clear sections (purpose, usage, workflow, authentication, common params, args, returns) and is front-loaded with the purpose. It is somewhat lengthy due to bilingual content, but every sentence is valuable. Could be slightly more concise but overall well-organized.
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 role as a universal fallback and the existence of an output schema, the description provides thorough coverage: explains response fields (endpoint, rows, count, etc.), when to use raw_response, pagination, and automatic handling of certain params. It is complete for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by explaining all four parameters: endpoint_code (with example and reference), params (with auto-handled fields), page (default 1), and page_size (default 10, max 100). This adds significant meaning beyond 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 it is a universal fallback to call any open.assembly.go.kr API endpoint directly, and specifies when to use it: when no dedicated MCP tool exists. The verb 'call any ... API endpoint directly' is specific and distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use when no dedicated MCP tool exists for the data you need.' A typical workflow is shown (discover_apis then query_assembly), and it warns not to pass KEY in params, explains common parameters, and mentions pagination. This leaves no ambiguity about when to use this tool.
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?
Discloses that the tool returns only metadata, not full text, and explains the API endpoints behind include_closed. Without annotations, it covers key behavioral traits, though auth or rate limits aren't mentioned.
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?
Well-structured with Korean lead, English explanation, Args, and Returns sections. Slightly verbose but information-dense; every sentence adds value. Minor redundancy in repeating '청원' but acceptable.
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 5 parameters with 0% schema coverage and an output schema, the description comprehensively covers inputs, outputs, and limitations. It also includes troubleshooting guidance, making it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but the description provides detailed explanations for all 5 parameters, including examples, defaults, and functional behavior (e.g., include_closed switches endpoints). This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries petition records from the National Assembly, distinguishes between pending and closed petitions, and specifies what metadata it returns. It also contrasts with query_assembly and addresses limitations, effectively differentiating it 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (for petition metadata) and provides an alternative path (discover_apis → query_assembly) if keyword filtering fails. Also notes that full text is unavailable, setting expectations clearly.
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 that the tool returns proposer details (name, party, role) and the required bill_id format. Although it doesn't explicitly state it's read-only, the purpose implies no side effects. A score of 4 is appropriate as it adds sufficient context beyond what annotations would provide.
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 well-structured with clear sections: Korean/English purpose, when to use, important note, args, returns. Front-loaded with core purpose. Every sentence adds value; no wasted words.
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?
With only one parameter and an output schema present, the description fully covers input requirements (bill_id) and output structure (proposers list with fields, count, total_count). Provides usage context and examples. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It provides a detailed explanation of the bill_id parameter: format example, distinction from bill_no, and where to obtain it (from search_bills or get_pending_bills). This adds significant meaningful context beyond 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 verb ('Get') and resource ('complete list of proposers for a bill'). It distinguishes from sibling tools by specifying that it returns proposer details including name, party, and role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section provides two specific scenarios: after search_bills and for co-sponsorship network analysis. Also clearly warns about the BILL_ID vs BILL_NO distinction, telling agents when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: default page_size=300 intended to fetch all ~300 members, pagination explanation (has_more), and response field names. It also clarifies that if has_more=False and count<300, all votes are retrieved.
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-organized with sections, but it is somewhat lengthy. However, every sentence is purposeful and adds value. It is front-loaded with the core purpose and key workflow.
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?
The description is thorough given the tool's complexity (7 params, pagination, multiple filters) and the presence of an output schema (though not shown). It covers parameter usage, workflow integration, return fields, and pagination. Slightly verbose but complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has 0% coverage (no descriptions), the tool description provides detailed explanations for all 7 parameters, including examples, default values, valid values, and notes on field formats. This fully compensates for the missing schema descriptions.
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 individual member voting records for a specific bill (one row per member). It distinguishes itself from sibling tools like get_vote_results and get_party_cohesion by specifying its role as step 2 in a per-member vote analysis workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance via a 3-step workflow, warns about the common BILL_ID vs BILL_NO mistake, and explains when to use each filter (e.g., party for discipline analysis). This is comprehensive and leaves no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the registry covers a verified subset of 276+ endpoints, explains matching criteria (Korean/English name, category, etc.), and notes the return format (endpoints grouped by category).
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 Korean and English sections, workflow steps, when-to-use, args, and returns. It is slightly longer than necessary but every sentence adds value.
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 low complexity (1 optional param) and presence of an output schema, the description fully covers purpose, usage, parameter semantics, and limitations (verified subset, link to full catalog). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description must compensate. It explains that keyword matches against multiple fields and that omitting it returns all endpoints grouped by category, adding meaning beyond the simple string/null type.
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 searches the registry of verified Korean National Assembly API endpoints to find endpoint codes before calling query_assembly. It differentiates from sibling tools by specifying its role in the workflow (discover before query).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: to explore available endpoints, find a specific endpoint code, or see all endpoints by category. Also includes a fallback instruction if the endpoint is not found in the registry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully discloses internal behavior: it chains multiple API calls (up to 3 parallel), describes failure behavior (missing sections with error notes), and details the return structure including an errors field. This provides clear transparency beyond what any annotations would cover.
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 sections for purpose, usage, note, args, and returns. It is front-loaded with key information. While a bit lengthy, every sentence adds value given the tool's complexity (aggregating multiple APIs). Minor room for tightening.
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?
Despite having an output schema, the description provides a detailed return structure with example fields for each section. It covers failure scenarios, parameter sourcing, and sufficient context for an agent to determine when and how to use this tool compared to its many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the description compensates fully by providing examples (e.g., assembly: '22', bill_no: '2216983') and guidance to use the BILL_NO field from search_bills/get_pending_bills results. This adds critical context that the schema alone lacks.
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 is a one-shot summary of a single bill, combining metadata, processing timeline, co-sponsors, and committee meeting history. It distinguishes from sibling tools by explicitly listing the alternatives it replaces (get_bill_detail, get_bill_review, get_bill_proposers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description has a dedicated 'When to use' section, explicitly stating to use for a comprehensive view of one bill and not to call the individual tools separately. It also notes that up to 3 parallel API calls are made and that sections may be missing if sub-calls fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: endpoint used, data accuracy (party/district reflect actual assembly affiliation), pagination details (page, page_size, has_more), and return fields. No behavioral traits are hidden.
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?
Well-structured with a brief intro, when-to-use section, and args list. Every sentence adds value. Slightly verbose due to bilingual description (Korean then English), but overall efficient and front-loaded. Could be slightly more concise by merging the bilingual intro.
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 7 parameters, no annotations, and presence of output schema, the description is highly complete. It covers all parameters, return fields explicitly listed (members with field names, count, total_count, has_more), and pagination explained. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries full burden. It provides detailed parameter descriptions with Korean labels, example values, default values, and acceptable range for assembly. Each parameter is explained clearly, going well beyond 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 it queries National Assembly member information including party, district, committee, contact, photo. It specifies the exact data sources and distinguishes itself from sibling tools by noting it uses the ALLNAMEMBER endpoint for correct per-assembly data across all assemblies (16th-22nd).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: look up member affiliations, list party members, verify name spelling. Also includes a specific exclusion: for committee rosters, use get_committee_members instead. This helps the agent choose between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: two identifiers returned (BILL_NO, BILL_ID) with specific downstream usage, client-side date filtering with performance implications, coverage of bill propose-reason texts via external package, and the return format in 'Returns' section. This fully compensates for missing annotations.
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 and front-loaded with critical info (purpose, identifiers, workflow). However, it contains some redundancy with bilingual content and a slightly lengthy note about the external package. Still, every sentence adds value, and the structure aids scanning.
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 9 parameters, no annotations, and an output schema, the description fully covers all aspects: purpose, scope, parameters, behavioral quirks, return fields, and integration with sibling tools. It leaves no obvious gaps for an agent to make mistakes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It does so comprehensively in the 'Args' section: each parameter has description, optionality, expected format (if applicable), examples for bill_name/proposer/committee, enum values for proc_result, client-side note for propose_dt_from/to, and defaults/limits for page/page_size. This is ideal.
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 searches for member-sponsored bills (의원발의안), distinguishes from government-submitted bills (정부제출안은 별도), and explicitly calls itself the 'PRIMARY entry point for most bill-related queries.' The verb+resource+scope is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it's the primary entry point, covers only member-initiated bills (not government-submitted), and includes a typical workflow referencing sibling tools (get_bill_detail, get_bill_proposers, etc.). It also notes limitations (date filtering applied client-side) and performance trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses that the tool returns only hearing metadata (not full transcripts), mentions potential limitations of nominee_name filtering, and explains the return fields. This is comprehensive 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?
The description is lengthy due to bilingual content and detailed explanations, but it is well-structured with clear sections (purpose, usage, args, returns). Some redundancy could be trimmed, but it remains effective and informative.
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 number of parameters (6) and absence of annotations, the description covers all input parameters, return fields, usage scenarios, and even suggests alternative tools. It is comprehensive and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the 'Args' section in the description explains each parameter in detail, including required status, defaults, usage context, and examples. This adds significant meaning beyond the bare schema titles.
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 queries National Assembly hearings, specifying two types (confirmation and public) and their purposes. It distinguishes the tool from siblings like query_assembly by providing an alternative for filtering issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use each hearing type and filter by nominee_name or committee. Includes a fallback instruction: if nominee_name filtering fails, use query_assembly directly. This helps the agent choose the appropriate tool.
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:

[![open-assembly-mcp MCP server](https://glama.ai/mcp/servers/kyusik-yang/open-assembly-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kyusik-yang/open-assembly-mcp)

Score Badge

Copy to your README.md:

[![open-assembly-mcp MCP server](https://glama.ai/mcp/servers/kyusik-yang/open-assembly-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kyusik-yang/open-assembly-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/kyusik-yang/open-assembly-mcp'

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