A
license-
qualityD
maintenanceProvides access to the National Park Service API to search for U.S. national parks, view park details, check alerts and closures, find visitor centers, campgrounds, and upcoming events.
418
MIT
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
- Repository
- cyanheads/national-parks-mcp-server
- GitHub Stars
- 1
- Server Listing
- National Parks MCP Server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.6/5.0
Tool DescriptionsA
Average 4.6/5 across 6 of 6 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool targets a distinct area: parks, campgrounds, events, activities, alerts, and park details. There is no overlap in purpose, making it easy for an agent to select the correct tool.
Naming Consistency5/5
All tools follow the consistent pattern 'nps_[verb]_[noun]' using snake_case. Verbs are either 'find' for search operations or 'get' for retrieval by park code, with no deviations.
Tool Count5/5
With 6 tools, the server covers essential trip-planning functionality without being overwhelming. Each tool is well-justified and the count feels appropriate for the domain.
Completeness4/5
The tool set covers parks, campgrounds, events, activities, alerts, and park details. Missing dedicated tools for trails or lodging, but campgrounds partially address lodging and park details provide weather. Overall solid coverage.
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.
ParametersJSON Schema
| 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") — 4-letter lowercase codes. 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
ParametersJSON 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
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds valuable behavioral context: the tool returns amenity details, site counts, and booking URLs; it warns that some parks list non-campground accommodations, and an empty result is not an error. This goes beyond annotations and helps the agent handle edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first succinctly lists what the tool returns and gives an example query; the second provides a prerequisite and a caveat. Every sentence is informative, no fluff, front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (5 optional parameters, rich schema, output schema exists), the description covers all necessary aspects: what data is returned, how to filter, how to handle empty results, and a link to a sibling tool for park codes. It is complete for guiding agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented. The description adds meaning by suggesting how to obtain park codes (using nps_find_parks) and by implying that stateCode and parkCode are the primary filters. It also hints at the free-text query capability with examples (e.g., 'river', 'rv'). This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns campgrounds with amenities, site counts, reservation details, accessibility, and fees, using specific verb 'find' and resource 'campgrounds'. It distinguishes from sibling tools by referencing nps_find_parks for park codes and notes that empty results are not errors for parks without NPS-managed campgrounds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to get park codes from nps_find_parks, providing a clear prerequisite. It also explains that empty results may occur for parks with lodging or backcountry permits, setting expectations. However, it does not explicitly state when to use this tool over alternatives like nps_find_events or nps_get_activities.
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.
ParametersJSON Schema
| 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") — 4-letter lowercase codes. 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 (e.g. "WY", "WY,MT,ID"). 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
ParametersJSON 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
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds important behavioral details: pagination by page number (not offset), that many parks have few or no events, and that an empty result is not an error. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences with no filler. The first sentence states the core purpose, the second provides example and links to related tool, and the third covers behavioral traits. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count (7, none required), presence of output schema, and annotations, the description covers key points: what tool does, how to get park codes, pagination, data consistency. It could mention sorting or default date behavior more, but the output schema likely covers return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about pagination mechanics (pageNumber increments) and the nature of event data (sparse, inconsistent). It also links parkCode to nps_find_parks, which adds value beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('find', 'answering') and clearly identifies the resource ('scheduled events at a park') with concrete examples like ranger programs and festivals. It distinguishes from sibling tools by contrasting with alerts and campgrounds, and by mentioning park codes from nps_find_parks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case ('what's happening at Yellowstone this weekend?') and tells the user to get park codes from nps_find_parks. It also notes that the events feed is sparser than alerts or campgrounds, helping manage expectations. It does not explicitly state when not to use it, but the context is sufficient.
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.
ParametersJSON Schema
| 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"). Results are re-ranked locally so an exact parkCode or name match leads: NPS returns matches in alphabetical-by-code order with no relevance ranking, so without this the obvious park can sit behind sites that only mention the term in their description. 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 (the API has no activity param) across every site matching query/stateCode, then paginated with start/limit — so totalCount is the true count of matching parks, not a per-page tally. 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
ParametersJSON 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
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds local re-ranking, pagination behavior (totalCount true count), and return fields. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Main description is front-loaded and clear. Parameter descriptions are thorough but not overly verbose. Could be slightly more concise, but still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. Description covers purpose, usage, coverage, and behavioral nuances. Complete for AI to select correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds significant context: limit usage advice, query re-ranking, activity substring match and pagination, stateCode comma-separated. Goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: resolve a place name or query to NPS parks, and explicitly identifies it as the required first step before detail tools. It distinguishes from sibling tools by naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (first step) and mentions alternatives (detail tools). Provides guidance on query vs stateCode, coverage (US NPS only), and behavior when neither is provided.
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.
ParametersJSON Schema
| 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
ParametersJSON 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
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not repeat that. It adds behavioral context: the tool covers editorial lists (not raw tags), requires exactly one of parkCode/stateCode, and empty results are not errors. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and every clause adds essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, output schema exists), the description covers purpose, parameter constraints, edge cases (empty results), and differentiation from siblings. It is complete without needing to detail the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that only a single park code or state code is accepted and that stateCode returns activities across sites in that state. It also references nps_find_parks for obtaining park codes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves curated things to do at a park, distinguishing it from raw activity tags in nps_get_park. It provides an example use case ('what should I do at Acadia?') and specifies input constraints (single park code or state code).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 editorially-curated activities) and explicitly contrasts with nps_get_park for raw tags. It notes that not every park has a curated list, but does not explicitly state when to avoid using it. Sibling tools provide context for alternatives.
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 with totalCount 0 means the park reports nothing closed or hazardous — good news, not an error. An empty page with a non-zero totalCount only means start ran past the end, so read the notice rather than the empty list. Closures and road conditions change daily — re-check before departure.
ParametersJSON Schema
| 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"). | |
| start | No | Zero-based offset for pagination within the matched set. Use with limit to page through results — when totalCount exceeds what was returned, re-request with start advanced by limit. | |
| category | No | Filter to one alert category. "Danger" and "Park Closure" are the high-priority ones for trip safety. Applied locally (the API has no category param) across every alert matching parkCode/stateCode/query, then paginated with start/limit — so totalCount is the true count of matching alerts, not a per-page tally. 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") — 4-letter lowercase codes. 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
ParametersJSON 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 with totalCount 0 means no active alerts — good news, not an error; with a non-zero totalCount it means start paged past the end of the matches. The notice says which. |
| notice | No | Message when the page is empty — states which case it is: good news (totalCount 0, the park reports nothing closed/hazardous right now) or a paging artifact (start ran past the end of a non-empty matched set). |
| 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
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds valuable behavioral details: results are most-recent-first, pagination behavior (empty page vs. empty set), local category filtering, and the advisory to re-check before departure. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with clear sections and front-loaded purpose. Every sentence adds information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, pagination, output schema existence, and real-world variability, the description covers usage, edge cases (empty results), and daily-changing nature. It references sibling tools and provides complete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by explaining the local category filter nuance, the meaning of totalCount, and practical usage of parkCode/stateCode. This exceeds baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns current alerts for a park or state, listing categories (closures, hazards, etc.) and emphasizing recency. It distinguishes from sibling tools by mentioning nps_find_parks for codes and implying a different focus from nps_find_campgrounds or nps_get_park.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use parkCode vs stateCode, how to get park codes from nps_find_parks, and interprets empty results. It could more directly contrast with siblings, but the guidance on statewide vs. single-park usage 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.
ParametersJSON Schema
| 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
ParametersJSON 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
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), description discloses that up to ten codes are fetched in a single request, options to trim payload via fields parameter, and provides a free-text weather overview. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is thorough and well-structured, front-loading the main purpose. Could be slightly more compact, but all sentences are informative and justify their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of trip-planning detail and presence of output schema (implied), description covers what is returned, parameter usage, source of codes, and references the NPS page for additional info. Fully adequate for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value: explains parkCode as 4-letter codes from nps_find_parks, describes fields enum items and their purpose, and gives usage guidance (omit for all, narrow for specific sections).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it provides full trip-planning detail for parks by parkCode, listing numerous included sections (description, activities, fees, hours, etc.). It distinguishes from siblings by referencing nps_find_parks as the source for codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use (for trip-planning detail) and how to obtain park codes. Mentions the fields parameter to trim payload and the ten-code limit, but could more explicitly contrast with alternatives like nps_find_parks for simpler listing.
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!
Related MCP Servers
- AlicenseBqualityFmaintenanceProvides real-time information about U.S. National Parks through the NPS API, enabling users to search parks, check details, alerts, visitor centers, campgrounds, and upcoming events.641840MIT
- Alicense-qualityDmaintenanceProvides access to the National Park Service API, enabling natural language queries about parks, alerts, campgrounds, events, and more.MIT
- Alicense-qualityDmaintenanceProvides LLM context on U.S. national parks by integrating National Park Service, Recreation.gov, and weather APIs, enabling queries about park info, trails, alerts, events, weather forecasts, and more via tool calls.3MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.