capitolguide
Server Details
Navigate the U.S. Capitol complex: decode room codes, route buildings, check access, amenities.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.4/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose. The only potential overlap between accessible_route and route_between is explicitly disambiguated by the descriptions: one is for step-free routes, the other for general routing, and the accessible_route description advises using it when step-free matters.
All tool names follow the same snake_case convention and are descriptive of their function. The naming pattern is consistent across all 9 tools, making it predictable for the agent.
With 9 tools, the count is well within the ideal range of 3-15. Each tool serves a necessary function for the Capitol guide domain, and none feel redundant or excessive.
The tool surface covers all major visitor needs: routing (general and accessible), room lookup, access requirements, prohibited items, and day planning. The addition of capitolguide_prep and overview for operational readiness shows thoughtful completeness.
Available Tools
9 toolsaccessible_routeARead-onlyInspect
Step-free / accessible directions between two points in the Capitol complex by mobility profile (wheelchair, limited_mobility, stroller, low_vision). Routes over elevators/ramps only, avoids stairs, and surfaces OCAS accommodation contacts. Use this instead of route_between when step-free matters.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destination: room code, building name, or Metro station / landmark | |
| from | Yes | Origin: room code, building name, or Metro station / landmark (e.g. 'Union Station') | |
| mobility_profile | No | Mobility profile (default: any step-free) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. Description adds valuable context: routes over elevators/ramps, avoids stairs, and includes OCAS accommodation contacts. 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 sentences with key info front-loaded. Minor clarity issue: 'surfaces OCAS accommodation contacts' may require interpretation, but overall concise and 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?
No output schema, but description does not explain return format. However, it provides sufficient context for decision-making. Agent can infer typical directions output. Good completeness given 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% with parameter descriptions. Description adds context for mobility_profile by listing enum values but does not significantly enhance schema information. 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?
Clearly states it provides step-free directions between two points in the Capitol complex, differentiating from sibling route_between by focusing on accessibility. Includes specific mobility profiles and routing constraints.
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 advises using this tool instead of route_between when step-free matters. Also mentions surfacing accommodation contacts, giving agents clear context for when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capitolguide_prepARead-onlyInspect
Pre-flight readiness check. Run before any other tool. Verifies secrets, KV, DB connectivity, and KB version + freshness. Returns a structured readiness report.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: it checks specific dependencies (secrets, KV, DB, KB). Aligns with readOnlyHint=true by not implying any modification. Could note it's non-destructive but still clear.
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 purpose and usage order. 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?
No output schema, but description mentions 'structured readiness report' which gives an idea of return. Covers purpose, usage order, and verification targets. Could elaborate on the report's structure but adequate.
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, baseline 4. Description explains the tool's function without needing parameters, adding meaning about what is verified.
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 it's a pre-flight readiness check that verifies secrets, KV, DB connectivity, and KB version/freshness. This distinguishes it from siblings which focus on navigation or access rather than system readiness.
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 instructs to 'Run before any other tool', providing clear timing context. Does not mention when not to use or alternatives, but the directive is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_accessARead-onlyInspect
What access a visitor needs for a zone of the Capitol complex: (visitor_type × zone) → allowed?, credential, escort, lead time, required docs, security entrance, and the granting authority. INFORMS, never grants — final authority is the member office / Capitol Police / Secret Service. Rules are volatile and live-source-stamped.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | Yes | Which area of the complex | |
| visitor_type | Yes | Who is visiting |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description details specific outputs, states that rules are volatile and live-source-stamped, and clarifies that it informs but does not grant access, adding valuable behavioral context.
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), front-loads the core function, and includes essential caveats without extraneous information. Every part serves a purpose.
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 two-parameter tool with no output schema, the description fully covers outputs, usage limitations, and the dynamic nature of the data, providing complete context for agent decision-making.
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 description reiterates the combination of visitor_type and zone as the key inputs, but adds little beyond the schema's own parameter descriptions since coverage is 100% and each parameter already has clear enum 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 clearly defines the tool's purpose: determining what access a visitor needs for a zone, mapping visitor type and zone to specific outputs like allowed?, credential, etc. It emphasizes the informational nature and distinguishes from granting authority.
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 the tool is for informational purposes only ('INFORMS, never grants') but does not explicitly compare with sibling tools or provide when-not-to-use guidance. The caveat about final authority helps but lacks direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_roomARead-onlyInspect
Find a Capitol office by ROOM CODE (e.g. 'SH-217', '2310 Rayburn', '167 Russell', 'H-232'), by MEMBER NAME (e.g. 'Cornyn', 'Ted Cruz', 'Womack'), or by COMMITTEE ('Senate Judiciary', 'Ways and Means', 'House Armed Services'). A room code returns the decoded location plus who currently holds it; a name returns that member's current office; a committee returns its office / principal hearing room. Member & committee assignments are the 119th Congress (volatile, live-source-stamped).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A room code/address, or a member's name |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, and the description adds valuable behavioral context: what each query returns (decoded location, current holder, committee office/hearing room) and notes that assignments are for the 119th Congress and are volatile/live-source-stamped.
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 concise sentences, front-loading the core functionality and then providing essential details about return types and data sources. Every sentence adds value without 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?
Despite no output schema, the description fully explains what each query type returns. It addresses volatility and source stamping, making the tool's behavior predictable for the agent. All dimensions of usage are covered.
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 one parameter with a brief description, but the tool's description enriches it by detailing acceptable formats (e.g., 'SH-217', '2310 Rayburn', member names, committee names) and explaining the output context, far exceeding 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 the tool finds a Capitol office by three distinct query types (room code, member name, committee) with specific examples. It differentiates itself from sibling tools like accessible_route or nearby by focusing on office location lookups.
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 explains when to use the tool (for room code, member name, or committee queries). However, it does not explicitly state when not to use it or mention alternatives for other needs, which would improve clarity further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nearbyARead-onlyInspect
Nearest restroom, exit, and food for a specific point — a room code (floor-specific, e.g. the exact nearest bathroom to SH-217), a building name, or GPS coordinates {lat, lon}. Returns specific named venues ranked by distance.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (e.g. from device GPS) — pair with lon | |
| lon | No | Longitude — pair with lat | |
| location | No | Room code or building name |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds behavioral details: returns specific named venues ranked by distance, and accepts multiple location formats. This adds valuable context beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the purpose and input types, the second explains the output. It is front-loaded with the most important 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 tool with 3 parameters and no output schema, the description adequately covers inputs and output format. It mentions returning named venues ranked by distance. It does not specify behavior when no results are found, but the openWorldHint annotation mitigates this. Overall, it is complete enough 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds meaning by giving concrete examples (e.g., SH-217) and explaining the relationship between location and lat/lon, reinforcing the schema but adding practical value.
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 finds nearest restroom, exit, and food for a specific point, with concrete examples of input formats (room code like SH-217, building name, or GPS coordinates). This distinguishes it from siblings like find_room (for finding a room) and route_between (for routing).
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 specifies when to use the tool: for finding nearby amenities. It does not explicitly list when not to use it or provide alternative tools, but the context of sibling tools and the clear scope make the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
overviewARead-onlyInspect
Operational snapshot for the caller's tenant: KB version + freshness, queue depths (itineraries / draft meetings / active nudges), and the recent tool-invocation tail. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. Description adds specific output content (KB version, freshness, queue depths, tool-invocation tail) and confirms read-only nature, aligning with annotations without 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?
Single concise sentence with front-loaded purpose keyword 'Operational snapshot'. Every phrase adds value; 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?
Given 0 parameters and no output schema, description adequately explains return content (KB version, freshness, queue depths, tool-invocation tail) and nature (snapshot, read-only). Complete for a simple status 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?
No parameters defined; schema coverage is 100% trivially. Baseline for 0 params is 4, and description correctly avoids discussing non-existent parameters.
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?
States specific verb ('operational snapshot') and resource ('caller's tenant') with enumerated data points (KB version, freshness, queue depths, tool-invocation tail). Clearly distinguishes from sibling tools which are action-oriented rather than status-summary.
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 getting a quick status overview via 'Operational snapshot' and 'Read-only', but does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling names provide some context but no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plan_dayARead-onlyInspect
Optimize a multi-meeting Hill day. Give a list of meetings (each a member name or room code, with an optional time like '10:30a'). Returns a sequenced itinerary: batched by chamber side to minimize cross-campus crossings, the route + minutes between each stop, the cross-campus window flagged, 'leave-by' times when meetings are timed, and warnings for connections too tight to make.
| Name | Required | Description | Default |
|---|---|---|---|
| meetings | Yes | ||
| accessible | No | Plan step-free routes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits: it returns a sequenced itinerary, batches by chamber side, includes route details, flags cross-campus windows, provides leave-by times, and warns about tight connections. These details go beyond the readOnlyHint and openWorldHint annotations, which are consistent.
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 and well-structured, starting with the primary action, followed by input format, then output details. Every sentence adds value without unnecessary repetition.
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 (multi-meeting optimization) and the absence of an output schema, the description provides sufficient context about input requirements and output features. It covers key aspects like batching, routing, and warnings, though it could briefly mention error conditions or limits.
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 description adds meaning to the parameters: it explains that 'meetings' should be a list of objects with 'who' and optional 'time', and clarifies that 'accessible' enables step-free routing. With 50% schema coverage, it effectively compensates for missing schema 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 clearly states the tool's purpose: 'Optimize a multi-meeting Hill day' and details the input (list of meetings) and output (sequenced itinerary). It distinguishes from siblings by focusing on multi-meeting optimization vs. single-route tools like 'route_between' or 'accessible_route'.
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 implicitly advises when to use the tool by specifying the input format and expected output. It does not explicitly state when not to use or list alternatives, but the sibling tool names and context provide sufficient differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prohibited_itemsARead-onlyInspect
What you cannot bring into an area of the Capitol complex (security screening). zone: 'capitol_cvc' (the Capitol + Visitor Center — strictest, no food/water), 'gallery' (House/Senate galleries — no phones/cameras), or 'office_building' (the 6 office buildings — food & drink allowed). Always returns the universal weapon/hazard bans too. Volatile — live-source-stamped; confirm at visitthecapitol.gov before you travel.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | Yes | Which area you're entering |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description confirms no side effects and adds that results are 'volatile — live-source-stamped', reinforcing the openWorldHint. 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?
Three sentences, front-loaded with the purpose, each sentence adds value: purpose, zone details, volatility warning. 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?
The description covers the three zones and mentions universal bans, but lacks details on the return format. Given the tool's simplicity and no output schema, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'zone' has an enum in the schema, and the description explains each enum value with specific examples of prohibited items, adding meaningful context beyond the schema's description.
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 tells what you cannot bring into specific areas of the Capitol complex, distinguishing it from sibling tools that handle routes, accessibility, or overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking prohibited items before security screening, but does not explicitly state when not to use it or provide alternative tools. The context is sufficient for a straightforward tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
route_betweenARead-onlyInspect
Turn-by-turn directions between two points in the Capitol complex. Each point can be a room code, a building name, OR a Metro station / landmark (e.g. 'Capitol South Metro' → '2412 Rayburn', 'Union Station' → '517 Hart', or to the 'Supreme Court' / 'Library of Congress'). Returns an ordered step list with mode (walk/tunnel/subway), minutes, and a flag wherever you re-clear security. Set accessible=true for a step-free route (or use accessible_route).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destination: room code, building name, or Metro station / landmark | |
| from | Yes | Origin: room code, building name, or Metro station / landmark (e.g. 'Capitol South Metro') | |
| accessible | No | Prefer a step-free / accessible route |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the return format (ordered step list with mode, minutes, and a security flag) and the accessible option. Annotations already indicate read-only and open-world behavior, so the description's behavioral context is supplementary.
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, consisting of three sentences that front-load the primary purpose, followed by examples and return format. Every sentence adds value without 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?
Despite the absence of an output schema, the description adequately describes the output structure (ordered step list with mode, minutes, security flag). It covers input types and the accessible option, making it sufficiently 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?
With 100% schema description coverage, the description still enhances parameter understanding by providing concrete examples for 'from' and 'to' and clarifying the 'accessible' parameter's effect. This exceeds the 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 that the tool provides turn-by-turn directions between two points in the Capitol complex. It specifies the types of points (room code, building name, Metro station, landmark), and distinguishes from the sibling accessible_route by mentioning the accessible parameter or an alternative tool.
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 when to set accessible=true for a step-free route or to use the dedicated accessible_route tool. It provides concrete examples of valid inputs, offering clear guidance on tool invocation. However, it does not explicitly state 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.
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!