Which integrations are available for this server?

Enables n8n workflows to search and retrieve procurement notices from the Kanpo API via HTTP endpoints.

How do I use kanpou-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., "@kanpou-mcp Find recent IT procurement notices from Tokyo" 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.

kanpou-mcp

by yoshinaga2015

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

官報API MCPサーバー

官公需情報ポータルサイトAPI（官報API）をLLMやAIエージェントがツールとして使用できるようにするMCP（Model Context Protocol）サーバーです。

機能

このMCPサーバーは以下のツールを提供します：

search_procurements - 詳細な検索条件で入札情報を検索
get_procurements_by_date - 指定した日付の入札情報を取得
search_by_keyword - キーワードで入札情報を検索

Related MCP server: koko-call-mcp

インストール

cd mcp-kanpo-api
npm install
npm run build

使用方法

MCPクライアントでの設定

MCPクライアント（例: Claude Desktop、Cursor等）の設定ファイルに以下を追加してください：

Claude Desktopの場合 (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "kanpo-api": {
      "command": "node",
      "args": ["/path/to/mcp-kanpo-api/dist/index.js"]
    }
  }
}

Cursorの場合 (.cursor/mcp.json または設定ファイル):

{
  "mcpServers": {
    "kanpo-api": {
      "command": "node",
      "args": ["/path/to/mcp-kanpo-api/dist/index.js"]
    }
  }
}

開発モード

開発中は tsx を使用して直接実行できます：

npm run dev          # stdio版
npm run dev:http     # HTTP版

HTTPサーバー版の使用方法

n8nなどのHTTPクライアントから使用する場合は、HTTPサーバー版を起動します：

npm run start:http

デフォルトで http://localhost:3000 で起動します。ポート番号は環境変数 PORT で変更できます：

PORT=8080 npm run start:http

利用可能なエンドポイント

GET / - ヘルスチェック
GET /api/tools - 利用可能なツール一覧
POST /api/tools/search_procurements - 入札情報検索
POST /api/tools/get_procurements_by_date - 日付指定取得
POST /api/tools/search_by_keyword - キーワード検索

使用例

# 日付指定で取得
curl -X POST http://localhost:3000/api/tools/get_procurements_by_date \
  -H "Content-Type: application/json" \
  -d '{"date": "2025-11-07", "count": 50}'

# キーワード検索
curl -X POST http://localhost:3000/api/tools/search_by_keyword \
  -H "Content-Type: application/json" \
  -d '{"keyword": "情報システム", "count": 20}'

ngrokでの公開

ngrokを使用してHTTPサーバーを外部公開できます：

# 1. HTTPサーバーを起動
npm run start:http

# 2. 別のターミナルでngrokを起動
ngrok http 3000

# 3. ngrokが提供するURL（例: https://xxxx-xxxx-xxxx.ngrok-free.app）をn8nで使用

自然言語での使用方法

このMCPサーバーは、LLM/AIエージェント（Claude、GPT-4等）が自然言語の命令を理解して、適切なツールを自動的に呼び出すことを想定しています。

使用例:

「2025年11月7日の入札情報を取得して」→ get_procurements_by_date ツールが自動的に呼び出されます
「情報システムというキーワードで検索して」→ search_by_keyword ツールが自動的に呼び出されます
「東京都の物品カテゴリーの入札情報を検索して」→ search_procurements ツールが自動的に呼び出されます
「11月の役務カテゴリーの入札情報を検索して」→ search_procurements ツールが自動的に呼び出されます

LLM/AIエージェントは、あなたの自然言語の命令を理解し、適切なツールとパラメータを選択して実行します。

利用可能なツール

1. search_procurements

詳細な検索条件で入札情報を検索します。

パラメータ:

