mcp-server
Server Details
Japan central + municipal subsidies (20,810 grants, 1,627 munis). 8 tools beyond Jグランツ MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- localgov-jp/localgov-mcp-server
- GitHub Stars
- 0
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.
Tool Definition Quality
Average 4.2/5 across 8 of 8 tools scored.
Each tool has a clearly distinct purpose: comparing subsidies, finding practitioner types, supplementary grants, municipality grants, subsidy details, searching, subscribing to changes, and verifying receipts. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., compare_municipal_subsidies, get_subsidy_detail). No deviations or mixed conventions.
With 8 tools, the count is well within the ideal 3-15 range. Each tool serves a necessary function for the domain of Japanese municipal grants, covering core queries and advanced features like subscriptions.
The tool set covers essential operations: search, detail, comparison, supplementary grants, and municipality listing. Minor gaps exist, such as no tool for listing all prefectures or categories independently, but the core informational purpose is well-served.
Available Tools
8 toolscompare_municipal_subsidiesARead-onlyIdempotentInspect
Compare same-category subsidies across nearby municipalities (same prefecture by default). Useful for relocation / siting decisions. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category to compare; if omitted, the most-frequent category at the anchor is auto-picked | |
| max_municipalities | No | Max number of municipalities in the comparison (2-20, default 10) | |
| anchor_municipality_code | Yes | JIS code of the anchor municipality to compare around |
Output Schema
| Name | Required | Description |
|---|---|---|
| category | Yes | |
| prefecture | Yes | |
| per_municipality | Yes | |
| municipalities_compared | Yes | |
| anchor_municipality_code | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. Description adds 'Free' but no additional behavioral context beyond what annotations provide. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering purpose and cost. Could be slightly more structured but remains informative without unnecessary verbosity.
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 output schema exists and annotations are rich, the description is adequate for a read-only comparison tool. Lacks detail on comparison output format but sufficient for typical use.
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 coverage is 100% with descriptions for all three parameters. The description does not add any further meaning beyond what the schema already provides.
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?
Clearly states it compares same-category subsidies across nearby municipalities, defaulting to same prefecture. Distinguishes from siblings like get_municipality_grants (single municipality) and search_subsidies (broader search).
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?
Implies usage for relocation/siting decisions but does not explicitly state when to use versus alternatives or provide exclusions. No mention of when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_practitionerARead-onlyIdempotentInspect
Recommend 3 Japanese licensed practitioner types (行政書士 / 税理士 / 中小企業診断士 / 社労士) for the grant's category. Returns role explanations and official-association registry links. Informational only — LocalGov.jp does NOT broker, refer, or accept commission for these recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| grant_id | Yes | Subsidy id (the recommendation is shaped by the grant's category and amount tier) | |
| industry_hint | No | Free-text industry context, e.g. "飲食業", "製造業" |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | Yes | |
| grant_id | Yes | |
| practitioners | Yes | |
| legal_disclaimer | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, etc.), the description adds critical behavioral context: it is 'Informational only' and does not broker, refer, or accept commission. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states the core action, second lists outputs, third provides a crucial caveat. No wasted words, information front-loaded.
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 description covers purpose, inputs, outputs (role explanations and links), and limitations. Given the presence of an output schema, the return values are further documented. The description is complete for this tool’s complexity.
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 coverage is 100%, so the baseline is 3. The description adds that the recommendation is shaped by the grant's category and amount tier, which provides some extra meaning beyond the schema's property descriptions.
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 specifies the verb 'Recommend', the resource 'Japanese licensed practitioner types', and lists specific types and outputs. It clearly distinguishes itself from sibling tools which handle subsidies or receipts.
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 states that the tool is for recommendations and that it does not broker or accept commission. However, it does not mention when not to use it or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_supplementary_grantsARead-onlyIdempotentInspect
Given a central J-Grants subsidy id, search for municipal grants that supplement it (e.g. national "事業再構築" + city-level "事業再構築追加上乗せ"). Heuristic title-token match. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records (1-50, default 30) | |
| prefecture | No | Restrict supplementaries to municipalities of a single prefecture | |
| central_grant_id | Yes | Central J-Grants id, e.g. "jg_a0W..." |
Output Schema
| Name | Required | Description |
|---|---|---|
| central | Yes | Echo of the seed central grant |
| base_token | Yes | Heuristic base token used for matching |
| supplementary | Yes | |
| supplementary_count | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds that it is a 'heuristic title-token match' and 'Free', which gives context beyond annotations. No 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?
Two sentences, front-loaded with key information, no unnecessary words. Excellent conciseness.
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 3 fully documented parameters, no nested objects, and an output schema available, this description is sufficiently complete. It explains the tool's purpose and heuristic nature.
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 coverage is 100%, so parameters are fully documented in the schema. Description restates the key param (central_grant_id) with an example but adds no new semantics beyond the schema.
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?
Description clearly states the tool does a specific search for supplementary municipal grants given a central J-Grants id, with an example. Distinguishes from sibling tools like search_subsidies.
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?
Indicates when to use: given a central J-Grants subsidy id. Implicitly differentiates from siblings by specializing in supplementary grants, but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_municipality_grantsARead-onlyIdempotentInspect
List all subsidies for a single municipality by JIS X 0402 6-digit code. Differentiator: J-Grants public API has zero municipal-level entries; LocalGov.jp covers 1,627 municipalities (target 1,718). Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records (1-200, default 50) | |
| municipality_code | Yes | JIS X 0402 6-digit municipality code |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| total | Yes | Total grants for the municipality |
| municipality_code | Yes | Echo of the requested code |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the cost trait 'Free' and confirms it's a listing operation. However, it does not address pagination or the limit parameter's effect on 'all' subsidies, which is a minor gap. Overall, it adds value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise, and front-loaded with the core action. The bolded differentiator adds value without extra words. Every part is necessary and information-dense.
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 presence of an output schema (not shown), the description need not cover return values. It provides key context: coverage scope and cost. However, the term 'all subsidies' may mislead given the limit parameter. Minor gap, but otherwise complete for a read tool with good annotations.
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 coverage is 100%, with both parameters having descriptions. The description does not add significant parameter-specific information beyond the schema, such as explaining the format of the code or the limit's role in pagination. It meets the baseline but does not excel.
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 subsidies for a single municipality using a specific code. The verb 'list' and resource 'subsidies' are precise, and the scope ('single municipality') is well-defined. The differentiator distinguishes it from other APIs but not explicitly from sibling tools, but the purpose itself is 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 differentiator provides context about data coverage and cost ('Free'), but it does not explicitly compare to sibling tools on this server. Usage guidance is implied (use for municipal-level grants) but lacks direct 'when-to-use' or 'when-not-to-use' statements. No alternatives among siblings are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subsidy_detailARead-onlyIdempotentInspect
Fetch the full record for a single subsidy by id. Returns _source (LocalGov.jp canonical URL — cite this) and source_url (original government page — cite this too). Free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Subsidy id, e.g. "jg_a0W2x000003QX8oEAG" (J-Grants central) or "131105_<slug>" (municipal) |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Stable grant id |
| title | Yes | Official subsidy/grant title (Japanese) |
| issuer | Yes | Issuing authority (ministry, prefecture, or municipality) |
| _source | Yes | Canonical LocalGov.jp URL — cite this as "via LocalGov.jp" |
| summary | Yes | Short Japanese summary |
| _license | Yes | License hint |
| category | Yes | Category label |
| deadline | Yes | Application deadline (ISO date) |
| prefecture | Yes | Prefecture name in kanji |
| source_url | Yes | Original government page (cite this in addition to _source) |
| eligibility | Yes | Eligibility criteria, free-form |
| _attribution | Yes | Attribution string for CC BY 4.0 |
| amount_max_jpy | Yes | Maximum subsidy amount in JPY |
| municipality_code | Yes | JIS X 0402 6-digit code, null for central government grants |
| source_url_shared | Yes | True when source_url is a category/index page shared by other grants. When true, cite as "LocalGov.jp listing" or pair with the LocalGov.jp _source for per-grant precision. |
| source_url_sibling_count | Yes | Number of other grants pointing at the same source_url (0 means dedicated per-grant page). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate `readOnlyHint`, `destructiveHint`, and `idempotentHint`. The description adds that it returns `_source` and `source_url` and notes 'Free.' (likely meaning no cost), providing additional behavioral context beyond the 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?
Two sentences, clearly structured. The 'Free.' statement is slightly tangential but not harmful. Could be more concise by removing 'Free.' or integrating it better, but overall efficient.
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 tool's simplicity (one required param, clear return fields described), the description is complete. It covers what the tool does, what it returns, and how to use it. No 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 describes the `id` parameter with examples (100% coverage). The description does not add parameter-specific meaning beyond 'by id.' Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Fetch the full record') and the resource ('single subsidy by id'). It specifies returned fields (`_source` and `source_url`) and distinguishes from siblings by emphasizing fetching by ID instead of searching.
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 phrase 'by id' indicates when to use (when you have a specific ID). Siblings like `search_subsidies` imply alternatives, but no explicit exclusions or when-not-use are provided. Still, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_subsidiesARead-onlyIdempotentInspect
Search Japanese central + municipal subsidies. Combine keyword (Japanese), prefecture, municipality_code, category, or minimum amount. Returns up to limit records. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order; default "relevance" when keyword set, otherwise "newest" | |
| limit | No | Max records to return (1-100, default 20) | |
| offset | No | Pagination offset (default 0) | |
| keyword | No | Free-text Japanese keyword (FTS), e.g. "IT導入", "創業", "省エネ" | |
| category | No | Category label (e.g. "子育て", "住宅", "事業者支援") — usually omit and rely on keyword | |
| open_only | No | When true, exclude records whose deadline has passed (default: false = include all) | |
| prefecture | No | Prefecture name in kanji, e.g. "東京都", "北海道" | |
| min_amount_jpy | No | Minimum subsidy amount in JPY; only records with amount_max_jpy >= this | |
| municipality_code | No | JIS X 0402 6-digit municipality code (e.g. 131105 = 杉並区) |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Records on this page |
| total | Yes | Total matching records (independent of limit/offset) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds that results are capped at `limit` records and that the service is free, but does not disclose pagination behavior or full-text search details beyond what the schema provides.
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?
Three sentences efficiently convey the tool's purpose, usage pattern, and a key behavioral trait (limit and free). No extraneous text.
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 description covers the essential filtering capability and result cap. With output schema available and detailed parameter documentation in the schema, the description is sufficient for an agent to understand the tool's function, though it omits explicit mention of sorting and pagination.
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?
All parameters are well-described in the schema (100% coverage). The description reiterates a subset of parameters (keyword, prefecture, municipality_code, category, min_amount_jpy) but does not add new meaning beyond the schema.
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?
Description clearly identifies the tool as a search for Japanese central and municipal subsidies, explicitly naming filters. It is distinct from sibling tools like get_subsidy_detail or compare_municipal_subsidies.
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 advises combining specific parameters (keyword, prefecture, etc.) to perform searches, implying this is the general search tool. However, it does not explicitly contrast with sibling tools or state when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
subscribe_changesAInspect
Create a webhook subscription that pushes grant-change events matching a filter. Cost: $0.20 USDC via x402 (paid by the agent runtime). On 402 response, agent must satisfy payment and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | Yes | At least one filter dimension required | |
| ttl_days | No | Subscription lifetime in days (1-90, default 30) | |
| hmac_secret | Yes | Shared secret used to HMAC-SHA256 sign delivery payloads (16-256 chars) | |
| callback_url | Yes | HTTPS URL that will receive POSTed event payloads |
Output Schema
| Name | Required | Description |
|---|---|---|
| details | No | |
| expires_at | No | |
| callback_url | No | |
| subscription_id | No | |
| payment_required | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses required payment and retry logic beyond annotations. Annotations (readOnlyHint=false) align with 'Create' action. No 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?
Two sentences, front-loaded with core purpose, then essential cost and retry info. No 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?
Given parameters, output schema existence, and clear context (4 params, 3 required, nested filter), description covers key behavioral aspects (cost, retry) comprehensively.
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 has 100% parameter description coverage, so description adds minimal extra param meaning. Baseline 3 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?
Description clearly states verb 'Create a webhook subscription' and resource 'grant-change events matching a filter.' Title 'Subscribe to Grant Changes' reinforces purpose. Distinct from sibling query tools.
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?
Explicitly mentions cost ($0.20 USDC via x402) and retry behavior on 402 response, guiding agent when to use. No direct alternative mention, but context makes it the only subscription tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_receiptARead-onlyIdempotentInspect
Return LocalGov.jp's Ed25519 public key (for offline citation-receipt verification). Callers verify receipt signatures using WebCrypto with this key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| alg | Yes | Signature algorithm (Ed25519) |
| issuer | Yes | Trust anchor name |
| pubkey | Yes | Base64-encoded 32-byte Ed25519 public key |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds context about the key's purpose but no new behavioral traits beyond what annotations convey. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that immediately convey the tool's function and usage. No redundant or unnecessary wording.
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?
Tool is simple (no parameters, output schema exists). Description fully explains what the tool returns and how to use the result, making it complete for an agent.
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?
No parameters exist (input schema has no properties), so baseline score of 4 applies per instructions. Description does not need to add parameter 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 it returns an Ed25519 public key for offline receipt verification, distinguishing it from all sibling tools (subsidies/practitioners). The verb 'Return' and specific resource 'LocalGov.jp's Ed25519 public key' provide unambiguous purpose.
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 says callers use this key for verification via WebCrypto, indicating when to use the tool. It does not provide explicit exclusions or alternatives, but sibling tools are unrelated, so no conflict.
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!