Skip to main content
Glama
deenesjakoruzh
SHAYOUWORLD

houan-mcp

by SHAYOUWORLD
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

@codeagentjp/houan-mcp

NDL国会会議録検索システムAPIを介して、日本の議案情報（衆参）および委員会質疑記録を検索するためのローカルstdio MCPサーバーです。

このサーバーはLLMを呼び出しません。ソースに基づいた国会データのみを返し、主要なURL（国会会議録検索システム、衆議院議案情報、参議院議案情報）を提供するため、MCPクライアント（Claude Desktop、Claude Code、Cursor、その他のエージェント）が元のソースを引用できます。

姉妹パッケージ: 現行の日本法（e-Gov法令検索）を扱う @codeagentjp/egov-law-mcp。houan-mcp は立法プロセス側、つまり審議中の議案、委員会質疑、会議録全文をカバーします。

ステータス

MVP。4つのツールを提供します：

  • find_diet_qa — NDL国会会議録検索システム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国会会議録検索システム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..."
}

データソースと帰属表示

このパッケージは、以下の3つの日本の公開ソースを使用しています：

ツールの結果にはソースURLが含まれます。このパッケージに基づいた出力を公開または再配布する場合は、適切な帰属表示を含めてください。推奨例：

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

例: Mythosに関する質疑の取得

2026年4月10日の衆議院外務委員会における、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公式記録を指しています。

安全上の注意

  • 本パッケージは立法参照ツールであり、法的・政治的助言を行うものではありません。

  • シェルコマンドは実行しません。

  • JSON-RPCメッセージはstdoutにのみ書き出し、ログはstderrにのみ出力します。

  • NDL国会会議録検索システム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
    -