How do I use houan-mcp?

1. Click on "Install 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., "@houan-mcp Find Diet committee discussions on AI regulation" 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.

de en es ja ko ru zh

houan-mcp

by SHAYOUWORLD

Overview Schema Related Servers Score Discussions

JavaScript

Remote

@codeagentjp/houan-mcp

Local stdio MCP server for searching Japanese Diet bills (衆参議案情報) and committee Q&A records via the NDL Kokkai (国会会議録検索システム) API.

This server does not call an LLM. It only returns source-backed Diet data, with primary URLs (NDL Kokkai, 衆議院議案情報, 参議院議案情報) so your MCP client (Claude Desktop, Claude Code, Cursor, or any other agent) can cite the original source.

Sister package: @codeagentjp/egov-law-mcp for current Japanese laws (e-Gov Law Search). houan-mcp covers the legislative process side: bills under deliberation, committee questionings, and full meeting transcripts.

Status

MVP. Four tools:

find_diet_qa — full-text search across all Diet committee speeches via the NDL Kokkai API. Filter by date, chamber, committee, speaker.
get_meeting_record — retrieve a single committee's full transcript by issueID.
search_bills — search current-session bills in either house by title keyword.
get_bill — retrieve detail of one bill (proceedings timeline, committee assignment, full-text URL).

Related MCP server: open-assembly-mcp

Requirements

Node.js 20 or later
Network access to https://kokkai.ndl.go.jp, https://www.shugiin.go.jp, https://www.sangiin.go.jp

Install

From npm:

{
  "mcpServers": {
    "houan": {
      "command": "npx",
      "args": ["-y", "@codeagentjp/houan-mcp"]
    }
  }
}

From source:

git clone https://github.com/SHAYOUWORLD/houan-mcp.git
cd houan-mcp
node bin/houan-mcp.mjs

{
  "mcpServers": {
    "houan": {
      "command": "node",
      "args": ["/absolute/path/to/houan-mcp/bin/houan-mcp.mjs"]
    }
  }
}

Tools

`find_diet_qa`

Full-text search of Diet committee speeches via the NDL Kokkai API.

{
  "keyword": "クロード ミトス",
  "from": "2026-04-01",
  "until": "2026-04-25",
  "chamber": "衆議院",
  "committee": "外務委員会",
  "limit": 5
}

Returns matched speeches with speaker, position, committee context, and direct NDL URL.

`get_meeting_record`

Retrieve a single full transcript by issueID.

{
  "issueID": "122103968X00620260410"
}

`search_bills`

Search 衆議院議案情報 / 参議院議案情報 by title keyword.

{
  "keyword": "情報",
  "chamber": "both",
  "session": 221,
  "limit": 20
}

`get_bill`

Retrieve a bill detail page (proceedings timeline, committee assignment, full-text URL). The proceedingURL must be a URL returned by search_bills — it is validated against the chamber's allowed path prefix before fetching.

{
  "chamber": "shugiin",
  "proceedingURL": "https://www.shugiin.go.jp/internet/itdb_gian.nsf/html/gian/keika/1DE..."
}

Data Sources and Attribution

This package uses three Japanese public sources:

NDL Kokkai (国会会議録検索システム) — https://kokkai.ndl.go.jp/ · API documentation. Diet records published 1947–. No auth required. Be a good neighbour: insert short delays between sequential requests, avoid concurrent bursts.
衆議院議案情報 — https://www.shugiin.go.jp/internet/itdb_gian.nsf/html/gian/menu.htm
参議院議案情報 — https://www.sangiin.go.jp/japanese/joho1/kousei/gian/index.htm

Tool results include the source URL. When you publish or redistribute output based on this package, include an appropriate attribution. Suggested:

