National Parks MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting different aspects of national park information: searching parks, getting alerts, campgrounds, events, park details, and visitor centers. There is no overlap in functionality, making tool selection straightforward for an agent.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern with 'get' or 'find' prefixes (e.g., getAlerts, findParks), but there is a minor deviation with 'findParks' using 'find' instead of 'get', and all tools use camelCase consistently. This slight inconsistency is minor and does not hinder readability.
Tool Count5/5
With 6 tools, the server is well-scoped for providing national park information. Each tool serves a distinct and useful purpose, covering key areas like search, alerts, amenities, events, details, and visitor centers without being overly broad or sparse.
Completeness4/5
The tool set covers most core aspects of national park information, including search, alerts, amenities, events, details, and visitor centers. A minor gap might be the lack of tools for booking or reservation-related operations, but the existing tools support comprehensive querying and information retrieval for the domain.
Average 3.1/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'Get' operation (implying read-only) but doesn't disclose important behavioral traits like whether it requires authentication, rate limits, pagination behavior beyond the 'start' parameter, or what format the alerts are returned in. The description is too minimal for a tool with 4 parameters and no output schema.
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?
The description is a single, efficient sentence that states the core purpose upfront. There's no wasted verbiage or unnecessary elaboration. However, it could be slightly more structured by separating purpose from content types for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'current' means (real-time? cached?), doesn't describe the return format or structure, and provides minimal behavioral context. The description should do more to compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no parameter-specific information beyond what's in the schema - it doesn't explain relationships between parameters or provide usage examples. With complete schema coverage, the baseline is 3 even without additional param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'current alerts for national parks' with specific content types 'closures, hazards, and important information'. It distinguishes from sibling tools like getParkDetails or getEvents by focusing on alerts rather than general park information or events. However, it doesn't explicitly differentiate from all siblings (e.g., getCampgrounds is clearly different).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when alerts might be needed (e.g., for trip planning, safety checks) or when other tools like getParkDetails might be more appropriate for general information. There's no explicit when/when-not guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets information,' implying a read-only operation, but doesn't clarify if it's safe, requires authentication, has rate limits, or what the output format looks like. For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding its behavior.
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?
The description is a single, clear sentence that efficiently conveys the core purpose. It's front-loaded with the main action and resource, with no unnecessary words. However, it could be slightly more structured by including brief usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what information is returned (e.g., campground names, locations, amenities details), how results are structured, or any behavioral traits like pagination or error handling. This makes it inadequate for an agent to fully understand the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description doesn't add any parameter-specific details beyond what's in the schema, such as examples or usage tips. However, it implies filtering by amenities, which isn't directly covered in the schema, adding minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: 'Get information about available campgrounds and their amenities.' It specifies the verb ('Get') and resource ('campgrounds'), and adds value by mentioning 'amenities' which isn't obvious from the name. However, it doesn't explicitly differentiate from sibling tools like 'findParks' or 'getParkDetails,' which might also provide campground information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'findParks' or 'getParkDetails,' which could overlap in functionality. There's no context about prerequisites, such as needing park codes, or when to choose this over other tools for campground-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Find' suggests a read-only operation, it doesn't specify permissions, rate limits, pagination behavior beyond the 'start' parameter, or what the return format looks like (e.g., list of events with details). For a tool with 6 parameters and no annotations, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to grasp immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error handling, or behavioral traits like pagination or filtering nuances, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear details for all 6 parameters (e.g., parkCode format, limit defaults, date formats). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for adequate but not enhanced coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find') and target resource ('upcoming events at parks'), which is specific and understandable. However, it doesn't differentiate this tool from potential sibling tools like 'getAlerts' or 'getCampgrounds' that might also involve park-related queries, missing an opportunity for clearer distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'findParks' or 'getParkDetails', nor does it mention prerequisites or exclusions. It implies usage for finding events but lacks explicit context about when this is the appropriate choice among the available tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving information and operating hours, but lacks details on permissions, rate limits, error handling, or response format. For a read operation with no annotation coverage, this is insufficient.
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 a single, efficient sentence that front-loads the core purpose without unnecessary details. It is appropriately sized for a simple retrieval tool, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks behavioral context and usage guidance. Without an output schema, it should ideally hint at the return structure, but this is not critical for a basic read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description does not add any meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: 'Get information about visitor centers and their operating hours.' It specifies the verb ('Get') and resource ('visitor centers'), but does not differentiate from sibling tools like 'getParkDetails' or 'getCampgrounds' that might also provide visitor center information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention sibling tools or contexts where other tools might be more appropriate, such as using 'getParkDetails' for broader park information or 'findParks' for locating parks themselves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions search functionality but fails to describe key traits: whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior (beyond the 'start' parameter in schema), or the format/scope of results. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that front-loads the core purpose ('Search for national parks') and succinctly lists criteria. There is no wasted text, repetition, or unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects (e.g., safety, performance) or result format, which are critical for a search tool. While the schema covers parameters well, the overall context for agent decision-making is insufficient, especially compared to siblings that may have overlapping domains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed documentation for all 5 parameters (e.g., stateCode format, limit defaults, activities filtering). The description adds minimal value beyond the schema, only listing criteria types ('state, name, activities, or other criteria') without explaining syntax or interactions. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('search') and resource ('national parks'), and specifies the search criteria ('based on state, name, activities, or other criteria'). It distinguishes from siblings like getParkDetails (which retrieves details for a specific park) by focusing on search/filtering. However, it doesn't explicitly contrast with getAlerts or getEvents, which might also involve parks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching parks with various filters, but provides no explicit guidance on when to use this tool versus alternatives like getParkDetails (for detailed info on a known park) or getCampgrounds (for campground-specific data). It lacks clear exclusions or prerequisites, leaving the agent to infer context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't specify aspects like rate limits, authentication needs, error handling, or what 'detailed information' entails (e.g., format, fields). For a tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, clear sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, or usage context beyond implied distinctions. With no output schema, it should ideally hint at return values, but the simplicity keeps it from being incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'parkCode' well-documented in the schema (including examples like 'yose' and 'grca'). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 without compensating for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a specific national park', making the purpose evident. It distinguishes from siblings like 'findParks' (which likely lists multiple parks) by focusing on a single park's details. However, it doesn't explicitly contrast with other siblings like 'getAlerts' or 'getCampgrounds', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when detailed info for a specific park is needed, as opposed to 'findParks' for broader searches. However, it lacks explicit guidance on when to use this tool versus alternatives like 'getAlerts' or 'getVisitorCenters', and no exclusions or prerequisites are mentioned. This leaves some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-nationalparks MCP server](https://glama.ai/mcp/servers/KyrieTangSheng/mcp-server-nationalparks/badges/card.svg)](https://glama.ai/mcp/servers/KyrieTangSheng/mcp-server-nationalparks)

Score Badge

Copy to your README.md:

[![mcp-server-nationalparks MCP server](https://glama.ai/mcp/servers/KyrieTangSheng/mcp-server-nationalparks/badges/score.svg)](https://glama.ai/mcp/servers/KyrieTangSheng/mcp-server-nationalparks)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/KyrieTangSheng/mcp-server-nationalparks'

If you have feedback or need assistance with the MCP directory API, please join our Discord server