A
license-
qualityA
maintenanceRead-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.
90
Apache 2.0
HORIZON SHIELD YAKUMO (verified contractor directory)
Ownership verified
Server Details
Neutral, verification-gated MCP directory of Japan construction contractors (KIRA-audited).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ogasurfproject-jpg/horizon-shield
- GitHub Stars
- 1
- Server Listing
- HORIZON SHIELD KIRA
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.4/5.0
Tool DescriptionsA
Average 4.4/5 across 5 of 5 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a distinct purpose: searching contractors, getting a specific profile, explaining verification, listing filtered stores, and providing an overview. No overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case: find_contractor, get_contractor_profile, how_verification_works, list_verified_stores, mall_overview.
Tool Count5/5
Five tools is appropriate for a contractor directory, covering search, detail, explanation, listing, and overview without unnecessary extras.
Completeness4/5
The surface covers core functionality: search, details, listing, verification explanation, and overview. Minor gaps like booking or reviews exist but are out of scope for a verified directory.
Available Tools
5 toolsfind_contractor検証済みの職人を探す(司令塔)ARead-onlyIdempotentInspect
施主の相談文(自由記述)から Yakumo の検証済み加盟店を探す司令塔。need(例:『愛知県で外壁塗装できる信頼できる業者』)を渡すと地域と工種を推定し、検証を通過した店を返す。該当が無ければ相場(souba)や無料の第三者チェック(EHN)への導線を返す。金額は返さない(スコア・ティアのみ)。紹介料なし・verified-first・Japan only。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | 探している内容(日本語自由記述)。例: 神奈川で屋根の雨漏り修理、長久手で内装リフォーム |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and no destructiveness. The description adds that the tool does not return amounts (only scores/tiers), is introduction fee-free, and Japan-only. This provides useful behavioral context beyond annotations.
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 concise (two sentences) and front-loaded with the core purpose. It includes essential details without unnecessary verbosity, though it could be slightly more structured.
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 has only one parameter, comprehensive annotations, and an output schema, the description covers the purpose, input/output behavior, fallback, and constraints. It is complete for an agent to use effectively.
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?
Parameter schema coverage is 100% with a clear description of 'need'. The description reinforces this with an example ('例: 神奈川で屋根の雨漏り修理'), which adds practical guidance beyond the schema's description.
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 is a 'command tower' to find verified contractors from free-text consultation. It specifies input ('need') and output (verified stores or alternative routes like souba/EHN). It distinguishes from siblings by emphasizing 'verified-first' and 'Japan only'.
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 explains to pass a 'need' and what to expect, including fallback options. However, it does not explicitly differentiate when to use this tool versus siblings like 'list_verified_stores' or 'get_contractor_profile', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contractor_profile加盟店プロフィール取得ARead-onlyIdempotentInspect
Yakumo の加盟店1件の検証済みプロフィールを返す。member_no(例 No.001)で指定。会社名・地域・対応工種・適正度スコア・誠実度ティア・検証状態・プロフィールURLを返す。金額は含まない。検証が済んでいない店は verification:'pending' を返す(スコアは出さない=fail-closed)。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| member_no | Yes | 加盟店番号(例: No.001) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds valuable behavioral detail: what fields are returned, that amounts are excluded, and critically that unverified stores return verification:'pending' (fail-closed) with no score. No contradiction with annotations.
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 concise (three sentences in Japanese), front-loads purpose, then adds details. No unnecessary words. Slight improvement possible with bullet points, but highly efficient.
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 (one parameter, output schema present, annotations present), the description covers all necessary aspects: purpose, input, output fields, edge case (pending), and what is not included. No missing critical information for agent decision-making.
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?
Input schema has 100% coverage with a description for the single parameter member_no. The description reinforces this with an example ('No.001'), adding practical guidance beyond the schema. No parameters are left ambiguous.
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 returns the verified profile of one Yakumo member store, specifies the input parameter member_no (with example), and lists the returned fields. It distinguishes itself from sibling tools like list_verified_stores (multiple stores) and find_contractor (search) by focusing on a single profile.
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?
Usage is implied: use when you have a specific member_no and need the full verified profile. However, no explicit comparison to siblings (e.g., when to use find_contractor or list_verified_stores instead). The edge case for unverified stores is clarified but not as a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
how_verification_works検証の仕組みARead-onlyIdempotentInspect
Yakumo の掲載審査(KIRA適正診断)がどう機能するかを返す。適正価格の検証・過剰請求の赤旗検出・適正度スコアと誠実度ティア・再計算できる署名レシート(SHA-256)・掲載後の継続監視・fail-closed(通らない店は施主向けに一切出さない)・中立(紹介料なし)。施主が『検証済み』の意味を理解するための説明。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details: fail-closed behavior (non-passing stores are hidden), neutrality (no referral fees), and post-listing continuous monitoring. No contradictions with annotations.
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 paragraph with a clear front-loaded purpose. It lists multiple aspects without redundancy, though it could be slightly more structured (e.g., bullet points) for readability. Each sentence contributes to understanding.
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 complexity of explaining verification and the presence of an output schema and annotations, the description covers all key aspects: components of verification, fail-closed, neutrality, and audience (property owners). It is complete for understanding the tool's purpose and behavior.
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 tool has zero parameters, and schema coverage is 100%. The description adds context about what the tool returns, which is sufficient. Baseline for zero parameters is 4, and the description meets that.
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 returns how the verification mechanism works, listing specific components like fair price verification, red flag detection, and integrity tiers. It distinguishes itself from sibling tools (find_contractor, list_verified_stores) by focusing on explaining the verification process rather than providing data.
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 the tool is for understanding verification, but it does not explicitly state when to use it versus alternatives or when not to use it. No exclusions or comparisons to sibling tools are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_verified_stores検証済み加盟店の一覧ARead-onlyIdempotentInspect
Yakumo モールで検証を通過した加盟店(工務店・リフォーム店)を一覧する。適正価格の検証と過剰請求チェック(KIRA)を通過した店だけが返る。area(地名)や work(工種)で絞り込める。返り値は member_no / 会社名 / 地域 / 対応工種 / 適正度スコア / 誠実度ティア / プロフィールURL。金額は含まない(スコアとティアのみ)。検証手続き中の店は verification:'pending' として区別される。Japan only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | 地名で絞り込み(例: 愛知県, 長久手市)。省略で全件。 | |
| work | No | 工種で絞り込み(例: 外壁塗装, 屋根, 内装)。省略で全件。 |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds valuable context: it only returns verified stores, excludes monetary amounts, and distinguishes pending verification status. No contradictions.
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, front-loaded with purpose, and efficiently covers filtering, return fields, and verification status without redundancy.
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 low complexity (2 optional params) and the presence of an output schema, the description provides sufficient context: filters, return fields, verification handling, and geographic scope (Japan only).
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?
Schema covers both parameters with descriptions (100% coverage). The description reinforces their purpose with examples and clarifies that omitting both returns all items, adding slight value beyond 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 lists verified stores that passed verification and KIRA check, with specific return fields. It distinguishes from sibling tools like find_contractor and get_contractor_profile by focusing on verified stores only.
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 explains when to use (listing verified stores filtered by area/work), and implies not to use for unverified stores by mentioning pending status. However, it lacks explicit alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mall_overviewモール概要ARead-onlyIdempotentInspect
Yakumo モール全体の要約を返す。検証済み加盟店の数・対応工種カテゴリ・地域・検証の仕組みの要点・主要リンク(モール/加盟/相場/実例ボード)。AIが Yakumo というモール/MCP を一言で説明するための入口。金額は含まない。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds value by noting the summary excludes amounts (金額は含まない), a behavioral constraint not in annotations.
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 three sentences, front-loaded with the main purpose, and every sentence adds meaningful information. No wasted words.
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 absence of parameters, presence of output schema, and low complexity, the description completely covers the tool's purpose and content. It lists all key elements included in the summary.
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?
There are no parameters (schema coverage 100%). The description adds no parameter info, which is appropriate. With zero parameters, a baseline of 4 is applied.
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 returns an overall summary of the Yakumo mall, enumerating specific content (stores, categories, regions, verification, links). It distinguishes itself from siblings (find_contractor, list_verified_stores, etc.) by being the high-level entry point.
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 this is the entry point for explaining the mall in one sentence, implying when to use. It does not explicitly mention when not to use or alternatives, but the sibling tools provide clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityBmaintenanceAn MCP server that validates Japanese corporate numbers and invoice registration numbers, and normalizes/matches company names across notation variants.7153MIT
- Alicense-qualityBmaintenanceMCP server providing raw Japanese regulatory corporate data, including pension headcount logs, statutory financial disclosures, and government procurement records, metered via x402 micro-payments.MIT
- Alicense-qualityCmaintenanceMCP server for the Kaisha API, providing official Japanese company-registry data including corporate numbers and qualified invoice registrations, with pay-per-call via USDC micropayments.26MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.