Skip to main content
Glama
easakura

Japan Parliament Search MCP

by easakura

Japan Parliament Search MCP — 国会会議録検索

Give your AI agent access to every word spoken in Japan's National Diet since 1947.

This MCP server searches the official National Diet Library record system — ministerial statements, committee Q&A, and policy debates — the primary source for understanding Japanese government policy. Built for policy research, journalism, government-affairs, and compliance AI agents.

Why this server?

Japanese policy signals appear in Diet debates months before they become law or regulation. This data is public but effectively invisible to AI agents: Japanese-only, verbose, and buried in a legacy search interface. This server makes it queryable in one tool call.

Related MCP server: kokkai-mcp

Tools

search_speeches

Full-text search across all Diet speeches (1947–present). Filter by speaker, house (衆議院/参議院), meeting name, and date range. Returns speaker, position, party, date, an excerpt (or full text with full_text=true), and an official citation URL.

search_meetings

Find which plenary sessions and committees discussed a topic, and when — the bird's-eye view before drilling into individual speeches.

Example queries your agent can now answer

  • 「生成AIについて文部科学大臣は国会でどう答弁している?直近のものを引用して」

  • "When did the Diet last debate semiconductor subsidies, and in which committee?"

  • 「インボイス制度に関する財務省side答弁を2026年に絞って要約して」

Data source & freshness

Official National Diet Library (国立国会図書館) Kokkai Kaigiroku API, fetched live on every call. Records go back to 1947 and include the most recent published sessions.

Pricing

Pay per tool call. One speech search or one meeting search = one event. No subscription, no minimum.


日本語

国会会議録(1947年〜最新)の答弁・質疑をAIエージェントから全文検索できるMCPサーバーです。発言者・院・委員会・期間での絞り込み、出典URL付き。政策調査・報道・渉外・コンプライアンス系AIに最適です。

Get started

This is a hosted (remote) MCP server, available on Apify Store:

👉 https://apify.com/e-asakura/japan-parliament-search-mcp

The store page includes setup instructions for Claude, ChatGPT, Cursor, and any MCP-compatible client. Pay-as-you-go: $0.02 per tool call, no subscription.


Built by Edward Asakura — Japanese data infrastructure for AI agents. Part of the SEKISHO series: subsidies / laws / parliament.

Available Tools

2 tools
search_meetings国会の会議(委員会・本会議)を検索A

キーワードを含む国会の会議(本会議・委員会)単位で検索する。どの委員会でいつ議論されたかの全体像を掴むのに使う。個別の発言内容はsearch_speechesで取得する。

ParametersJSON Schema
NameRequiredDescriptionDefault
fromNo開始日 YYYY-MM-DD
houseNo院で絞り込み
queryYes検索語(例: 生成AI / 補助金)
untilNo終了日 YYYY-MM-DD
max_resultsNo最大件数(1〜10)

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It states the tool searches meetings by keyword but does not disclose behavioral traits such as sorting, pagination, authentication needs, or the exact structure of returned data. The max_results parameter is documented, offering minimal behavioral context.

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

Conciseness5/5

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

The description is very concise: two sentences with no wasted words. The first sentence states the core function, the second provides usage context and redirects to sibling. All information is front-loaded.

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

Completeness4/5

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

Given the absence of an output schema, the description does not explain the return format or fields. However, the tool is a search operation with well-documented parameters (100% coverage) and a clear purpose. The mention of the sibling tool adds completeness. A brief note on output structure would improve it, but it is mostly adequate.

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

Parameters3/5

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

Schema coverage is 100%, so the description adds limited extra meaning beyond the parameter descriptions. It mentions 'keyword' which is already in the query parameter description. No significant additional semantics.

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 Diet meetings (plenary and committee) by keyword. It uses specific verb 'search' and resource 'meetings', and explicitly distinguishes from the sibling tool search_speeches, which handles individual speech content.

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 explains when to use this tool (to get an overview of which committee discussed what and when) and explicitly directs the agent to search_speeches for individual speech content, providing a clear alternative.

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

search_speeches国会答弁・発言を検索A

日本の国会会議録(1947年〜最新)から発言を全文検索する。大臣答弁・質疑・政府見解の一次資料を、発言者・院・会議名・期間で絞り込める。政策調査・報道・ロビイング・コンプライアンス確認に有用。デフォルトは発言の冒頭抜粋を返す。full_text=trueで発言全文を取得(長い場合がある)。

ParametersJSON Schema
NameRequiredDescriptionDefault
fromNo開始日 YYYY-MM-DD
houseNo院で絞り込み
queryYes検索語(例: 生成AI / インボイス / 防衛費)
untilNo終了日 YYYY-MM-DD
meetingNo会議名で絞り込み(例: 予算委員会)
speakerNo発言者名で絞り込み(例: 岸田文雄)
full_textNotrueで発言全文を返す(既定は400字抜粋)
max_resultsNo最大件数(1〜10)

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It discloses default behavior (returns 400-character excerpt) and the full_text parameter effect, but does not mention rate limits, authentication needs, pagination, or any destructive aspects. It covers basic behavior but lacks depth.

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 very concise: four sentences in Japanese, totaling about 150 characters. It front-loads the core action and immediately provides context. Every sentence adds meaningful information without redundancy.

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

Completeness3/5

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

Given 8 parameters (one required) and no output schema, the description adequately explains the default behavior (excerpt vs. full text) and filtering options. However, it does not specify the output format (e.g., list of objects, sorting), pagination details, or how to handle empty results, leaving gaps for an AI agent.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema's parameter descriptions; it repeats the default excerpt length and full_text behavior, but does not provide significantly new semantic context for parameters like 'from', 'until', or 'speaker'.

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: full-text search of Japanese National Diet minutes from 1947 to latest, with specific filtering options (speaker, house, meeting, date range). It distinguishes itself from the sibling tool 'search_meetings' by focusing on speeches rather than meetings, even if not explicitly stated.

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

Usage Guidelines3/5

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

The description lists use cases (policy research, media, lobbying, compliance) but does not provide explicit guidance on when NOT to use the tool or when to prefer the sibling tool 'search_meetings' instead. Usage context is implied but not clearly delineated.

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.

  1. 2 tool updatesv0.1.0
    • First observedsearch_meetings
    • First observedsearch_speeches

TDQS

A4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: search_meetings focuses on meeting-level search to understand which committee discussed what, while search_speeches provides full-text speech search. There is no overlap in functionality.

Naming Consistency5/5

Both tools follow a consistent 'verb_noun' pattern with 'search_' prefix plus a plural noun (meetings, speeches), making the naming predictable and clear.

Tool Count4/5

Only 2 tools is slightly below the typical 3-15 range, but for a focused task like searching Japanese parliament records, this minimal set can be sufficient if it covers the core use cases of meeting discovery and speech retrieval.

Completeness3/5

The tools cover primary search needs but lack additional capabilities like retrieving individual meeting details, filtering by exact dates, or exporting results. Minor gaps that agents can work around with careful queries.

Maintenance

ActivityStale
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers