Skip to main content
Glama
deenesjakoruzh
SHAYOUWORLD

houan-mcp

by SHAYOUWORLD
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

@codeagentjp/houan-mcp

这是一个本地 stdio MCP 服务器，用于通过 NDL Kokkai（国会会议录检索系统）API 搜索日本国会法案（衆参議案情報）和委员会问答记录。

此服务器不调用 LLM。它仅返回基于来源的国会数据，并提供原始链接（NDL Kokkai、众议院法案信息、参议院法案信息），以便您的 MCP 客户端（Claude Desktop、Claude Code、Cursor 或任何其他代理）可以引用原始来源。

姊妹包：@codeagentjp/egov-law-mcp，用于查询现行日本法律（e-Gov 法律检索）。houan-mcp 涵盖了立法过程方面：审议中的法案、委员会质询以及完整的会议记录。

状态

MVP 版本。包含四个工具：

  • find_diet_qa — 通过 NDL Kokkai API 对所有国会委员会发言进行全文搜索。可按日期、议院、委员会、发言人进行筛选。

  • get_meeting_record — 通过 issueID 获取单个委员会的完整会议记录。

  • search_bills — 按标题关键词搜索两院当前会期的法案。

  • get_bill — 获取法案详情（审议时间表、委员会分配、全文 URL）。

Related MCP server: open-assembly-mcp

要求

  • Node.js 20 或更高版本

  • 可访问 https://kokkai.ndl.go.jp、https://www.shugiin.go.jp、https://www.sangiin.go.jp 的网络环境

安装

从 npm 安装：

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

从源码安装：

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"]
    }
  }
}

工具

find_diet_qa

通过 NDL Kokkai API 对国会委员会发言进行全文搜索。

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

返回匹配的发言，包含发言人、职位、委员会背景以及直接的 NDL URL。

get_meeting_record

通过 issueID 获取单个完整会议记录。

{
  "issueID": "122103968X00620260410"
}

search_bills

按标题关键词搜索众议院/参议院法案信息。

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

get_bill

获取法案详情页面（审议时间表、委员会分配、全文 URL）。proceedingURL 必须是 search_bills 返回的 URL — 在获取之前，它会根据议院允许的路径前缀进行验证。

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

数据来源与归属

此包使用了三个日本公共来源：

工具结果包含来源 URL。当您基于此包发布或重新分发输出时，请包含适当的归属说明。建议格式：

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

示例：获取 Mythos 问答

可以像这样检索 2026 年 4 月 10 日众议院外务委员会中宇佐美登（Team Mirai）关于 Anthropic Claude Mythos Preview 的质询：

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

响应包含花田贵裕政府参考人的逐字回答，其中 meetingURL 指向 https://kokkai.ndl.go.jp/txt/122103968X00620260410 处的规范 NDL 记录。

安全说明

  • 此包是一个立法参考工具，而非法律/政治建议。

  • 它不执行 shell 命令。

  • 它仅向 stdout 写入 JSON-RPC 消息，仅向 stderr 记录日志。

  • 它仅获取 NDL Kokkai API 和众/参议院法案信息端点的数据。

  • NDL 中的国会记录通常在委员会会议后 1-2 周内出现。如果找不到最近的会议，请稍后再试，或直接查阅议院的视频库。

相关项目

许可证

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
NameRequiredDescriptionDefault
keywordYesFull-text query. Spaces are AND.
fromNoDate range start, YYYY-MM-DD.
untilNoDate range end, YYYY-MM-DD.
chamberNoChamber filter.
committeeNoCommittee name, e.g. 外務委員会. Spaces are OR.
speakerNoSpeaker name.
limitNoMaximum 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
NameRequiredDescriptionDefault
chamberYesChamber the bill is registered with.
proceedingURLYesProceedings 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
NameRequiredDescriptionDefault
issueIDYesMeeting 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
NameRequiredDescriptionDefault
keywordYesKeyword to match in bill title.
chamberNoWhich chamber to search. Defaults to both.
sessionNoDiet session number. Defaults to 221.
limitNoMaximum 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.

  1. 4 tool updatesv1.0.0
    • First observedfind_diet_qa
    • First observedget_bill
    • First observedget_meeting_record
    • First observedsearch_bills
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 4 tools

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

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • tdnet-disclosure-mcp

    ajtgjmdjp
    A
    license
    Not graded
    quality
    B
    maintenance
    MCP server for Japan's TDnet (Timely Disclosure network). Search and retrieve timely disclosure documents from listed companies on Japanese stock exchanges.
    5
    Apache 2.0

  • open-assembly-mcp

    kyusik-yang
    A
    license
    A
    quality
    B
    maintenance
    MCP server for the Korean National Assembly Open API, enabling querying of bills, members, votes, committees, and more via natural language.
    20
    655 PyPI
    Apache 2.0

  • 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.
    3
    38
    -