Neutral, verification-gated MCP directory of Japan construction contractors (KIRA-audited).
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Average 4.5/5 across 6 of 6 tools scored.
The tools are mostly distinct: check_named_contractor handles specific named contractors, find_contractor handles free-text searches, get_contractor_profile retrieves a single profile, list_verified_stores lists stores, mall_overview gives an overview, and how_verification_works explains the process. There is slight overlap between find_contractor and list_verified_stores (both return verified stores), but the former is a natural-language command tower while the latter is a direct filterable list, so the boundary is clear enough.
Most tools follow a verb_noun pattern: check_named_contractor, find_contractor, get_contractor_profile, list_verified_stores, mall_overview. The exception is how_verification_works, which uses a question-like phrase rather than a verb_noun structure, but it is still readable and consistent in style. Overall, the naming is predictable and clear.
With 6 tools, the server is well-scoped for its purpose: a verified contractor directory. Each tool serves a distinct function: checking a named contractor, finding contractors, viewing profiles, listing stores, explaining verification, and providing an overview. No tool feels redundant or missing; the count is appropriate for the domain.
The tool surface covers the core workflows: searching, listing, profiling, and explaining the verification process. However, there is no tool for submitting a contractor for verification or for updating store information, which might be expected in a directory that manages verified stores. That said, the server appears to be consumer-facing (for homeowners), so those gaps are acceptable and agents can work around them by directing users to the mall links.
check_named_contractor名指しの業者を照会A施主が名前を挙げた業者について答える。Yakumoの加盟店ならその測定結果を返す。加盟していない場合、その会社の良し悪しは一切判定せず、『Yakumoは測っていない』という事実だけを返し、施主が自分で確かめられる公的な照会先(国土交通省の建設業者検索・国民生活センター・住まいるダイヤル)と、同条件の検証済み加盟店を返す。掲載が無いことはその会社への評価ではない。金額は返さない。紹介料なし。Japan only。
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | (任意)地域。代わりの検証済み店を探すのに使う | |
| work | No | (任意)工種。代わりの検証済み店を探すのに使う | |
| company | Yes | 施主が名前を挙げた業者名(日本語) |
| Name | Required | Description |
|---|---|---|
| roster_read | No | true = the contractor roster was read successfully; any counts below are real facts about the roster. false = the roster could NOT be read, and this response makes no claim about how many contractors exist. A count of 0 with roster_read true means nobody matched. There is no case where a failed read reports a count. |
| pending_count | No | |
| roster_source | No | |
| verified_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds substantial behavioral context beyond those hints: it states that no judgment is made about non-member companies, only returns the fact that 'Yakumo hasn't measured,' provides public inquiry contacts, does not return monetary amounts, and charges no referral fee. This significantly clarifies the tool's behavior and boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused paragraph that front-loads the main purpose ('施主が名前を挙げた業者について答える') then efficiently lists key behaviors and exclusions. Every sentence contributes critical information, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with a detailed output schema. The description covers the core decision logic (member vs non-member), return content, explicit non-actions (no judgment, no amounts, no referral fee), geographic scope, and fallback sources. Given the output schema exists, return value details are not needed. This description is thorough and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description mentions that 'area' and 'work' are used to find alternative verified stores, which aligns with their schema descriptions but adds no new meaning. Thus the description provides no extra value beyond the schema for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb '答える' (answer) and resource '施主が名前を挙げた業者' (contractor named by the owner), distinguishing it from siblings like find_contractor and list_verified_stores. It further clarifies scope by outlining behavior for both member and non-member cases, making the tool's unique role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context: it is used when an owner has named a specific contractor. It implies the tool is not for general searches (there are siblings for that) and states 'Japan only' as a constraint. However, it does not explicitly name alternative tools for different scenarios, so it lacks explicit exclusions 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.
find_contractor検証済みの職人を探す(司令塔)A施主の相談文(自由記述)から Yakumo の検証済み加盟店を探す司令塔。need(例:『愛知県で外壁塗装できる信頼できる業者』)を渡すと地域と工種を推定し、検証を通過した店を返す。該当が無ければ相場(souba)や無料の第三者チェック(EHN)への導線を返す。金額は返さない(スコア・ティアのみ)。紹介料なし・verified-first・Japan only。
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | 探している内容(日本語自由記述)。例: 神奈川で屋根の雨漏り修理、長久手で内装リフォーム |
| Name | Required | Description |
|---|---|---|
| roster_read | No | true = the contractor roster was read successfully; any counts below are real facts about the roster. false = the roster could NOT be read, and this response makes no claim about how many contractors exist. A count of 0 with roster_read true means nobody matched. There is no case where a failed read reports a count. |
| pending_count | No | |
| roster_source | No | |
| verified_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses key behaviors: it estimates region and trade, returns only verified stores, does not return prices (only score/tier), and provides fallback guidance. It also states business constraints (no referral fee, verified-first, Japan only), giving agents a rich picture of what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, starting with the purpose and then adding behavioral details and constraints. Every sentence contributes useful information without redundancy or unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, a rich output schema, and strong annotations, the description covers the essential operational aspects: input format, matching behavior, fallback paths, and output limitations. It is complete for an AI agent to select and invoke the tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single 'need' parameter with examples, so the baseline is 3. The description adds semantic value by explaining that 'need' should contain a free-form Japanese request and that the tool will infer region and trade from it, which helps the agent formulate the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a '司令塔' (command center) that searches Yakumo verified contractors from free-form client requests, which is a specific verb+resource pairing. It also distinguishes itself from siblings like check_named_contractor and list_verified_stores by emphasizing free-form consultation text and verification-first matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: pass a free-form 'need' and the tool infers region and trade. It mentions fallback paths (souba and EHN) when no match exists, but it does not explicitly list exclusions or name sibling alternatives for when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contractor_profile加盟店プロフィール取得AYakumo の加盟店1件の検証済みプロフィールを返す。member_no(例 No.001)で指定。会社名・地域・対応工種・適正度スコア・誠実度ティア・検証状態・プロフィールURLを返す。金額は含まない。検証が済んでいない店は verification:'pending' を返す(スコアは出さない=fail-closed)。
| Name | Required | Description | Default |
|---|---|---|---|
| member_no | Yes | 加盟店番号(例: No.001) |
| Name | Required | Description |
|---|---|---|
| roster_read | No | true = the contractor roster was read successfully; any counts below are real facts about the roster. false = the roster could NOT be read, and this response makes no claim about how many contractors exist. A count of 0 with roster_read true means nobody matched. There is no case where a failed read reports a count. |
| pending_count | No | |
| roster_source | No | |
| verified_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond the annotations: it specifies that unverified stores return verification:'pending' with no score (fail-closed), and explicitly states pricing is not included. This is exactly the kind of edge-case behavior an agent needs to know. The annotations (readOnlyHint, idempotentHint, destructiveHint:false) are consistent with the description, and the description enriches the agent's understanding of the tool's side effects and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first states the core purpose, the second lists return fields and exclusions, and the third explains the pending behavior. Every sentence earns its place, and the most important information is front-loaded. It is appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (one parameter, no nested objects, output schema exists). The description covers the input format, return fields, an explicit exclusion (pricing), and the fail-closed behavior for unverified stores. Given the output schema is present and the tool is simple, this is a complete description that leaves no meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single parameter member_no with an example ('例: No.001'). The description repeats this example and adds no additional meaning beyond what the schema provides. With 100% schema description coverage, the baseline of 3 applies. The description correctly aligns with the schema but does not introduce new semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a verified profile for a single contractor specified by member_no. It lists the exact fields returned (company name, region, work types, scores, verification status, URL) and distinguishes itself from siblings by explicitly noting it returns one contractor's profile and excludes pricing. This is a specific verb+resource+scope formulation that differentiates it from the sibling tools like list_verified_stores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need a single contractor's verified profile by member_no. It also provides useful exclusions ('does not include pricing') and behavior for unverified stores. However, it does not explicitly name alternative tools or provide when-not-to-use instructions. Clear context is present, but explicit exclusionary guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
how_verification_works検証の仕組みAYakumo の掲載審査(KIRA適正診断)がどう機能するかを返す。適正価格の検証・過剰請求の赤旗検出・適正度スコアと誠実度ティア・再計算できる署名レシート(SHA-256)・掲載後の継続監視・fail-closed(通らない店は施主向けに一切出さない)・中立(紹介料なし)。施主が『検証済み』の意味を理解するための説明。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| roster_read | No | true = the contractor roster was read successfully; any counts below are real facts about the roster. false = the roster could NOT be read, and this response makes no claim about how many contractors exist. A count of 0 with roster_read true means nobody matched. There is no case where a failed read reports a count. |
| pending_count | No | |
| roster_source | No | |
| verified_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description goes beyond by detailing the content of the explanation (red flags, score tiers, SHA-256 receipt, continuous monitoring, fail-closed behavior, neutrality), which is valuable behavioral context. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that lists all key aspects of the verification mechanism without extraneous words. It is front-loaded with the primary purpose ('掲載審査がどう機能するかを返す') and efficiently enumerates the features. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is an output schema (though not shown, it exists), and this tool has no parameters amplifying complexity, the description fully captures the tool's role: explaining verification mechanics to homeowners. It covers the key features, making it complete for both selection and invocation. The output schema presumably provides return structure, so the description need not reiterate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so description doesn't need to document them. The schema coverage is 100% (vacuously). The description provides meaning about what the tool returns, which is the core semantic information for a parameterless info tool. Baseline 4 for 0 params is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns an explanation of how Yakumo's listing review (KIRA appropriateness diagnosis) functions, listing specific features like price verification, red-flag detection, scoring tiers, receipts, monitoring, fail-closed behavior, and neutrality. This distinguishes it from sibling tools that list or profile stores, as it is about the verification mechanism itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for helping homeowners understand what 'verified' means, but it does not explicitly state when to use this tool versus sibling tools or what prerequisites exist. There is no explicit when-not-to-use guidance, though the informational nature is clear. It provides some context but lacks explicit alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_verified_stores検証済み加盟店の一覧AYakumo モールで検証を通過した加盟店(工務店・リフォーム店)を一覧する。適正価格の検証と過剰請求チェック(KIRA)を通過した店だけが返る。area(地名)や work(工種)で絞り込める。返り値は member_no / 会社名 / 地域 / 対応工種 / 適正度スコア / 誠実度ティア / プロフィールURL。金額は含まない(スコアとティアのみ)。検証手続き中の店は verification:'pending' として区別される。Japan only.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | 地名で絞り込み(例: 愛知県, 長久手市)。省略で全件。 | |
| work | No | 工種で絞り込み(例: 外壁塗装, 屋根, 内装)。省略で全件。 |
| Name | Required | Description |
|---|---|---|
| roster_read | No | true = the contractor roster was read successfully; any counts below are real facts about the roster. false = the roster could NOT be read, and this response makes no claim about how many contractors exist. A count of 0 with roster_read true means nobody matched. There is no case where a failed read reports a count. |
| pending_count | No | |
| roster_source | No | |
| verified_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior; the description adds useful details such as pending verification status ('verification:'pending'') and that pricing amounts are excluded, which goes beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative with multiple sentences but remains focused, covering the main behavior, filters, return fields, and a special status. It is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description compensates by listing the return fields (member_no, company name, region, etc.) and clarifying that pricing is not included. It also mentions the pending verification subcase, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for area and work. The description reinforces that these parameters are for filtering and gives examples in the schema, adding practical meaning beyond the basic type and optionality info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 (加盟店) in Yakumo Mall, and distinguishes it from siblings like find_contractor or check_named_contractor by focusing on listing all verified entries with optional filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that the tool lists verified stores and can be filtered by area (地名) and work type (工種), giving clear context. However, it does not explicitly mention when to use this over alternatives such as find_contractor or check_named_contractor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mall_overviewモール概要AYakumo モール全体の要約を返す。検証済み加盟店の数・対応工種カテゴリ・地域・検証の仕組みの要点・主要リンク(モール/加盟/相場/実例ボード)。AIが Yakumo というモール/MCP を一言で説明するための入口。金額は含まない。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| roster_read | No | true = the contractor roster was read successfully; any counts below are real facts about the roster. false = the roster could NOT be read, and this response makes no claim about how many contractors exist. A count of 0 with roster_read true means nobody matched. There is no case where a failed read reports a count. |
| pending_count | No | |
| roster_source | No | |
| verified_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond this: it returns a summary, includes specific sections, and explicitly excludes monetary amounts. There is no contradiction between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and dense, with the primary action and object stated immediately, followed by a list of concrete contents, a usage hint, and an important exclusion. Every phrase earns its place; there is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter overview tool with an output schema and strong annotations, the description is complete: it states what the tool returns, what content areas are included, what it is for, and what it does not include. Additional detail about exact return formatting is unnecessary given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to document; the schema is an empty object and the description correctly adds no parameter details. With no parameters, ambiguity is eliminated by construction, so the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a summary of the entire Yakumo mall and enumerates the exact content areas (verified store counts, work categories, regions, verification process, key links). This distinguishes it from sibling tools like find_contractor or get_contractor_profile, which target specific contractors or verification details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as the entry point for AI to explain Yakumo the mall/MCP in a nutshell, giving clear usage context. It does not explicitly state when not to use it, but the nature of the overview plus sibling tools implies that detailed contractor-specific lookups should go elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.