jgrants-mcp-serverofficial
A
licenseNot graded
qualityD
maintenanceMCP server for Japan's Jグランツ grant application system, enabling LLMs to search and retrieve subsidy information via natural language.
50
MIT
jgrants-mcp
This server provides access to Japanese government subsidy information from the jGrants public API, enabling you to search subsidies, retrieve detailed information, and download official documents.
Core capabilities:
Search subsidies (
list_subsidies) - Find currently accepting programs using Japanese keywords (defaults to "補助金")Get detailed information (
get_subsidy_detail) - Retrieve comprehensive details including eligibility, funding limits, target regions, and attachment metadata (file names, sizes, indexes)Download documents (
download_attachment) - Access official files as Base64-encoded content:Application guidelines (公募要領)
Grant outline documents (交付要綱)
Application forms (申請様式)
Key features:
Returns structured data optimized for LLM processing
No API key required
Efficient attachment handling with metadata access before downloading
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@jgrants-mcp介護施設向けの補助金を検索して"
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.
jgrants-mcp
日本の補助金情報を検索するための MCP (Model Context Protocol) サーバー
概要
jgrants-mcp は、jGrants（デジタル庁が運営する補助金電子申請システム）の公開 API をラップした MCP サーバーです。LLM から MCP を経由して日本の補助金情報に簡単にアクセスできます。
Related MCP server: houjin-bangou-api-mcp
機能
以下の 3 つのツールを提供します。すべてのツールは structuredContent フィールドで構造化データを返すため、LLM が効率的に処理できます。
1. list_subsidies
指定したキーワードで公募中の補助金一覧を取得します。
パラメータ:
keyword(文字列, オプション): 検索キーワード（デフォルト: "補助金"）
返却データ:
補助金のリスト（id, name, title, 対象地域, 補助上限額など）
2. get_subsidy_detail
補助金の詳細情報を取得します。添付ファイルは軽量なメタデータ（ファイル名、サイズ、インデックス）のみを返し、Base64 データは含まれません。
パラメータ:
subsidy_id(文字列, 必須): 補助金の ID（list_subsidiesで取得した id を指定）
返却データ:
補助金の詳細情報
各添付カテゴリの
AttachmentGroup:count: 添付ファイル数hasAttachments: 添付の有無attachments: ファイル情報の配列index: ダウンロード時に指定するインデックスname: ファイル名sizeBytes: ファイルサイズ（バイト）
3. download_attachment
指定した補助金の添付ファイルをダウンロードします。Base64 エンコードされたファイルデータとメタデータを返します。
パラメータ:
subsidy_id(文字列, 必須): 補助金の IDcategory(文字列, 必須): 添付文書のカテゴリapplication_guidelines: 公募要領outline_of_grant: 交付要綱application_form: 申請様式
index(整数, 必須): 添付文書のインデックス（get_subsidy_detailのattachments[n].indexを指定）
返却データ:
file_name: ファイル名data: Base64 エンコードされたファイルデータdata_size_bytes: ファイルサイズencoding: エンコード形式（常に "base64"）
インストール
npm 経由でグローバルインストール
npm install -g jgrants-mcpnpx で直接実行
npx jgrants-mcpローカル開発
git clone https://github.com/tachibanayu24/jgrants-mcp.git
cd jgrants-mcp
npm install
npm run build使用方法
Claude Desktop での設定
Claude Desktop の設定ファイル（~/Library/Application Support/Claude/claude_desktop_config.json）に以下を追加：
{
"mcpServers": {
"jgrants": {
"command": "npx",
"args": ["jgrants-mcp"]
}
}
}他の MCP クライアントでの使用
MCP に対応した任意のクライアントから利用可能です。
使用例
1. 補助金を検索
ユーザー: 「介護施設向けの補助金を探して」→ LLM が list_subsidies を keyword: "介護" で実行
2. 詳細情報を取得
ユーザー: 「ID a0WJ200000CDTxsMAH の補助金の詳細を教えて」→ LLM が get_subsidy_detail を実行し、以下の情報を取得：
補助金の詳細（対象者、補助率、上限額など）
添付ファイルのメタデータ（ファイル名とサイズ）
3. 添付ファイルをダウンロード
ユーザー: 「公募要領をダウンロードして」→ LLM が download_attachment を実行：
category: "application_guidelines"index: 0（詳細情報から取得）
開発
必要な環境
Node.js 18 以上
npm または yarn
ビルド
npm run build開発モード
npm run devAPI について
このツールは jGrants の公開 API（https://api.jgrants-portal.go.jp/exp/v1/public）を使用しています。API キーは不要です。
ライセンス
MIT
Available Tools
3 toolsdownload_attachmentA
Download a subsidy's attachment document. Returns the file data in base64 encoding along with metadata. First call get_subsidy_detail to see the attachments array for each category (application_guidelines, outline_of_grant, application_form), then use the 'index' from attachments[n].index to download the specific file.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| subsidy_id | Yes | Subsidy ID | |
| category | Yes | Attachment category | |
| index | Yes | Attachment index (starts from 0) |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return format ('Returns the file data in base64 encoding along with metadata'), which is useful. However, it lacks details on error handling, rate limits, authentication needs, or file size constraints, leaving gaps for a download operation.
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 appropriately sized and front-loaded, starting with the core purpose. The second sentence adds necessary context about the return format, and the third provides crucial usage guidance. While efficient, it could be slightly more concise by integrating the return format into the first sentence without losing clarity.
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?
Given the tool's complexity (download operation with three parameters) and no output schema, the description is mostly complete: it explains the purpose, return format, and usage workflow. However, it lacks details on error cases or behavioral traits like rate limits, which would enhance completeness for a tool with no annotations.
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 the schema already documents all three parameters (subsidy_id, category, index) with descriptions and constraints. The description adds minimal value beyond the schema by mentioning the index comes from 'attachments[n].index' and the categories, but it doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.
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 specific action ('Download a subsidy's attachment document') and resource ('subsidy's attachment'), distinguishing it from siblings like get_subsidy_detail (which retrieves subsidy details) and list_subsidies (which lists subsidies). It explicitly mentions the verb 'download' and the target resource, avoiding tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'First call get_subsidy_detail to see the attachments array for each category... then use the 'index' from attachments[n].index to download the specific file.' It names the alternative tool (get_subsidy_detail) and specifies the prerequisite step, clearly outlining the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subsidy_detailB
Get detailed information about a specific subsidy. Use the subsidy ID, not the title.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| subsidy_id | Yes | Subsidy ID |
TDQS
B3.3/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 states the tool 'Get[s] detailed information,' which implies a read-only operation, but does not specify permissions, rate limits, error handling, or what 'detailed information' entails. This leaves significant gaps for a tool with no annotation coverage.
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 concise and well-structured with two sentences: the first states the purpose, and the second provides usage guidance. Every sentence adds value without redundancy, making it efficient and front-loaded.
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 the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and parameter usage, but lacks details on behavioral aspects like permissions or output format, which are needed for full contextual understanding in the absence of annotations.
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 schema description coverage is 100%, with the parameter 'subsidy_id' documented as 'Subsidy ID.' The description adds minimal value beyond the schema by emphasizing 'Use the subsidy ID, not the title,' which clarifies the parameter's purpose but does not provide additional syntax or format details. This meets the baseline for high schema coverage.
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 states the tool's purpose: 'Get detailed information about a specific subsidy.' It uses a specific verb ('Get') and resource ('subsidy'), but does not explicitly differentiate from sibling tools like 'list_subsidies' beyond the 'specific' qualifier, which is implied but not directly contrasted.
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 provides some usage guidance: 'Use the subsidy ID, not the title.' This implies when to use this tool (for a specific subsidy by ID) versus alternatives, but does not explicitly mention sibling tools or broader contexts. It offers basic direction without clear exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_subsidiesB
Search for subsidies currently accepting applications using the specified keyword. Default is '補助金' (subsidy).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Search keyword | 補助金 |
TDQS
B3.2/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 mentions the search functionality and default keyword, but doesn't describe key behaviors such as whether this is a read-only operation, how results are returned (e.g., pagination, format), error handling, or any rate limits. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the core purpose ('Search for subsidies currently accepting applications') and includes essential details (keyword usage and default). There is no wasted text, making it appropriately sized and well-structured for quick comprehension.
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 tool's complexity (a search function with no output schema and no annotations), the description is incomplete. It lacks information on return values (e.g., what data is included in search results), behavioral traits like pagination or sorting, and how it differs from sibling tools. Without annotations or output schema, the description should provide more context to be fully helpful.
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 has 100% description coverage, with the parameter 'keyword' documented as 'Search keyword' and a default value. The description adds minimal value beyond the schema by restating the default keyword ('補助金') and implying it's used for searching subsidies. Since schema coverage is high, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
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 states the tool's purpose: 'Search for subsidies currently accepting applications using the specified keyword.' It specifies the verb ('search'), resource ('subsidies'), and scope ('currently accepting applications'), though it doesn't explicitly differentiate from sibling tools like 'get_subsidy_detail' beyond the search vs. detail distinction. This makes it clear but not fully sibling-differentiated.
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 context by specifying 'currently accepting applications' and the default keyword, suggesting it's for finding active subsidies. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_subsidy_detail' (e.g., for detailed info vs. broad search) or provide exclusions. The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A3.5/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: list_subsidies searches for subsidies, get_subsidy_detail retrieves detailed information about a specific subsidy, and download_attachment handles file downloads. There is no overlap in functionality, and the descriptions clearly differentiate their roles.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (list_subsidies, get_subsidy_detail, download_attachment) using snake_case. The verbs (list, get, download) are appropriate and predictable, making the set easy to understand and use.
Tool Count3/5
With only 3 tools, the set feels thin for a subsidy management domain, as it lacks operations like creating, updating, or deleting subsidies. However, the tools cover core search and retrieval functions, so it's borderline but not severely mismatched.
Completeness2/5
The tool set has significant gaps for a subsidy management server. It provides search and detail retrieval but lacks essential CRUD operations (e.g., create_subsidy, update_subsidy, delete_subsidy) and other lifecycle actions like applying for subsidies or managing applications, which could cause agent failures in broader workflows.
Maintenance
ActivityInactive
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for Pinchwork - an agent-to-agent task marketplace with credits-based economy
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
Official remote MCP server for SUZURI.
Related MCP Servers
- AlicenseBqualityDmaintenanceMCP server for the Japan National Tax Agency Corporate Number API, enabling corporate number lookup and search via local AI clients.31MIT
- AlicenseAqualityDmaintenanceAn MCP server that provides AI assistants with access to over 40 Bank of Japan statistical databases (interest rates, money supply, exchange rates, tankan, etc.) via the BOJ time-series data search API.423MIT
- AlicenseAqualityDmaintenanceAn MCP server that provides access to Japan's central and municipal subsidies, covering over 20,000 municipal grants not exposed by official APIs, with tools for search, comparison, citation verification, and practitioner referrals.1350MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tachibanayu24/jgrants-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server