query (string, 任意): 検索文字列（AND、OR、NOT演算子使用可能）
projectName (string, 任意): 件名で絞り込み
organizationName (string, 任意): 機関名で絞り込み
lgCode (string, 任意): 都道府県コード（JIS X0401準拠）
category (number, 任意): カテゴリー（1=物品, 2=工事, 3=役務）
procedureType (number, 任意): 公示種別（1=一般競争入札, 2=簡易公募型競争入札, 3=簡易公募型指名競争入札）
certification (string, 任意): 入札資格（A, B, C, D）
cftIssueDate (string, 任意): 公告日（形式: YYYY-MM-DD/ または /YYYY-MM-DD または YYYY-MM-DD/YYYY-MM-DD）
tenderSubmissionDeadline (string, 任意): 入札開始日
openingTendersEvent (string, 任意): 開札日
periodEndTime (string, 任意): 納入期限日
count (number, 任意): 返却件数（デフォルト: 100、最大: 1000）

注意: query、projectName、organizationName、lgCodeのいずれか一つを指定することを推奨します。すべてが指定されない場合は、デフォルトでQuery="*"が使用されます。

2. get_procurements_by_date

指定した日付の入札情報を取得します。内部ではquery="入札"とcftIssueDateを指定して検索を実行します。

パラメータ:

date (string, 必須): 日付（形式: YYYY-MM-DD）
count (number, 任意): 返却件数（デフォルト: 100、最大: 1000）

例:

{
  "date": "2025-11-07",
  "count": 50
}

3. search_by_keyword

キーワードで入札情報を検索します。

パラメータ:

keyword (string, 必須): 検索キーワード
count (number, 任意): 返却件数（デフォルト: 100、最大: 1000）

例:

{
  "keyword": "情報システム",
  "count": 20
}

レスポンス形式

MCP版（stdio）

すべてのツールは以下の形式でレスポンスを返します：

{
  "searchHits": 262,
  "results": [
    {
      "resultId": 1,
      "key": "...",
      "externalDocumentURI": "https://...",
      "projectName": "第2069号小中学校児童生徒用机・いす",
      "date": "2025-11-07T19:08:01+09:00",
      "fileType": "pdf",
      "fileSize": 134411,
      "lgCode": "19",
      "prefectureName": "山梨県",
      "cityCode": "192015",
      "cityName": "甲府市",
      "organizationName": "山梨県甲府市",
      "cftIssueDate": "2025-11-07T00:00:00+09:00",
      "category": "物品",
      "procedureType": "一般競争入札",
      "projectDescription": "...",
      "attachments": [
        {
          "name": "入札説明書（PDF：132KB）",
          "uri": "https://..."
        }
      ]
    }
  ]
}

HTTP版

HTTPサーバー版は以下の形式でレスポンスを返します：

{
  "success": true,
  "data": {
    "searchHits": 262,
    "results": [
      {
        "resultId": 1,
        "projectName": "第2069号小中学校児童生徒用机・いす",
        "organizationName": "山梨県甲府市",
        "cftIssueDate": "2025-11-07T00:00:00+09:00",
        "category": "物品",
        "procedureType": "一般競争入札",
        ...
      }
    ]
  }
}

エラーの場合：

{
  "success": false,
  "error": "エラーメッセージ"
}

注意事項

このAPIは官公需情報ポータルサイトのAPIを使用しています
登録・認証は不要で誰でも利用可能です
利用規約を遵守してください
APIのレスポンスはXML形式ですが、このMCPサーバーはJSON形式に変換して返します

参考資料

ライセンス

MIT

Available Tools

3 tools

get_procurements_by_dateA

指定した日付の入札情報を取得します。公告日で検索します。

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes	日付（形式: YYYY-MM-DD）
`count`	No	返却する検索結果の最大件数（デフォルト: 100、最大: 1000）

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic operation and search field, with no mention of pagination, result limits, error behavior, or output format. This is minimal for a tool with zero annotation support.

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 short sentences, efficiently conveying the core purpose and search field with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the simple nature of the tool, the description lacks any mention of return values, which is critical since no output schema is provided. With no annotations and no output schema, the agent is left without information about what the tool returns or expects.

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

