Skip to main content
Glama
deenesjakoruzh
SHAYOUWORLD

houan-mcp

by SHAYOUWORLD
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

@codeagentjp/houan-mcp

Lokaler stdio-MCP-Server zur Suche nach japanischen Gesetzesentwürfen (衆参議案情報) und Ausschuss-Protokollen über die NDL Kokkai (国会会議録検索システム) API.

Dieser Server ruft kein LLM auf. Er liefert lediglich quellengestützte Daten aus dem Parlament mit primären URLs (NDL Kokkai, 衆議院議案情報, 参議院議案情報), sodass Ihr MCP-Client (Claude Desktop, Claude Code, Cursor oder ein anderer Agent) die Originalquelle zitieren kann.

Schwesterpaket: @codeagentjp/egov-law-mcp für aktuelle japanische Gesetze (e-Gov Law Search). houan-mcp deckt den Bereich des Gesetzgebungsprozesses ab: Gesetzesentwürfe in der Beratung, Ausschussbefragungen und vollständige Sitzungsprotokolle.

Status

MVP. Vier Tools:

  • find_diet_qa — Volltextsuche in allen Reden der Parlamentsausschüsse über die NDL Kokkai-API. Filterbar nach Datum, Kammer, Ausschuss, Redner.

  • get_meeting_record — Abruf des vollständigen Protokolls eines Ausschusses über die issueID.

  • search_bills — Suche nach Gesetzesentwürfen der aktuellen Sitzungsperiode in beiden Kammern nach Titel-Stichwort.

  • get_bill — Abruf von Details zu einem Gesetzesentwurf (Verfahrensverlauf, Ausschusszuweisung, URL zum Volltext).

Related MCP server: open-assembly-mcp

Anforderungen

  • Node.js 20 oder neuer

  • Netzwerkzugriff auf https://kokkai.ndl.go.jp, https://www.shugiin.go.jp, https://www.sangiin.go.jp

Installation

Über npm:

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

Aus dem Quellcode:

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

Volltextsuche in den Reden der Parlamentsausschüsse über die NDL Kokkai-API.

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

Gibt die gefundenen Reden mit Redner, Position, Ausschusskontext und direkter NDL-URL zurück.

get_meeting_record

Abruf eines vollständigen Protokolls über die issueID.

{
  "issueID": "122103968X00620260410"
}

search_bills

Suche in 衆議院議案情報 / 参議院議案情報 nach Titel-Stichwort.

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

get_bill

Abruf einer Detailseite zu einem Gesetzesentwurf (Verfahrensverlauf, Ausschusszuweisung, URL zum Volltext). Die proceedingURL muss eine von search_bills zurückgegebene URL sein — sie wird vor dem Abruf gegen das erlaubte Pfadpräfix der Kammer validiert.

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

Datenquellen und Quellenangaben

Dieses Paket nutzt drei öffentliche japanische Quellen:

Die Ergebnisse der Tools enthalten die Quell-URL. Wenn Sie Ausgaben, die auf diesem Paket basieren, veröffentlichen oder weitergeben, fügen Sie eine entsprechende Quellenangabe hinzu. Empfehlung:

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

Beispiel: Abruf einer Mythos-Fragerunde

Die Befragung vom 10.04.2026 im Auswärtigen Ausschuss des Unterhauses durch 宇佐美登 (Team Mirai) zum Anthropic Claude Mythos Preview kann wie folgt abgerufen werden:

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

Die Antwort enthält die wörtliche Antwort des Regierungsreferenten 花田貴裕 mit einer meetingURL, die auf das kanonische NDL-Protokoll unter https://kokkai.ndl.go.jp/txt/122103968X00620260410 verweist.

Sicherheitshinweise

  • Dieses Paket ist ein gesetzgeberisches Referenzwerkzeug, keine Rechts- oder Politikberatung.

  • Es führt keine Shell-Befehle aus.

  • Es schreibt JSON-RPC-Nachrichten nur nach stdout und protokolliert nur nach stderr.

  • Es ruft nur die NDL Kokkai-API und die Endpunkte für 衆/参 議案情報 ab.

  • Parlamentsprotokolle in der NDL erscheinen typischerweise mit einer Verzögerung von 1–2 Wochen nach der Ausschusssitzung. Wenn eine aktuelle Sitzung nicht gefunden werden kann, versuchen Sie es später erneut oder konsultieren Sie direkt die Videobibliothek der jeweiligen Kammer.

Verwandte Projekte

Lizenz

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
    -