Search and resolve government entities worldwide at every tier; open civic data for AI agents.
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.4/5 across 8 of 8 tools scored.
Each tool targets a distinct resource and action: search/get entities, search/get CGJ reports, list countries/service types, get product coverage, and submit service requests. There is no overlap; even the two search tools search different domains (entities vs CGJ reports), and the two get tools retrieve different kinds of records.
All tool names follow a consistent verb_noun pattern using snake_case: get, list, search, and submit. There is no mixing of conventions or vague verbs, making the tool set predictable and easy to navigate.
With 8 tools, the server is well-scoped for its dual purpose of government entity data browsing and service request submission. The count is within the ideal range and each tool earns its place without redundancy or bloat.
The surface covers entity discovery and retrieval, CGJ report search and retrieval, service type listing, and service request submission. Missing is a way to check the status of an already-submitted request or update/cancel it, but these are not core to the stated purpose and can be worked around by the submit response.
get_cgj_reportAInspectGet full details for a specific California Grand Jury report by ID. Includes findings, recommendations, and responses. Requires X-API-Key header (50 req/day shared with data.ungovr.org). Register at https://data.ungovr.org/api/register.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Report ID (from search results) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses critical behavioral context: requires X-API-Key header, rate limit of 50 req/day shared with data.ungovr.org, registration URL, and what content the report includes. This fully addresses the burden.
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: the first states purpose and content, the second states auth and rate limit. Every sentence earns its place with no 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?
For a single-parameter retrieval tool, it covers purpose, content included, auth requirement, and rate limit. Even without an output schema, the description gives sufficient context for an agent to invoke it correctly.
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 the parameter description 'Report ID (from search results)'. The tool description adds little beyond 'by ID', which is already implied, so the 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 clearly states the action ('Get full details') and resource ('specific California Grand Jury report by ID'), distinguishing it from the sibling search_cgj_reports by emphasizing ID-based retrieval.
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?
Usage is implied: use when you have a specific report ID, and the parameter description says 'from search results'. However, there is no explicit alternative comparison or when-not-to-use guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entityAInspectGet full details for a specific government entity by its URL slug (e.g., "us/ca/ventura"). Works at any depth of the hierarchy, including cities, school districts and special districts (e.g., "us/ca/santa-barbara/spd/carpinteria-valley"). Returns name, type, website, parent, children, domain status, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Entity URL slug at any depth (e.g., "us/ca/ventura", "us/ca/santa-barbara/city/carpinteria", "ie/cork", "kr/seoul") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly discloses that the tool returns name, type, website, parent, children, domain status, and metadata, giving a good sense of the output. It does not mention error behavior or permissions, but for a read operation this is acceptable.
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, using two sentences to convey purpose, examples, and return fields. Every sentence adds value, with no redundant or filler content.
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 simple with one parameter and no output schema. The description covers the purpose, usage scope, and return fields, which is sufficient for an agent to select and invoke the tool. It could mention error handling or case sensitivity, but these are minor 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 schema provides 100% coverage of the single parameter 'slug' with its own detailed description and examples. The tool description adds little beyond the schema, only repeating 'by its URL slug' with a couple of examples. Baseline 3 is appropriate because the schema already handles parameter semantics.
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's purpose: getting full details for a specific government entity by URL slug. It distinguishes itself from search_entities (which would find entities) and other sibling tools by focusing on retrieval of a single entity's full 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 provides clear context: use this tool when you have a specific entity's URL slug and want full details. It does not explicitly name alternatives or exclusions, but the context is unambiguous. It also clarifies that it works at any hierarchy depth, which is useful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_coverageAInspectGet the full hierarchy of government entities where an UnGovr product is available. product="request" returns the worldwide UnGovr Request coverage footprint (where you can file a government service request); product="cgj" returns Civil Grand Jury coverage. Public, no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product id: "request" or "cgj" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses authentication requirements ('Public, no API key required') and clarifies the meaning of both product values. It does not discuss rate limits or response format, but for a simple read-heavy tool, this is adequate.
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 concise: two sentences that front-load the purpose, then explain the parameter values. Every clause adds value, with no redundancy or fluff.
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 one-parameter tool with no output schema and no annotations, the description covers the essential aspects: purpose, parameter choices, and access requirements. It is complete enough for an agent to invoke the tool correctly without further context.
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 enum values, but the description adds meaningful semantics beyond the schema: it explains what each product value returns (worldwide footprint for 'request', Civil Grand Jury coverage for 'cgj'), which is not in the schema's own description. This significantly aids correct parameter selection.
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's purpose: retrieving the full hierarchy of government entities for an UnGovr product. It names the tool's resource ('coverage footprint') and differentiates between the two product values, distinguishing it from sibling tools like get_cgj_report or get_entity.
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 provides clear context for when to use each product parameter value, but does not explicitly mention alternatives or exclusions. The context is sufficient for the tool's simplicity, but no 'use this instead of X' guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_countriesAInspectList all countries with government entity data in UnGovr, including entity counts and coverage metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It does indicate what the tool returns (countries with entity counts and coverage metadata), but it does not explicitly state that it is read-only, mention pagination, or disclose any other behavioral traits. The verb 'list' implies a safe read, but this is not explicitly stated.
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 sentence that front-loads the primary action and resource, with no unnecessary words. It is highly concise and well-structured.
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 parameterless listing tool, this description is complete. It clearly states the scope (all countries with government entity data) and the content of the result (entity counts and coverage metadata). Given the simplicity of the tool and absence of an output schema, no further details are needed.
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 is nothing for the description to add beyond the schema. Per the baseline for 0 params, a score 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 uses the specific verb 'List' with a clear resource ('all countries with government entity data in UnGovr') and mentions included details (entity counts, coverage metadata). This distinguishes it from sibling tools like get_entity or search_entities, making its purpose immediately clear.
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 states what the tool does but does not provide explicit guidance on when to use it versus alternatives. Usage is implied for obtaining an overview of all countries, but no exclusions or references to sibling tools are given, so it falls short of a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_service_typesAInspectList available service request categories and types for a country. Returns service types grouped by category (e.g., Infrastructure, Utilities, Parks). Use this to discover valid service_type_id values for submit_service_request. Supported countries: US, IE (Ireland), GB (United Kingdom).
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Two-letter country code: "us", "ie", or "gb" (default: "us") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses that results are grouped by category, provides example categories, and lists supported countries. However, it does not discuss authentication, rate limits, or behavior with invalid country codes, leaving some behavioral aspects undisclosed.
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 concise sentences front-load the purpose, then add return format and usage. 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?
For a simple list tool with one optional parameter, the description covers purpose, return grouping, usage, and supported countries. It lacks details like pagination or error handling, but these are not critical given the tool's simplicity. It is sufficiently complete, though not exhaustive.
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 fully describes the 'country' parameter with codes and default (100% coverage). The description adds minor context (full country names) but doesn't introduce new parameter semantics beyond the schema. Baseline of 3 applies.
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 opens with a specific verb ('List') and resource ('service request categories and types'), and explicitly distinguishes itself from sibling tools like get_cgj_report or search_entities by focusing on service request data. It also mentions grouping and examples, making the purpose unmistakable.
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 clearly states when to use the tool: 'Use this to discover valid service_type_id values for submit_service_request.' This provides explicit context for the downstream use case. However, it doesn't mention when not to use or alternative tools, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cgj_reportsAInspectSearch California Grand Jury reports by county, year, and/or title keyword. Returns report metadata (title, year, county, themes). Requires X-API-Key header (50 req/day). Register at https://data.ungovr.org/api/register. For the list of valid county names, query the UnGovr entity API: GET https://data.ungovr.org/v1/entities/us/ca.json
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Filter by jury year (reports from that year) | |
| limit | No | Maximum results to return (default 20, max 100) | |
| query | No | Substring to match against report title (case-insensitive) | |
| county | No | County name (e.g., "Los Angeles", "San Francisco") | |
| offset | No | Number of results to skip for pagination (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details: requires X-API-Key header, rate limit of 50 req/day, and returns report metadata. It also advises querying the UnGovr entity API for valid county names. This goes beyond what the schema provides and helps the agent understand authentication, limitations, and prerequisites.
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 front-loaded. The first sentence states the tool's purpose and filters, the second covers authentication, and the third offers a practical tip. No redundant or extraneous information is included.
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 no annotations and no output schema, the description covers the essential aspects: purpose, filters, return metadata, authentication, rate limit, and county name source. It does not mention pagination behavior or error responses, but these are not critical for a search tool and the schema includes limit/offset fields.
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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by grouping the main filters (county, year, title keyword) and explicitly instructing how to obtain valid county names via the entity API. This extra context improves 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 tool searches California Grand Jury reports with specific filters (county, year, title keyword) and returns metadata. The verb 'Search' plus the resource and filter criteria make the purpose unambiguous and distinguish it from sibling tools like get_cgj_report.
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 on how to use the tool: search by county, year, and/or title keyword, and returns metadata. It also explains the API key requirement and points users to the entity API for valid county names. However, it does not explicitly mention when to use this tool versus alternatives like search_entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_entitiesAInspectSearch government entities by country, optional state/province, name query, and entity type. Searches every tier of government in the jurisdiction, not just the top one: counties, cities, school districts, special districts, fire and police districts, joint powers authorities and regulated utilities are all reachable. Returns matching entities with slugs, types, and website URLs, plus a "scope" field — "full" means every tier was searched, "direct_children" means only the top tier was (narrow by state and search again). Unrecognised arguments are rejected, not ignored.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by entity type, exact match (e.g., "county", "city", "school_district", "special_district", "fire_district", "police_department", "jpa", "regulated_utility"). The parameter is named "type", not "entity_type". | |
| limit | No | Maximum results to return (default 20, max 100) | |
| query | No | Substring to match against entity name (case-insensitive) | |
| state | No | State/province code to narrow search (e.g., "ca" for California, "on" for Ontario) | |
| offset | No | Number of results to skip for pagination (default 0) | |
| country | Yes | Two-letter country code (e.g., "us", "ca", "ie") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It excels by explaining the tier-search behavior, the meaning of the 'scope' field ('full' vs 'direct_children'), and the handling of unrecognized arguments. It also enumerates the types of entities reachable and the return fields, going well beyond a basic tool statement.
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, each earning its place. The first sentence states the core functionality, the second elaborates on the unique tier coverage, and the third explains return fields, the scope behavior, and a usage caveat. It is dense but not bloated, with no filler 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?
Despite having no output schema or annotations, the description covers the essential contextual information: what the tool searches, what it returns, how to interpret the 'scope' field, and how to react to 'direct_children' results. It also warns about strict argument handling. This is complete for a search tool of this 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?
The schema describes all six parameters with detailed explanations and examples, so the baseline is 3. The description restates a few parameters (country, state, name query, entity type) but adds no additional semantic meaning or clarification beyond what the schema already provides. No gaps to compensate for.
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's purpose with a specific verb ('Search') and resource ('government entities'), and enumerates the filtering dimensions (country, state/province, name query, entity type). It distinguishes itself from siblings by emphasizing that it searches every tier of government, not just the top one, which is a unique capability.
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 on when to use the tool: it covers all government tiers, making it the comprehensive search option. It also gives actionable guidance for the 'direct_children' scope case ('narrow by state and search again') and warns that unrecognized arguments are rejected. However, it does not explicitly mention alternatives or 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.
submit_service_requestAInspectSubmit a government service request (e.g., report a pothole, broken streetlight, illegal dumping). The request is validated, geocoded, classified, routed to the correct government entity, and recorded. Delivery is enabled per-entity: where the target channel is live, the request is transmitted (response delivery.state = "sent", or "held" when queued for review); for entities not yet enabled it is recorded and routable but not transmitted (delivery.state = "dry_run", or "handoff" with a redirect_url the user finishes). Always check delivery.state. Requires X-API-Key header. Rate limit: 2 requests/hour. Supported countries: US, IE (Ireland), GB (United Kingdom).
| Name | Required | Description | Default |
|---|---|---|---|
| images | No | Up to 3 base64-encoded images (optional). Each item: {data: "base64...", media_type: "image/jpeg"} | |
| address | No | Address to geocode (e.g., "123 Main St, Ventura, CA 93001"). Provide this OR latitude+longitude. | |
| latitude | No | Latitude (-90 to 90). Provide with longitude as alternative to address. | |
| longitude | No | Longitude (-180 to 180). Provide with latitude as alternative to address. | |
| description | Yes | Description of the issue (10-5000 characters) | |
| country_code | No | Country code: "US", "IE", or "GB" (default: "US") | |
| contact_email | Yes | Email of the person reporting the issue | |
| service_type_id | No | Service type ID from list_service_types (optional — auto-classified from description if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses side effects: requests are validated, geocoded, classified, routed, and recorded. It explicitly explains delivery states (sent, held, dry_run, handoff) and instructs the agent to always check delivery.state. It also surfaces auth requirements, rate limits, and geographic restrictions—rich behavioral context beyond simple 'submit'.
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 dense but every sentence earns its place. It front-loads purpose, then explains processing and delivery states, and ends with requirements. While it is longer than average, the complexity of the tool (side effects, delivery modes, auth) justifies the length with no fluff.
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 complexity and the absence of an output schema, the description is remarkably complete. It covers the request lifecycle, detailed delivery state semantics, the critical 'always check delivery.state' guidance, and the handoff/redirect_url flow. It also addresses auth, rate limiting, and supported countries—essential for correct invocation.
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 100% coverage with detailed descriptions for every parameter, including alternatives (address vs lat/long), defaults (country_code), and optional behavior (service_type_id auto-classified). The description adds the overall pipeline context but does not deepen individual parameter meaning. Baseline 3 applies due to high schema coverage.
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 submits a government service request with concrete examples (pothole, streetlight, dumping). It specifies the processing pipeline (validated, geocoded, classified, routed, recorded), making the action and resource unmistakable. It also distinguishes itself from the sibling read/list tools by using 'submit' as the verb.
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 on when to use this tool: it is the only write/submit tool among siblings, and it lists prerequisites (X-API-Key), rate limits, and supported countries. However, it does not explicitly name alternatives or say when not to use it, relying on the tool name and sibling context for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