Parameters4/5

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

The schema already fully covers both parameters, but the description adds meaning by specifying that the date parameter refers to the announcement date, which is not explicitly stated in the schema. This supplementary context helps the agent understand the parameter semantics better.

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 procurement information for a specified date, and specifically by announcement date. This distinguishes it from sibling tools like search_by_keyword, which are likely keyword-based.

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 date-based searches but provides no explicit guidance on when to use this tool versus the sibling tools. It does not mention alternatives or exclusions.

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

search_by_keywordC

キーワードで入札情報を検索します。

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	返却する検索結果の最大件数（デフォルト: 100、最大: 1000）
`keyword`	Yes	検索キーワード

TDQS

C2.9/5.0

Behavior2/5

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

There are no annotations, so the description must convey behavioral traits. It only states the basic search action without disclosing return format, pagination behavior, or any limitations. As a read operation, it does not explicitly confirm safety or side-effect-free 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, concise sentence with no redundancy. It is front-loaded with the key action, though it is too brief to provide extra context, which slightly reduces its usefulness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations and output schema, the description is insufficiently complete. It does not mention how results are returned, any filtering limitations, or how it differs from sibling tools. The simple parameter set mitigates this slightly, but the description still lacks necessary context.

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%, with both 'keyword' and 'count' already described in the input schema. The description adds no additional parameter meaning beyond what the schema provides, so a baseline of 3 is appropriate.

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

Purpose4/5

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

The description clearly identifies the action ('search') and the resource ('bidding information') and specifies the method ('by keyword'). However, it does not explicitly distinguish this tool from sibling 'search_procurements', which may overlap in functionality.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus search_procurements or get_procurements_by_date. The description lacks any context for tool selection or exclusions.

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

search_procurementsA

官公需情報ポータルサイトAPIを使用して入札情報を検索します。日付、キーワード、カテゴリー、都道府県などで絞り込めます。

ParametersJSON Schema

Name	Required	Description
`count`	No	返却する検索結果の最大件数（デフォルト: 100、最大: 1000）
`query`	No	検索文字列（AND、OR、NOT演算子使用可能）。Query、Project_Name、Organization_Name、LG_Codeのいずれかは必須です。
`lgCode`	No	都道府県コード（JIS X0401準拠、カンマ区切りで複数指定可能）（必須パラメータのいずれか）
`category`	No	カテゴリー: 1=物品, 2=工事, 3=役務
`projectName`	No	件名で絞り込み（必須パラメータのいずれか）
`cftIssueDate`	No	公告日またはデータ取得日（形式: YYYY-MM-DD/ または /YYYY-MM-DD または YYYY-MM-DD/YYYY-MM-DD）
`certification`	No	入札資格: A, B, C, D（カンマ区切りで複数指定可能）
`periodEndTime`	No	納入期限日（形式: YYYY-MM-DD/ または /YYYY-MM-DD または YYYY-MM-DD/YYYY-MM-DD）
`procedureType`	No	公示種別: 1=一般競争入札, 2=簡易公募型競争入札, 3=簡易公募型指名競争入札
`organizationName`	No	機関名で絞り込み（必須パラメータのいずれか）
`openingTendersEvent`	No	開札日（形式: YYYY-MM-DD/ または /YYYY-MM-DD または YYYY-MM-DD/YYYY-MM-DD）
`tenderSubmissionDeadline`	No	入札開始日（形式: YYYY-MM-DD/ または /YYYY-MM-DD または YYYY-MM-DD/YYYY-MM-DD）

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the tool uses an external API and can filter, but does not disclose whether it's read-only, any rate limits, authentication requirements, pagination behavior, or result format. This is a significant transparency gap for a search tool.

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, front-loaded sentence that states the core function and key filter capabilities without any redundant wording. It is appropriately sized for the information it conveys.

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?

