What can you do with this server?

Search and explore Korean National Assembly speeches, committees, and meetings using natural language queries in Korean or English. * search_speeches — Find speeches using a natural language query with optional filters: committee, speaker, speaker role, organization, date range, meeting type, assembly term, and result limit; optionally includes surrounding speech context * get_speech — Retrieve the full text and provenance details of a specific speech by its ID * get_speech_context — Access the ordered surrounding speech turns (before/after) around a specific speech, useful for understanding Q&A exchanges and debate flow * list_committees — List all indexed committees, optionally filtered by a search query or assembly term, showing coverage dates * list_meetings — Browse indexed meetings, optionally filtered by committee, date range, and meeting type * explore_issue — Multi-hop graph traversal connecting bills, committees, people, and speeches for deeper legislative research

How do I use Korean Assembly Speech MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Korean Assembly Speech MCP search speeches about AI regulation in the Science Committee" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Korean Assembly Speech MCP

by epoko77-ai

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Korean Assembly Speech MCP

Follow a Korean policy from bill status to the people, committees, and actual words behind it.

Korean & English queries · local-first · no paid API · FTS5 + E5 + FAISS · MCP + CLI

한국어 문서 · Architecture · Deployment · MCP clients · Data sources

KASM demo

Ask “Who raised concerns about sovereign AI?”, “What happened to bill 2200001?”, or “Show the subcommittee debate and the government's answers.” KASM traverses bill/agenda → status → committee/subcommittee → meeting → member → speech → surrounding Q&A. It combines official structured records with speech-level retrieval, acting as a small, evidence-first GraphRAG for legislative research.

	Bill lookup MCP	Korean Assembly Speech MCP
Result	an isolated API row	a connected bill-and-debate evidence graph
Retrieval	structured API lookup	lexical + multilingual semantic + RRF
English query	client chooses an API	directly retrieves Korean passages
Context	API metadata	status, committee/subcommittee, previous/next turns, Q&A
Verification	API record	original text, locator, meeting, official PDF
End-user key	often required	none for demo or public prepared-index MCP

Try it

The bundled demo is deliberately synthetic and clearly labeled. After package installation it proves the CLI and MCP contract without a key, model download, or upstream data call.

uvx korean-assembly-speech-mcp demo
uvx --from 'korean-assembly-speech-mcp[mcp]' kasm mcp

For a public deployment, an MCP client mounts one endpoint without credentials:

{
  "mcpServers": {
    "korean-assembly": {"url": "https://YOUR_HOST/mcp"}
  }
}

The operator's Open Assembly key belongs only in a separate refresh job. It is never required by clients and is not present in the public search container.

Related MCP server: LexLink Korean Law MCP Server

Search and synchronize

# Search a configured local/prepared index
kasm search "AI 기본법에 대한 정부 측 답변" --committee 과학기술정보방송통신위원회 \
  --database kasm.sqlite3 --vector-index kasm-vectors.faiss

# Operator-only official synchronization
kasm sync --source committee --assembly-term 22 --month 2025-01 --ingest \
  --all-pages --max-meetings 100 --database kasm.sqlite3

# Bills/agendas and their current processing results
kasm sync-bills --assembly-term 22 --all-pages --database kasm.sqlite3

# Local multilingual E5 + FAISS index
kasm index --database kasm.sqlite3 --output kasm-vectors.faiss --backend faiss

# stdio or stateless Streamable HTTP
kasm mcp --database kasm.sqlite3 --vector-index kasm-vectors.faiss
kasm mcp --transport streamable-http --host 0.0.0.0 --port 8000

Official synchronization uses only open.assembly.go.kr metadata and record.assembly.go.kr minutes. data.go.kr and third-party parliamentary datasets are out of scope. Set ASSEMBLY_OPEN_API_KEY only for kasm sync; raw caches, PDFs, .env, databases, and indexes are ignored by Git.

MCP tools

explore_issue — one-query GraphRAG traversal across bills, committees, people and speeches
search_bills — natural-language bill/agenda discovery with term, committee and status filters
get_bill_status — current outcome plus connected debate evidence
search_speeches — Korean/English policy-opinion retrieval with eight filters
get_speech — full speech record and stable provenance
get_speech_context — ordered surrounding speech turns
list_committees — indexed committees and covered dates
list_meetings — indexed meetings by committee, date, and type

Public clients need no Assembly key. The server operator uses a key only when producing refreshed SQLite/FAISS artifacts; clients query those prepared artifacts exactly like a public search index.

Measured gates

Checked-in scripts and artifacts make the results reproducible; synthetic evaluation data is explicitly labeled and never represented as Assembly speech text.

Gate	Corpus	Result
Official parser review	20 distinct official PDFs	20/20 reviewed boundaries pass
SQLite FTS5 latency	50,000 synthetic speeches	p95 4.46 ms
E5 English → Korean	25 qrels	Recall@10 1.00
Bilingual hybrid	50 queries	Recall@10 1.00, MRR@10 0.99

