Skip to main content
Glama
deenesjakoruzh
SHAYOUWORLD

houan-mcp

by SHAYOUWORLD
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

@codeagentjp/houan-mcp

NDL 국회(국회회의록 검색 시스템) API를 통해 일본의 국회 의안(衆参議案情報) 및 위원회 질의응답 기록을 검색하기 위한 로컬 stdio MCP 서버입니다.

이 서버는 LLM을 호출하지 않습니다. 오직 출처가 명확한 국회 데이터만을 반환하며, MCP 클라이언트(Claude Desktop, Claude Code, Cursor 등)가 원본 출처를 인용할 수 있도록 기본 URL(국회회의록 검색 시스템, 중의원 의안 정보, 참의원 의안 정보)을 제공합니다.

자매 패키지: 현행 일본 법령을 위한 @codeagentjp/egov-law-mcp (e-Gov 법령 검색). 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..."
}

데이터 출처 및 저작자 표시

이 패키지는 세 가지 일본 공공 출처를 사용합니다:

도구 결과에는 출처 URL이 포함됩니다. 이 패키지를 기반으로 결과물을 게시하거나 재배포할 때는 적절한 저작자 표시를 포함하십시오. 권장 문구:

출처: 국회회의록 검색 시스템 (https://kokkai.ndl.go.jp/) / 중의원 의안 정보 / 참의원 의안 정보

예시: Mythos 질의응답 가져오기

Anthropic의 Claude Mythos Preview에 대한 2026년 4월 10일 중의원 외무위원회에서의 우사미 노보루(팀 미라이)의 질의는 다음과 같이 가져올 수 있습니다:

{
  "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
    -