Navigate the U.S. Capitol complex: decode room codes, route buildings, check access, amenities.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose: accessibility routes, general routes, access checks, room finding, nearby amenities, operational overview, day planning, prohibited items, and readiness check. No overlap or ambiguity.
All tool names use lowercase snake_case and are descriptive. While most follow a verb_noun pattern (e.g., check_access, find_room), a few are noun-only (nearby, overview), but the overall pattern is consistent and predictable.
9 tools is well within the ideal range for a domain-specific server. Each tool serves a necessary function without redundancy, and the count feels appropriate for the Capitol complex navigation and visitor support domain.
The tool set covers core domains: navigation, accessibility, room lookup, amenities, security restrictions, and day planning. Minor gaps like event scheduling or tour information exist, but the essential use cases are well-covered.
accessible_routeAStep-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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it avoids stairs, uses elevators/ramps, and surfaces OCAS accommodation contacts. No contradiction with readOnlyHint.
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 sentence contains all key information efficiently, but could be broken into multiple sentences for slightly better readability.
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?
Covers purpose, when to use, and parameters well. However, lacks description of output format (e.g., steps, map, contacts), which would be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaning by noting default mobility profile and examples for from/to (e.g., 'Union Station'). It also lists the enum values explicitly.
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 states it provides step-free accessible directions between two points in the Capitol complex, using specific mobility profiles. It also distinguishes itself from the sibling tool 'route_between' by emphasizing step-free 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?
Explicitly says 'Use this instead of route_between when step-free matters', providing clear guidance on when to use and the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capitolguide_prepAPre-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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds meaningful context about what is verified (secrets, KV, DB, KB) and that it returns a structured report, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and every sentence provides value. No redundancy or unnecessary 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 tool has no parameters, no output schema, and annotations are present, the description fully covers what the tool does and when to use it. It is complete for the agent to understand its role.
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 no parameters, and the input schema coverage is 100%. According to guidelines, baseline is 4, and the description does not need to add parameter information.
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 explicitly states a 'pre-flight readiness check' that verifies specific resources (secrets, KV, DB, KB) and returns a report. This clearly distinguishes it from sibling tools, as it is meant to run before others.
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 'Run before any other tool,' providing clear when-to-use guidance. It also outlines what is verified, implying this is a prerequisite for other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_accessAWhat 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. Description adds that the tool informs only and that rules are volatile and live-source-stamped, aligning with 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?
Two dense sentences convey purpose, inputs, outputs, and caveats. Front-loaded with the mapping, 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 2 enum parameters and no output schema, the description covers the return fields and important behavioral notes. Could briefly mention when to use over siblings, but overall 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?
Schema coverage is 100% with enums and descriptions. The description restates the parameters and explains their combined output, but adds no new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the mapping (visitor_type × zone) → access details, with a specific verb 'check' implied. It is distinct from siblings like 'route_between' or 'prohibited_items' by focusing on access requirements.
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 usage context: 'INFORMS, never grants' and notes final authority lies elsewhere, plus volatile rules. It does not explicitly contrast with siblings, but the guidance is sufficient for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_roomAFind 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) are present; description adds that assignments are 119th Congress, volatile, and live-source-stamped, plus details on what each query returns.
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 with no filler, front-loaded with examples and output details; every sentence adds value.
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, description fully explains what each query returns and notes volatility, making it complete for a single-parameter tool with three modes.
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% (one parameter with description), but the tool description adds significant context by explaining the three query types and their results, beyond the schema's generic 'room code or name'.
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 specifies three distinct query modes (room code, member name, committee) and the output each produces, clearly distinguishing from sibling tools like accessible_route and nearby.
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?
Describes when to use each query type (room code, name, committee) and implies context (e.g., not for routes/accessibility), but does not explicitly exclude alternatives or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nearbyANearest 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. The description adds that results are specific named venues ranked by distance, and provides an example with floor-specific room codes. This goes beyond the annotations by detailing the output structure and input specificity. 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?
The description is extremely concise: two sentences that immediately state the purpose, list possible inputs, and describe the output. Every word is necessary. No filler or repetition. It is front-loaded with the core action ('Nearest...').
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 what the tool does, inputs, and outputs (ranked venues). However, it does not specify if multiple results are returned or the format of the data. Given no output schema, a bit more detail on return structure would be helpful, but it is still adequate for a simple lookup 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?
The input schema already describes each parameter (lat, lon, location). The description adds meaning by clarifying that 'location' can be a room code or building name, and that lat/lon are a pair for GPS coordinates. It also gives a concrete example (SH-217). This fully compensates for the 100% schema coverage, adding usage context.
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 nearest restroom, exit, and food for a given point. It specifies three input types (room code, building name, GPS coordinates) and mentions ranking by distance. This distinguishes it from siblings like 'find_room' which locates a specific room, and 'accessible_route' which provides routes.
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 needing nearby facilities but does not explicitly state when to avoid this tool or provide alternatives among siblings. For example, it could mention using 'accessible_route' for routing or 'find_room' for locating a specific room. The guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
overviewAOperational 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true; the description adds 'Read-only' and details the snapshot contents, providing behavioral context beyond annotations. 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 no wasted words. The first sentence front-loads the purpose and contents; the second is a standalone safety note.
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 output schema, the description partially lists returned data categories but lacks explicit structure (e.g., format of 'queue depths'). For a 0-parameter tool, this is a moderate gap.
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 0 parameters and 100% schema coverage, baseline is 4. The description does not need to add parameter info, and it correctly omits any.
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 provides an 'operational snapshot' and lists specific data: KB version, freshness, queue depths, and recent tool-invocation tail. It distinguishes itself from sibling navigation tools like 'find_room' or 'route_between' by focusing on tenant-level status.
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 explicit when-to-use or alternatives are given. However, the sibling tools are navigation-focused, implying this is for high-level status, but the description lacks direct guidance on context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plan_dayAOptimize 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: 'batched by chamber side to minimize cross-campus crossings,' 'route + minutes between each stop,' 'cross-campus window flagged,' 'leave-by times,' and 'warnings for connections too tight to make.' Annotations already declare readOnlyHint and openWorldHint, and the description adds rich behavioral context 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: the first clearly states the purpose and input requirements; the second details the output features. It is concise, front-loaded, and earns its sentences with high information density.
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 complexity of multi-meeting planning and the lack of an output schema, the description provides a thorough overview of what the tool returns: sequenced itinerary, batching, travel times, warnings, and leave-by times. This is sufficient for an agent to understand the tool's output without needing an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema: it explains that 'who' can be a member name or room code, and provides an example time format ('10:30a'). It also mentions the optional 'accessible' parameter indirectly via 'plan step-free routes' in the schema. While the schema covers basic types, the description enriches understanding of usage.
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.' It specifies the input (list of meetings) and detailed output (itinerary with routing, warnings, leave-by times). It distinguishes itself from siblings like route_between (single route) and accessible_route (step-free routes only) by focusing on multi-meeting optimization.
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 indicates when to use this tool: when you have multiple meetings to schedule. It mentions the input format and what the tool returns, but does not explicitly state when not to use it or compare to alternatives. However, the context from sibling names (e.g., route_between) helps differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prohibited_itemsAWhat 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, but the description adds valuable behavioral context: it is volatile and source-stamped, advising confirmation at visitthecapitol.gov. It also explains that universal weapon/hazard bans are always returned. 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?
The description is concise: three focused sentences. The first sentence states the purpose and key zones. The second sentence adds zone-specific details. The third sentence notes volatility and verification. No wasted words; front-loaded with core 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?
Given the tool is simple with one parameter and no output schema, the description covers the input well but does not explain the return format or structure. It mentions that universal bans are always included, but an agent might benefit from knowing the output schema. However, the readOnlyHint and openWorldHint mitigate some need for complete transparency.
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 has 100% coverage for the single required parameter 'zone' with an enum. The description adds semantic value by explaining what each zone entails (e.g., capitol_cvc is strictest, no food/water; office_building allows food/drink). This goes beyond the schema description 'Which area you're entering'.
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: listing prohibited items for different zones of the Capitol complex. It specifies the exact zones and their restrictions, distinguishing what cannot be brought in. This is a specific verb-resource pairing that differentiates it from sibling tools like check_access or find_room.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when entering different areas of the Capitol. It details each zone's restrictions and includes a note about volatility and verification. However, it does not explicitly state when not to use or mention alternative tools, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
route_betweenATurn-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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses return format ('ordered step list with mode, minutes, and a flag wherever you re-clear security'). Annotations already declare readOnlyHint=true and openWorldHint=true, but description adds behavioral details about security checks.
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 paragraph of 4 sentences, front-loads the core purpose, then gives parameter details, return format, and a tip. No redundant 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?
Covers input examples, parameter effects, return structure, and alternative tool. Without output schema, it provides enough for an agent to understand the tool's output. Minor missing detail: whether route is optimal or time-based, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning: explains what 'from' and 'to' can be (room code, building, Metro, landmark) with concrete examples, and clarifies 'accessible' parameter results in step-free route.
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 provides 'turn-by-turn directions between two points in the Capitol complex' and specifies the types of points (room code, building, Metro station/landmark). Examples distinguish it from sibling tool '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?
Description explains when to use: for directions in the Capitol complex, and mentions setting 'accessible=true' or using 'accessible_route' for step-free routes. It does not explicitly state when not to use, but provides enough context.
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!