uv sync --extra dev --extra mcp --extra semantic
HF_HOME=.hf-cache uv run python scripts/evaluate_e5.py
HF_HOME=.hf-cache uv run python scripts/evaluate_hybrid.py
uv run python scripts/benchmark_fts.py
uv run ruff check . && uv run mypy && uv run pytest

Architecture and data integrity

Refresh and search are separate trust domains:

Open Assembly key → scheduled refresh → validated SQLite + FAISS artifacts
                                             ↓ atomic release
keyless MCP client → HTTPS /mcp → read-only prepared search artifacts

The fetcher allowlists the official minutes host, verifies PDF signatures, records SHA-256 and retrieval metadata, reports parser failures, and refuses mismatched vector metadata. The public ASGI service exposes /mcp and /healthz; mount /data read-only and rate-limit at ingress.

Development

Python 3.12 and 3.13 are tested in GitHub Actions.

uv sync --extra dev --extra mcp
uv run ruff check .
uv run mypy
uv run pytest --cov=kasm

See CONTRIBUTING.md, SECURITY.md, and the roadmap in SPEC.md.

License and records

Code is licensed under Apache-2.0. Parliamentary records and excerpts remain subject to their official source terms; source URLs and hashes are retained. The repository contains only small review fixtures, not the full parliamentary corpus. See DATA_LICENSE.md.

Available Tools

5 tools

get_speechD

ParametersJSON Schema

Name	Required	Description	Default
`speech_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

get_speech_contextD

ParametersJSON Schema

Name	Required	Description	Default
`after`	No
`before`	No
`speech_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

list_committeesD

ParametersJSON Schema

Name	Required	Description	Default
`query`	No
`assembly_term`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

list_meetingsD

ParametersJSON Schema

Name	Required	Description	Default
`date_to`	No
`committee`	No
`date_from`	No
`meeting_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

search_speechesD

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`date_to`	No
`speaker`	No
`committee`	No
`date_from`	No
`meeting_type`	No
`organization`	No
`speaker_role`	No
`assembly_term`	No
`include_context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Jul 11, 2026
- First observedget_speech
- First observedget_speech_context
- First observedlist_committees
- First observedlist_meetings
- First observedsearch_speeches

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2/5.0

Scored 2026-07-11 16:25 across 5 tools

Disambiguation4/5

The tool names are distinct: get_speech, get_speech_context, list_committees, list_meetings, and search_speeches each target different resources or actions. However, without descriptions, an agent might not fully understand the nuance between get_speech and get_speech_context, causing slight ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using underscores (get_speech, list_committees, search_speeches), which is predictable and easy to parse.

Tool Count4/5

With 5 tools, the set is focused and appropriate for a read-only API covering speeches, committees, and meetings. It is slightly minimal but fits the domain well.

Completeness4/5

The tool surface covers core operations: retrieving and searching speeches, listing committees and meetings. Minor gaps exist (e.g., no individual committee/meeting detail), but the main workflows are supported.

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Audioscrape Audio IntelligenceOAuth
com.audioscrape
Search speech in podcasts, government meetings, and your own audio: speakers, entities, timestamps.
Audio Processing Search Web Scraping
2
GavelinOAuth
ai.gavelin
Search bills and speaker-attributed hearing transcripts across all 50 US state legislatures.
Government Data Search Open Data
21
Congressional Documents A
io.github.pipeworx-io
Congressional Documents — full-text search and retrieval over the official
Government Data Search Open Data
341
ezelOAuth
ai.ezel
Search U.S. case law, fetch opinions, and ask matter-aware legal questions over your documents.
Legal & Compliance Search
2

Related MCP Servers

Kokkai Minutes MCP Agent
Government Data Search Documentation Access
egegungordu
F
license
A
quality
D
maintenance
Provides a structured interface to the Japanese National Diet Library's parliamentary proceedings API, allowing AI models to search and retrieve Diet meeting records and speeches.
Updated a year ago (2025-06-04 06:34 UTC)
3
1
-
LexLink Korean Law MCP Server
rabqatab
-
license
Not graded
quality
Not graded
maintenance
Enables searching and retrieving Korean legal information including laws, court precedents, legal interpretations, and local ordinances from the Korean National Law Information Center API with intelligent search ranking.
Updated 10 months ago (2025-11-04 16:22 UTC)
-
Korean National Assembly MCP
Government Data Open Data
hollobit
A
license
Not graded
quality
D
maintenance
Enables AI assistants to access real-time legislative data from the Korean National Assembly including members, bills, votes, and schedules through 276 Open APIs. Supports dual transport modes (stdio/HTTP), configurable Lite/Full tool profiles, and in-memory caching for efficient querying.
Updated 4 months ago (2026-05-02 05:09 UTC)
17
89
MIT
mcp-nosdeputes-fr
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables querying the French National Assembly data, including deputies, interventions, questions, and votes, through natural language.
Updated 17 days ago (2026-08-26 17:25 UTC)
9
MIT