出典: 国会会議録検索システム (https://kokkai.ndl.go.jp/) / 衆議院議案情報 / 参議院議案情報

Example: pulling a Mythos Q&A

The 4/10 2026 衆議院外務委員会 questioning by 宇佐美登 (チームみらい) on Anthropic's Claude Mythos Preview can be retrieved like this:

{
  "tool": "find_diet_qa",
  "arguments": {
    "keyword": "クロード",
    "from": "2026-04-01",
    "until": "2026-04-30"
  }
}

The response includes 花田貴裕政府参考人's verbatim answer with meetingURL pointing to the canonical NDL record at https://kokkai.ndl.go.jp/txt/122103968X00620260410.

Safety Notes

This package is a legislative reference tool, not legal/political advice.
It does not execute shell commands.
It writes JSON-RPC messages only to stdout and logs only to stderr.
It fetches only the NDL Kokkai API and 衆/参議案情報 endpoints.
Diet records in NDL typically appear with a 1–2 week lag after the committee meeting. If a recent meeting cannot be found, check back later or consult the chamber's video library directly.

Sibling MCP for current laws: @codeagentjp/egov-law-mcp
Roadmap (法令diff / 自治体条例 / 判例 MCPs): SHAYOUWORLD/egov-law-mcp#1
Background article: codeagent.jp / Tools

License

MIT © codeagent.jp

Available Tools

4 tools

find_diet_qaA

Full-text search of Japanese Diet committee speeches via the NDL Kokkai API. Returns speeches matching the keyword along with speaker, position, committee, and the canonical NDL URL.

ParametersJSON Schema

Name	Required	Description
`keyword`	Yes	Full-text query. Spaces are AND.
`from`	No	Date range start, YYYY-MM-DD.
`until`	No	Date range end, YYYY-MM-DD.
`chamber`	No	Chamber filter.
`committee`	No	Committee name, e.g. 外務委員会. Spaces are OR.
`speaker`	No	Speaker name.
`limit`	No	Maximum number of results. Defaults to 10.

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description must disclose behavior. It notes the return fields but omits details about sorting, pagination, error handling, or rate limits. The read-only nature is implicit but not explicitly stated.

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

Conciseness5/5

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

The description is a single, clear sentence that conveys the tool's purpose and key details without any extraneous information.

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 7 parameters and no output schema or annotations, the description covers the basics but lacks details on result ordering, default limit behavior, and error scenarios. It is functional but not comprehensive.

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

Parameters3/5

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

The input schema already has 100% parameter description coverage, so the description adds no additional semantics beyond listing return fields. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states it performs a full-text search of Japanese Diet committee speeches via a specific API, and returns speeches with speaker, position, committee, and URL. This distinguishes it from sibling tools that handle bills and meeting records.

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 implies this tool is for keyword searches within speeches, which is distinct from siblings (get_bill, get_meeting_record, search_bills). However, it does not explicitly state when not to use it or provide alternative guidance.

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

get_billA

Retrieve detail of one bill by chamber and proceedings URL. Returns title, submitter, committee assignment, and a status timeline parsed from the proceedings page. The proceedingURL must be a URL returned by search_bills.

ParametersJSON Schema

Name	Required	Description	Default
`chamber`	Yes	Chamber the bill is registered with.
`proceedingURL`	Yes	Proceedings URL returned by search_bills.

TDQS

A4/5.0

Behavior3/5

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

No annotations are present, so the description carries full burden. It describes a read-only retrieval operation without mentioning side effects, permissions, or error cases. Adequate but no extra context beyond the read nature.

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 two sentences, front-loaded with the action and result. Every sentence adds value without redundancy.

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?

Without an output schema, the description explains what is returned (title, submitter, committee assignment, status timeline). It does not detail the structure of the timeline, but it is reasonably complete for a simple retrieval tool.

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

Parameters3/5

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

Schema description coverage is 100%, so schema already documents parameters. The description adds the important constraint that proceedingURL must come from search_bills, providing 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 tool retrieves detail of one bill using chamber and proceedings URL, and specifies the returned fields (title, submitter, committee assignment, status timeline). It distinguishes itself from sibling tool search_bills which likely returns a list.

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 explicitly states that proceedingURL must be a URL returned by search_bills, guiding the agent to use search_bills first. No explicit when-not-to-use, but the constraint is clear.

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

get_meeting_recordA

Retrieve the full transcript of one Diet committee meeting by issueID via the NDL Kokkai API. Use the issueID from a find_diet_qa result.

ParametersJSON Schema

Name	Required	Description	Default
`issueID`	Yes	Meeting issueID, e.g. 122103968X00620260410.

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are present, so the description bears full responsibility. It states 'retrieve', indicating a read operation, but does not disclose potential behavior like error handling, rate limits, or output format. It's minimally adequate.

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?

Two sentences with no redundancy. First sentence front-loads the purpose, second adds usage guidance. Every word earns its place.

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 simplicity (1 param, no output schema), the description covers all essential aspects: what it retrieves, how to use it, and the source of the parameter. It is complete for its complexity.

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

Parameters3/5

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

Schema coverage is 100% with a description for issueID. The description adds context by saying it comes from find_diet_qa, which is helpful but does not significantly augment the schema. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states it retrieves the full transcript of a Diet committee meeting using issueID via a specific API, distinguishing it from sibling tools like find_diet_qa (for searching) and get_bill/search_bills (for bills).

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 explicitly says to use the issueID from find_diet_qa, providing direct guidance on prerequisite. It implies this tool is for retrieval after obtaining the ID, but does not explicitly mention when not to use it or list alternative tools.

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

search_billsA

Search current-session Japanese Diet bills (衆議院議案情報 / 参議院議案情報) by title keyword. Returns bill metadata with proceedings and full-text URLs.

ParametersJSON Schema

Name	Required	Description
`keyword`	Yes	Keyword to match in bill title.
`chamber`	No	Which chamber to search. Defaults to both.
`session`	No	Diet session number. Defaults to 221.
`limit`	No	Maximum number of results. Defaults to 30.

TDQS

A3.6/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 the burden of disclosing behavior. It describes a read-only search operation returning metadata, but lacks details on rate limits, authentication, pagination, or sorting behavior.

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

Conciseness4/5

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

The description is a single efficient sentence that front-loads the tool's action. It avoids unnecessary words, but might benefit from slight structuring (e.g., listing return items).

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 no output schema and 4 parameters, the description is short. It mentions return types (metadata, proceedings, URLs) but does not explain defaults or result interpretation, leaving some context gaps for a new user.

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

Parameters3/5

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

Input schema has 100% description coverage, so parameters are already well-documented. The description adds minimal extra meaning beyond stating the search is by title keyword, which is already implied by 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 searches Japanese Diet bills by title keyword and returns metadata with URLs. It uses a specific verb (search) and resource (bills), and distinguishes from siblings that retrieve specific bills or meeting records.

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

Usage Guidelines3/5

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

The description implies usage for searching bills by keyword, but does not explicitly state when to use this tool versus alternatives like get_bill or find_diet_qa, nor does it mention when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv1.0.0Apr 25, 2026
- First observedfind_diet_qa
- First observedget_bill
- First observedget_meeting_record
- First observedsearch_bills

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct resource: speeches (find_diet_qa), bills (get_bill, search_bills), and meeting transcripts (get_meeting_record). There is no overlap in functionality, making it easy for an agent to choose the correct tool.

Naming Consistency3/5

Tool names mix verb prefixes: 'find', 'get', and 'search'. While all use snake_case, the lack of a uniform verb-noun pattern (e.g., all 'get_...' or all 'search_...') creates mild inconsistency.

Tool Count5/5

Four tools is well-scoped for the domain of Japanese Diet information retrieval. Each tool serves a clear purpose without redundancy or excessive granularity.

Completeness4/5

The tool set covers search and retrieval for bills, speeches, and meeting transcripts, which are the core needs. Minor gaps exist (e.g., listing all committees or filtering by date), but they don't hinder primary workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

JP Bids AOAuth
io.github.sugukurukabe
Read-only MCP server for searching Japan government procurement bid information from the KKJ portal.
Government Data Search
2
Airweave SearchOAuth
io.github.airweave-ai
MCP server for searching Airweave collections with natural language queries.
Search Art & Culture Open Data
25,729
mcpOAuth
com.bullpenstrategygroup.rotunda
An MCP server that provides congressional transcripts
Government Data Search Open Data
2
Dados Abertos Senado BR MCP A
io.github.SidneyBissoli
MCP server for Brazilian Federal Senate open data (legislative, administrative, e-Cidadania).
Government Data Open Data
6925

Related MCP Servers

tdnet-disclosure-mcp
Finance Search
ajtgjmdjp
A
license
Not graded
quality
A
maintenance
MCP server for Japan's TDnet (Timely Disclosure network). Search and retrieve timely disclosure documents from listed companies on Japanese stock exchanges.
Updated 14 days ago (2026-08-23 08:17 UTC)
5
Apache 2.0
open-assembly-mcp
Government Data Open Data
kyusik-yang
A
license
A
quality
D
maintenance
MCP server for the Korean National Assembly Open API, enabling querying of bills, members, votes, committees, and more via natural language.
Updated 4 months ago (2026-05-19 03:03 UTC)
20
Apache 2.0
e-Gov Law MCP Server
Legal & Compliance Government Data
ymadd
A
license
A
quality
D
maintenance
MCP server for searching and retrieving Japanese laws from the e-Gov API, enabling natural language queries for legal information.
Updated 7 months ago (2026-02-05 18:22 UTC)
3
13
MIT
kokkai-giji-mcp
seiichi3141
F
license
B
quality
D
maintenance
MCP server that provides tools and prompts for searching Japanese Diet (国会) proceedings using the National Diet Library API. Enables querying meetings and speeches with various filters and obtaining direct URLs to the records.
Updated a year ago (2025-08-18 06:00 UTC)
3
38
-

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/SHAYOUWORLD/houan-mcp'

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