Despite having 12 parameters and no output schema, the description is very brief. It does not mention the requirement that at least one of query, projectName, organizationName, or lgCode must be provided, nor does it explain how it relates to sibling tools. The rich schema descriptions compensate, but the description itself lacks contextual depth for such a complex 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%, with each parameter already having a detailed description (including required alternations and date formats). The tool description only generically mentions filter types (date, keyword, category, prefecture), adding no specific parameter semantics beyond what the schema already provides. 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 the tool searches for bid information using a specific API, with a clear verb '検索します' (search) and resource '入札情報' (bid information). It lists multiple filtering dimensions (date, keyword, category, prefecture), distinguishing it from the more narrow sibling tools get_procurements_by_date and search_by_keyword.

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 multifaceted searches by mentioning multiple filter criteria, but does not explicitly state when to prefer this tool over the siblings or provide exclusions. It lacks explicit when-to-use or alternative guidance, so usage context is only implied.

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.

3 tool updatesv1.0.0Aug 9, 2026
- First observedget_procurements_by_date
- First observedsearch_by_keyword
- First observedsearch_procurements

Install Server

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

TDQS

B3.2/5.0

Scored 2026-08-09 15:50 across 3 tools

Disambiguation2/5

search_procurements already supports keyword and date filters, making get_procurements_by_date and search_by_keyword redundant specializations. Agents may struggle to decide which tool to use, as the boundaries are unclear and overlapping.

Naming Consistency4/5

All tool names follow a verb_noun pattern with consistent snake_case style. The slight inconsistency is that 'search_by_keyword' does not explicitly mention 'procurements' like the others, but it remains readable and predictable.

Tool Count4/5

Three tools is a reasonable count for a focused procurement search server. However, two tools are largely redundant subsets of the first, which suggests the count could be trimmed without losing functionality.

Completeness3/5

The server covers general search, date-based lookup, and keyword lookup, but lacks a way to fetch a specific procurement by ID or view detailed information. This is a notable gap for a procurement search domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

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
tenderapi-mcp A
io.github.IDNSIDNS
MCP server for French (BOAMP) + EU (TED) public procurement data via TenderAPI.
Government Data Open Data Search
31
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
geojp
io.github.55tarkun
MCP server for Japan geodata: cadastral lot numbers (chiban) and reverse geocoding, for AI agents.
Location Services Open Data Government Data
1

Related MCP Servers

jgrants-mcp-serverofficial
Government Data Search
digital-go-jp
A
license
Not graded
quality
D
maintenance
MCP server for Japan's Jグランツ grant application system, enabling LLMs to search and retrieve subsidy information via natural language.
Updated 5 months ago (2026-04-06 07:42 UTC)
50
MIT
koko-call-mcp
Government Data Search
sugukurukabe
A
license
Not graded
quality
A
maintenance
Read-only MCP server for searching Japanese government procurement bid notices (官公需) from the SME Agency's KKJ portal. Includes AI ranking, PDF requirement extraction, and CSV/calendar export.
Updated 13 days ago (2026-08-29 16:37 UTC)
239
Apache 2.0
houjin-bangou-api-mcp
Government Data Search
yamayued
A
license
B
quality
D
maintenance
MCP server for the Japan National Tax Agency Corporate Number API, enabling corporate number lookup and search via local AI clients.
Updated 6 months ago (2026-03-13 04:22 UTC)
3
1
MIT
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

官報API MCPサーバー

機能

インストール

使用方法

MCPクライアントでの設定

開発モード

HTTPサーバー版の使用方法

利用可能なエンドポイント

使用例

ngrokでの公開

自然言語での使用方法

利用可能なツール

1. search_procurements

2. get_procurements_by_date

3. search_by_keyword

レスポンス形式

MCP版（stdio）

HTTP版

注意事項

参考資料

ライセンス

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

jgrants-mcp-serverofficial

koko-call-mcp

houjin-bangou-api-mcp

e-Gov Law MCP Server