national-parks-mcp-server
Server Details
Plan US National Park Service trips — parks, alerts, campgrounds, things to do, events.
- 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.7/5 across 6 of 6 tools scored.
Each tool targets a distinct aspect of national park information: park lookup, details, alerts, campgrounds, events, and activities. There is no overlap in purpose, making it easy for an agent to select the correct tool.
All tool names follow the consistent 'nps_verb_noun' pattern, using snake_case throughout. The verbs (find, get) are appropriately and consistently used.
With 6 tools, the server is well-scoped for providing national park trip planning information. Each tool serves a clear purpose without unnecessary proliferation.
The tool set covers the core trip planning workflow: finding parks, getting details, alerts, campgrounds, events, and activities. Minor gaps like visitor center details or photos are covered in the park detail tool, so no critical missing functionality.
Available Tools
6 toolsnps_find_campgroundsnational-parks-mcp-server: find campgroundsARead-onlyInspect
Campgrounds at a park or across a state: amenities (potable water, showers, RV dump station, toilets, trash collection, RV access), reservable vs. first-come-first-served site counts, reservation guidance and booking URL, accessibility, and fees — answering "where can I camp at Zion, and can I get an RV hookup?" Get park codes from nps_find_parks. Some parks list lodging or backcountry permits instead of NPS-managed campgrounds; an empty result is not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum campgrounds to return (1–50). | |
| query | No | Free-text search across campground names/descriptions (e.g. "river", "group", "rv"). | |
| start | No | Zero-based pagination offset. | |
| parkCode | No | Park code, or comma-separated list (e.g. "zion"). Get codes from nps_find_parks. Provide parkCode or stateCode. | |
| stateCode | No | Two-letter state code, or comma-separated list. Returns campgrounds across all NPS sites in those states. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Limit applied (populated when results were truncated). |
| shown | No | Campgrounds returned in this response (populated when capped by limit). |
| notice | No | Guidance when no campgrounds matched. |
| totalCount | Yes | Total campgrounds matching the filter before the limit was applied. |
| campgrounds | Yes | Campgrounds at the requested park(s)/state(s). |
| appliedFilters | Yes | Echo of parkCode/stateCode/query as applied. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by detailing what information is returned (amenities, site counts, reservation guidance, accessibility, fees) and explains that an empty result is not an error. This goes beyond the annotations in providing specific 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 a single, well-organized paragraph that front-loads the core purpose and key details. Every sentence is informative and necessary, with no redundancy. It is highly concise while covering essential 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's moderate complexity, the output schema exists (though not shown), and the description explains what is returned. It covers amenities, site types, reservation info, accessibility, and fees, and warns about empty results. This is complete for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully describes parameters. The description does not add new semantics about parameters beyond reinforcing that park codes come from another tool. Given high schema coverage, baseline is 3, and no additional parameter semantics are provided.
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 campgrounds at a park or across a state, listing specific amenities, site counts, reservation info, accessibility, and fees. It provides a concrete example question, making the purpose immediately understandable. It also distinguishes from the sibling nps_find_parks by directing users to get park codes from that 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 tells users to get park codes from nps_find_parks, providing context for how to use the tool effectively. It also notes that empty results may occur when parks list lodging or backcountry permits instead, which sets expectations. However, it does not explicitly state when not to use this tool or compare to sibling tools beyond the reference to find parks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nps_find_eventsnational-parks-mcp-server: find eventsARead-onlyInspect
Scheduled events at a park within a date range — ranger programs, festivals, tours, interpretive events — answering "what's happening at Yellowstone this weekend?" with title, dates and times, location, category, fee, and registration links. Get park codes from nps_find_parks. Paginates by page number, not offset. The events feed is sparser and less consistent than alerts or campgrounds; many parks list few or no events, and an empty result is not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text search across event titles/descriptions (e.g. "ranger", "astronomy", "guided"). | |
| dateEnd | No | End of the date window (YYYY-MM-DD). Use with dateStart. | |
| pageSize | No | Maximum events to return per page (1–50). Paginates by page number, not offset — use with pageNumber to walk through results. | |
| parkCode | No | Park code, or comma-separated list (e.g. "yell"). Get codes from nps_find_parks. Provide parkCode or stateCode. | |
| dateStart | No | Start of the date window (YYYY-MM-DD). Combine with dateEnd to bound the search (e.g. a weekend). Omit for upcoming events from today. | |
| stateCode | No | Two-letter state code, or comma-separated list. Returns events across NPS sites in those states. | |
| pageNumber | No | 1-based page number. Increment to page through results beyond the first page. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Page size applied (populated when results were truncated). |
| shown | No | Events returned on this page (populated when the page was capped by pageSize). |
| events | Yes | Events matching the park/state and date window. |
| notice | No | Guidance when no events matched, or a warning when the upstream envelope reported errors. |
| totalCount | Yes | Total events matching the filter before the page limit. |
| appliedFilters | Yes | Echo of parkCode/stateCode/date window/query as applied. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds behavioral details: pagination mechanism, data consistency issues, and return contents (title, dates, location, fee, registration links). 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?
Four focused sentences: main purpose, park code source, pagination hint, data sparsity note. No redundancy, 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?
Given 7 parameters, 100% schema coverage, and output schema present, the description covers use cases, edge cases (empty results), pagination, and provides a sample query. Fully 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%, but the description adds significant value: explains dateStart/dateEnd usage (omitting start for upcoming events), pagination parameters, and parkCode/stateCode cross-references. All parameters are well-contextualized.
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: finding scheduled events at parks (ranger programs, festivals, tours) within a date range, with a concrete example query. It distinguishes from sibling tools by noting events are sparser than alerts or campgrounds.
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?
Provides explicit usage context: when to use for 'what's happening' queries, cross-reference to nps_find_parks for park codes, explains pagination (page number, not offset), and warns about data sparsity and empty results not being errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nps_find_parksnational-parks-mcp-server: find parksARead-onlyInspect
Resolve a place name, US state, or free-text query to National Park Service parks — the required first step before the detail tools. Returns each park's parkCode (the key nps_get_park, nps_get_alerts, nps_find_campgrounds, nps_get_activities, and nps_find_events all use) plus a compact trip-planning summary (designation, states, description, coordinates, headline activities, entrance fee, NPS page). Coverage is US NPS sites only — national parks, monuments, historic sites, seashores — not state parks and not Forest Service or BLM land.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum parks to return (1–50). The full set is ~470 sites; narrow with query/stateCode rather than paging through everything. | |
| query | No | Free-text search across park names and descriptions (e.g. "yosemite", "civil war", "redwood"). Omit to browse by state. At least one of query or stateCode is recommended; with neither, returns the first page of all ~470 NPS sites. | |
| start | No | Zero-based offset for pagination within the matched set. Use with limit to page through results. | |
| activity | No | Filter to parks offering an activity, matched against each park's activities list (e.g. "hiking", "camping", "stargazing"). Case-insensitive substring match applied locally after fetch — it narrows the returned page, it does not search all ~470 sites by activity. Use nps_get_park to see a park's full activity list. | |
| stateCode | No | Two-letter US state/territory code, or comma-separated list (e.g. "CA", "WY,MT,ID"). Filters to parks located in those states. Combine with query to narrow. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit applied to this response (populated when results were truncated). |
| parks | Yes | Matching parks, each carrying the parkCode needed to chain into the detail tools. |
| shown | No | Number of parks returned in this response (populated when the result set was capped by limit). |
| notice | No | Guidance when no parks matched — suggests broadening the query, checking the state code, or dropping the activity filter. |
| totalCount | Yes | Total parks matching the query/state filter before the limit was applied. |
| appliedFilters | Yes | Echo of the filters as the server applied them (query / stateCode / activity), so the agent can see what was searched. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and openWorldHint annotations, the description discloses the output format (parkCode, trip-planning summary) and coverage boundaries (only US NPS sites, no state parks or other agencies).
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 efficiently convey purpose, usage, and key details without redundancy. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no required fields, and an output schema, the description covers all necessary aspects: pagination, filtering, output contents, and relationship to sibling tools.
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 adds context: how parameters work together, activity as a post-fetch filter, and pagination details, enriching the schema 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 clearly states the tool resolves queries to NPS parks, labels it as the required first step, and distinguishes it from sibling detail tools by name.
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 explicit usage context: it's the first step, recommends using query or stateCode, and lists sibling tools that depend on the output. Lacks explicit exclusion scenarios but is clear on when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nps_get_activitiesnational-parks-mcp-server: get activitiesARead-onlyInspect
Curated things to do and points of interest at a park — title, description, time commitment, location, accessibility, and fee/pet/reservation flags — answering "what should I do at Acadia?" Covers the NPS editorially-curated activity list (distinct from a park's raw activity tags in nps_get_park). Accepts a single 4-letter park code or a single two-letter state code, and at least one is required. Not every park has a curated list; an empty result is not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum activities to return (1–50). | |
| query | No | Free-text search across activity titles/descriptions (e.g. "sunrise", "hike", "tour"). | |
| start | No | Zero-based pagination offset. | |
| parkCode | No | A single 4-letter lowercase park code (e.g. "acad"). Get it from nps_find_parks. Accepts one park code, not a list. Provide parkCode or stateCode. | |
| stateCode | No | A single two-letter state code (e.g. "ME"). Returns curated activities across NPS sites in that state. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Limit applied (populated when results were truncated). |
| shown | No | Activities returned in this response (populated when capped by limit). |
| notice | No | Guidance when no curated activities matched. |
| activities | Yes | Curated activities and points of interest for the requested park/state. |
| totalCount | Yes | Total activities matching the filter before the limit was applied. |
| appliedFilters | Yes | Echo of parkCode/stateCode/query as applied. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld. The description adds that the data is editorially-curated, that empty results are non-errors, and explains parameter behavior (single codes, not lists). 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 well-structured sentences with no waste. Front-loaded with the core purpose, followed by essential usage constraints and edge cases. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, existing output schema, annotations, and sibling context, the description covers all necessary aspects: purpose, input constraints, data nature, and error behavior. Nothing critical is missing.
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 descriptions cover all 5 parameters (100% coverage). The description supplements with key usage rules: only one parkCode or stateCode allowed, at least one required. This adds value 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 clearly states the tool returns curated activities with specific fields (title, description, time commitment, etc.) and explicitly distinguishes itself from nps_get_park's raw tags. The example 'what should I do at Acadia?' grounds the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states accepted inputs (single park code or state code, at least one required) and that empty results are not errors. Mentions sibling tool for raw tags, but does not fully list when to avoid using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nps_get_alertsnational-parks-mcp-server: get alertsARead-onlyInspect
Current alerts for a park or a whole state — closures, hazards, caution notices, and information — with category and recency surfaced first so "is anything closed at Glacier right now?" is answered at a glance. Get park codes from nps_find_parks, or pass a stateCode for a statewide "what's closed" sweep. Returns most-recent-first; an empty result means the park reports nothing closed or hazardous, which is good news, not an error. Closures and road conditions change daily — re-check before departure.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum alerts to return (1–50), most-recent first. | |
| query | No | Free-text search within alert titles/descriptions (e.g. "road", "wildfire", "trail"). | |
| category | No | Filter to one alert category. "Danger" and "Park Closure" are the high-priority ones for trip safety. Omit to see all categories (the default — closures and hazards should not be missed). | |
| parkCode | No | Park code, or comma-separated list (e.g. "glac", "yose,zion"). Get codes from nps_find_parks. Provide parkCode or stateCode; with neither, returns recent alerts service-wide. | |
| stateCode | No | Two-letter state code, or comma-separated list (e.g. "MT", "WY,MT,ID"). Returns alerts for all NPS sites in those states — use for a statewide sweep rather than one park. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Limit applied (populated when results were truncated). |
| shown | No | Alerts returned in this response (populated when capped by limit). |
| alerts | Yes | Current alerts, sorted most-recent first. An empty array means no active alerts — good news, not an error. |
| notice | No | Message when there are no active alerts — explicitly states this is good news (the park reports nothing closed/hazardous right now). |
| totalCount | Yes | Total alerts matching the filter before the limit was applied. |
| appliedFilters | Yes | Echo of parkCode/stateCode/category/query as applied. |
| categoryBreakdown | Yes | Count of returned alerts per category (e.g. "Park Closure: 3, Caution: 1, Information: 2") — gauge severity without scanning every alert. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations: explains most-recent-first order, interprets empty results as good news, and emphasizes dynamic nature of closures. No contradiction with readOnlyHint and openWorldHint.
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 well-structured sentences, front-loaded with purpose. Every sentence adds unique value, no fluff. Efficient and clear.
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?
Complete given complexity: 5 optional params, output schema exists. Covers all parameters, edge cases (empty result), usage patterns, and references sibling tool. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaningful context: prioritizes categories, explains parkCode and stateCode relationship, provides examples for query, and clarifies default behavior. Justifies a score above baseline.
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 retrieves current park alerts, including closures, hazards, and cautions, with specific use cases like 'is anything closed at Glacier right now?' It distinguishes from sibling tools by referencing park codes from nps_find_parks and offering statewide sweeps.
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?
Explicit guidance on using park codes from nps_find_parks or state codes for statewide sweeps, and advises re-checking before departure. Does not explicitly mention when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nps_get_parknational-parks-mcp-server: get park detailARead-onlyInspect
Full trip-planning detail for one or more parks by parkCode: description, activities and topics, entrance fees and passes, operating hours by area/season, contacts, directions, a free-text weather overview, representative images, and the NPS page for everything else. Get codes from nps_find_parks. Up to ten codes are fetched in a single request. Use the fields parameter to trim the payload when you only need certain sections.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Optional detail sections to include beyond the always-present core (name, designation, states, description, coordinates, weather, url). Omit for all sections. Narrow to reduce payload when you only need, say, hours and fees. | |
| parkCode | Yes | One to ten park codes (each a 4-letter lowercase code like "yose", "grca", "zion"). Get codes from nps_find_parks. Multiple codes are fetched in a single request. |
Output Schema
| Name | Required | Description |
|---|---|---|
| parks | Yes | Requested parks with trip-planning detail. |
| notice | No | Guidance when one or more codes did not resolve, or when none did. |
| missingCodes | No | Requested park codes the API returned no record for — likely invalid/misspelled codes. Populated only when some codes did not resolve. |
| returnedCount | Yes | Number of parks the API returned. |
| requestedCount | Yes | Number of park codes requested. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds valuable behavioral details: batch processing of up to ten codes, payload trimming via fields parameter, and a comprehensive list of returned data categories. 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 two sentences long: the first sentence front-loads the core purpose and output, the second provides key usage guidance. No fluff 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?
Given the tool's complexity (many return fields) and the presence of an output schema, the description covers all essential behavioral aspects: multiple park codes, field selection, and prerequisite tool. It is fully self-contained.
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%, and the description adds meaning beyond schema: 'Get codes from nps_find_parks' for parkCode, and explicit advice on using fields to reduce payload. This helps the agent understand parameter usage in 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 the function: 'Full trip-planning detail for one or more parks by parkCode'. It lists specific content categories and distinguishes from sibling tools like nps_find_parks (code retrieval) and nps_get_activities (specific section).
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 explicit usage advice: 'Get codes from nps_find_parks', 'Up to ten codes are fetched in a single request', and 'Use the fields parameter to trim the payload'. It does not explicitly mention alternative tools for specific sections, but the guidance is clear and sufficient.
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!