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/5 across 8 of 8 tools scored. Lowest: 3.2/5.
Each tool serves a distinct function: comparison, practitioner recommendation, supplementary grants, municipal listing, detail retrieval, search, change subscription, and receipt verification. No two tools overlap in purpose, making selection unambiguous.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., compare_municipal_subsidies, find_practitioner, verify_receipt). This predictability aids agent selection.
With 8 tools, the server is well-scoped for its domain of Japanese municipal subsidies. Each tool addresses a necessary operation without excess or deficiency.
The tool surface covers search, detail, comparison, supplementary grant discovery, practitioner recommendations, change subscriptions, and verification. A minor gap is the lack of a utility to look up municipality codes by name, but the set is otherwise comprehensive.
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 declare readOnly and non-destructive; description adds that it is free and defaults to prefecture. This adds moderate context beyond annotations, but does not detail output format or pagination.
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 front-load the core purpose and use case. No wasted words.
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 and good parameter coverage, the description is fairly complete. It explains the default behavior and use case, though it omits edge cases or error handling.
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 detailed descriptions for each parameter. The description adds value by noting the default prefecture scope and that it is free, which are not in 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?
The description clearly states the tool compares same-category subsidies across nearby municipalities, with a default to same prefecture. It distinguishes from siblings like get_municipality_grants and get_subsidy_detail by specifying the comparison aspect.
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?
Mentions usefulness for relocation/siting decisions but does not explicitly say when to avoid or name alternatives. Guidance is implied rather than explicit.
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 declare readOnlyHint, destructiveHint, and idempotentHint, so the safety profile is clear. The description adds the heuristic title-token match behavior, which provides additional transparency. 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?
Two sentences cover purpose, example, and method. No wasted words, but could be slightly more structured (e.g., separating behavior notes). Front-loaded with the core action.
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 has three well-documented parameters and an output schema exists, the description covers the essential behavioral aspects (heuristic match, free usage). It could mention that output schema defines return structure, but overall complete for its 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% and each parameter has a meaningful description (e.g., central_grant_id with example, limit with range/default, prefecture with purpose). The tool description adds little beyond reinforcing the central_grant_id context, so score is at baseline 3.
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 searches for municipal grants that supplement a given central J-Grants subsidy id, with an example and mention of heuristic title-token match. It distinguishes from siblings like search_subsidies and get_municipality_grants by focusing on supplementary grants for a specific central grant.
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 when to use the tool (when you have a central grant id and want supplementary municipal grants) but does not explicitly state when not to use or contrast with alternatives. The sibling tools exist but no guidance is given.
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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds data coverage information (1,627 of 1,718 municipalities) but does not reveal significant new behavioral traits beyond what annotations provide.
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: first states core purpose, second provides differentiator. No wasted words, front-loaded with key information.
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 read-only list tool with an output schema (mentioned in context signals), the description explains coverage and differentiator. Could mention pagination via limit parameter, but schema covers that. Generally complete for the 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?
Input schema has 100% description coverage for both parameters (limit, municipality_code). Description mentions the code format 'JIS X 0402 6-digit code' but does not add substantial meaning beyond the schema's own 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?
Description clearly specifies 'List all subsidies for a single municipality by JIS X 0402 6-digit code' — a specific verb and resource. It distinguishes from siblings by mentioning data coverage and that J-Grants API has zero municipal entries.
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?
Includes a 'Differentiator' section that explicitly contrasts with alternative data sources (J-Grants public API, LocalGov.jp), indicating when this tool is valuable. However, it does not explicitly state when not to use it (e.g., for prefectural or national subsidies).
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 declare `readOnlyHint: true`, `destructiveHint: false`, and `idempotentHint: true`, covering safety and idempotency. The description adds minor transparency by noting the tool is 'Free' (likely indicating no cost/ auth barrier), but does not disclose any other behavioral traits beyond what annotations provide.
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 with no wasted words. The description is front-loaded with the core purpose ('Fetch the full record for a single subsidy by id') and immediately follows with key output fields. Every sentence earns its place.
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 (single parameter, output schema present, annotations covering safety), the description is nearly complete. It adds value by naming two important return fields. It could mention potential absence of results or error handling, but for a straightforward GET-by-id, it is sufficient to guide the 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?
Schema coverage is 100% with one parameter `id` fully defined (type, required, example values). The description adds no new semantics beyond restating the purpose; it simply says 'by id' which is already clear from the schema. 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?
The description uses a specific verb ('Fetch') and identifies the resource ('full record for a single subsidy by id'). It explicitly lists key return fields (`_source` and `source_url`) and distinguishes itself from siblings like `search_subsidies` which operate on multiple records.
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 when you need a single subsidy by ID and mentions the returned fields, but it does not explicitly state when to use this tool versus alternatives (e.g., `search_subsidies` for queries, `compare_municipal_subsidies` for comparison). No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_subsidiesBRead-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 declare readOnlyHint and idempotentHint. Description adds cost ('Free') and result limit, but limit is also in schema. No disclosure of pagination behavior beyond schema.
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 short sentences. Minor redundancy with schema (parameter list), but overall efficient and 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?
Output schema exists, so return format not needed. Missing sort order explanation and pagination details, but covers core purpose and cost. Adequate for a simple search tool.
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 covers all parameters with descriptions (100% coverage). Description briefly lists some filters but adds no significant detail beyond what 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?
Description states 'Search Japanese central + municipal subsidies' with clear verb and resource, covering scope. No explicit differentiation from siblings like get_municipality_grants or get_subsidy_detail, but name and context suffice.
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?
No guidance on when to use this tool vs alternatives like compare_municipal_subsidies or get_subsidy_detail. Lacks exclusions or prerequisites.
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!