Skip to main content
Glama
epoko77-ai

Korean Bill & Debate MCP

by epoko77-ai

explore_issue

Read-only

Retrieve evidence-ranked Korean bill and debate records across subcommittee, committee, and plenary stages, with cited speeches and stage-by-stage review for bounded policy questions.

Instructions

Return one detailed, answer-ready review across every requested legislative stage.

    필수: 이 도구는 한 번만 호출하고 ``answer_brief.mandatory_coverage``를 최종 답변의
    체크리스트로 사용하세요. 소위·상임위·본회의를 각각 독립 절로 쓰고 모든
    ``direct_claim_evidence``를 발언자별 주장·이유·답변까지 반영해야 합니다. 본회의
    찬반토론과 같은 발언의 ``supplemental_excerpts``를 생략하거나 짧은 발언자 목록으로
    대체하면 미완성 답변입니다. 답변 직전 단계별 반환 건수와 후반 논거 수를 대조하세요.

    상위 N건, ``5개 정도``, 중요 법안 요약처럼 범위가 제한된 일반 질문의 기본
    도구입니다. ``limit``는 사용자가 요구한 결과 수를 그대로 반영하세요. 전건·전수·
    빠짐없이·역대 조사는 ``exhaustive=true``로 호출하거나 ``start_research``를
    사용하세요.

    Use this as the primary tool for bounded Korean or English questions asking what happened,
    who argued what, or how a policy and bill evolved. A single law nickname plus requested
    subcommittee, standing-committee, and plenary stages belongs here. Call this tool once;
    do not precede or follow it with redundant bill/meeting/speech discovery unless next_action
    explicitly requests a continuation. Results include evidence-ranked speeches,
    ordered multi-turn discussion threads, bill and review-report links, official provenance,
    and live-check metadata. Long research is deliberately paged so no evidence is silently
    truncated and no single connector request times out. Call this tool again only when
    ``research_pagination.next_minutes_offset`` is present, using that offset and the same
    query/date scope. If it is absent, synthesize the bounded result and disclose any deadline,
    source, or stage gap instead of repeating discovery. Call get_bill_status only for the one
    exact primary bill identified by the result
    when the user needs its expert review report; never call it for every candidate.
    It queries official Open Assembly APIs before searching the private local cache and reports
    bounded-refresh diagnostics. When ``answer_brief`` is present it is the mandatory
    synthesis contract. Cover every requested stage and every returned
    ``direct_claim_evidence`` turn and every ``supplemental_excerpts`` continuation, grouping
    only genuinely redundant arguments. Preserve enumerated reasons (first, second, final,
    and so on) as separate subpoints instead of summarizing only the beginning of a long turn.
    Explain the measure identity, timeline, issue map, claim/reason/response/outcome flow,
    actor types, disposition, coverage ledger, and sources; a short speaker bullet list is not
    complete.
    Synthesize the answer from actual turns; do not infer a stance that is not supported by a
    quoted speech. Put each quote's citation.official_url next
    to the claim so the user can open and verify the original minutes immediately. Source
    records are Korean; answer English users in English and identify translated quotations.
    For unfamiliar English subjects, supply concise Korean keywords in korean_query.

    With a durable backend, only ``exhaustive=true``, an explicit exhaustive phrase, or an
    explicit multi-Assembly scope is routed to ``start_research``. Ordinary
    requests use the live Open Assembly APIs and honor ``limit``. Bounded results must not be
    described as an exhaustive inventory; expose their pagination and source coverage as-is.
    

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYes
date_toNo
date_fromNo
committeesNo
exhaustiveNo
korean_queryNo
assembly_termNo
minutes_offsetNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.3

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, it discloses that results include evidence-ranked speeches, ordered discussion threads, bill/report links, official provenance, live-check metadata, and bounded-refresh diagnostics. It explains paging behavior, the answer_brief synthesis contract, citation URL placement, and Korean-source translation handling.

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 very long and repetitive, repeating the answer_brief contract, stage coverage rules, and evidence-turn requirements in both Korean and English. While the opening is front-loaded, much of the prose restates the same mandatory synthesis rules.

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 and the presence of an output schema, the description covers most operational context: routing, pagination, synthesis obligations, citations, provenance, and source-language handling. Its main gap is incomplete parameter semantics for several non-required inputs.

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 0%, so the description must carry parameter meaning. It explains limit, exhaustive, korean_query, and minutes_offset, but leaves date_from, date_to, committees, and assembly_term largely undocumented, including formats and expected values.

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 states a specific verb and resource: returning one detailed, answer-ready review across requested legislative stages. It clearly identifies the bounded Korean/English question types it serves and distinguishes itself from exhaustive research via start_research and from get_bill_status for expert review reports.

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?

It gives explicit routing rules: use this as the primary tool for bounded questions, call it once, do not precede or follow with redundant discovery, and only call again when research_pagination.next_minutes_offset is present. It also explicitly routes exhaustive or multi-Assembly requests to exhaustive=true or start_research.

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