Maine Burn Permit MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Maine Burn Permit MCP Servercheck fire danger in Portland and apply for a burn permit"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Maine Burn Permit MCP Server
A Model Context Protocol (MCP) server that provides automated tools for checking fire danger levels and applying for burn permits in Maine.
Overview
This MCP server exposes two main tools:
Check Fire Danger - Retrieves current fire danger ratings for Maine towns from the Maine Fire Weather system
Apply for Burn Permit - Automates the process of applying for an open burn permit through Maine's official burn permit system
Related MCP server: Weather MCP Server
Features
š„ Real-time fire danger monitoring for Maine locations
š Automated burn permit application submission
š¤ Model Context Protocol integration for AI assistant compatibility
š Web scraping using Puppeteer for up-to-date information
ā Input validation using Zod schemas
Quick Start (Using from GitHub)
The fastest way to use this MCP server with Claude Desktop:
Open your Claude Desktop config file:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Add this configuration:
{ "mcpServers": { "maine-burn-permit": { "command": "npx", "args": ["-y", "github:yourusername/publicmcp"] } } }Restart Claude Desktop
Start asking about fire danger or burn permits in Maine!
That's it! No local installation needed.
Prerequisites
Node.js (v18 or higher recommended)
npm or yarn
Chrome/Chromium (for Puppeteer)
Installation
Clone the repository:
git clone <repository-url>
cd publicmcpInstall dependencies:
npm installBuild the TypeScript project:
npm run buildUsage
Starting the Server
Run the MCP server:
npm startThe server will start and communicate via stdio, making it compatible with MCP clients.
Development Mode
For development with auto-rebuild on file changes:
npm run devDeploying to GitHub
To make your MCP server available via GitHub for easy distribution:
Update the repository URL in
package.json:Replace
yourusernamewith your actual GitHub username:"repository": { "type": "git", "url": "https://github.com/yourusername/publicmcp.git" }Commit and push to GitHub:
git init git add . git commit -m "Initial commit" git remote add origin https://github.com/yourusername/publicmcp.git git push -u origin mainTag a release (optional but recommended):
git tag v1.0.0 git push origin v1.0.0
Once pushed to GitHub, anyone can use your MCP server without cloning it locally!
Note about the dist folder:
The
distfolder is in.gitignoreand won't be committed to GitHubThis is intentional! When users install from GitHub via npx, the
preparescript automatically runsnpm run buildThis ensures the TypeScript is compiled fresh for each installation
Keep
distin.gitignorefor cleaner version control
Connecting to an MCP Client
Claude Desktop Configuration
To use this MCP server with Claude Desktop, add it to your Claude Desktop configuration file:
Location:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Configuration:
{
"mcpServers": {
"maine-burn-permit": {
"command": "node",
"args": ["/Users/wolfbird/dev/publicmcp/dist/index.js"]
}
}
}Replace /Users/wolfbird/dev/publicmcp with the actual path to your project directory.
After updating the configuration, restart Claude Desktop.
Serving Directly from GitHub
You can also configure Claude Desktop to run this MCP server directly from GitHub without cloning the repository locally. This approach automatically uses the latest version from the repository.
Configuration using npx:
{
"mcpServers": {
"maine-burn-permit": {
"command": "npx",
"args": [
"-y",
"github:yourusername/publicmcp"
]
}
}
}Replace yourusername/publicmcp with the actual GitHub repository path (e.g., wolfbird/publicmcp).
Benefits of GitHub deployment:
ā No local installation required
ā Automatically uses the latest version
ā Easier to share with others
ā Consistent environment across users
Requirements:
The repository must be public, or you need GitHub authentication configured
Your
package.jsonmust include abinfield orstartscript (already configured)Node.js and npm must be installed locally
Alternative: Using a specific version/branch
To use a specific branch or commit:
{
"mcpServers": {
"maine-burn-permit": {
"command": "npx",
"args": [
"-y",
"github:yourusername/publicmcp#main"
]
}
}
}Or a specific release tag:
{
"mcpServers": {
"maine-burn-permit": {
"command": "npx",
"args": [
"-y",
"github:yourusername/publicmcp#v1.0.0"
]
}
}
}Using with Other MCP Clients
Any MCP-compatible client can connect to this server via stdio. Configure your client to run:
Local installation:
node /path/to/publicmcp/dist/index.jsFrom GitHub:
npx -y github:yourusername/publicmcpExample Usage
Once configured, you can interact with the tools through your MCP client. Here are some example conversations:
Example 1: Check Fire Danger
You: "What's the current fire danger in Augusta, Maine?"
Claude (using check_fire_danger tool):
Fire Weather Data for Augusta (Zone 23):
Burning Index: 15
Fire Moisture (1-hr): 12%
Fire Moisture (10-hr): 15%
Fire Moisture (100-hr): 18%
Weather: 65°F, RH 45%, Wind 5 mph
Note: Please verify the official Class Day (Low/Moderate/High) on the main map...Example 2: Apply for Burn Permit
You: "I need to apply for a burn permit. My name is John Smith, I live at 123 Main Street, Augusta, ME 04330. My phone is 207-555-1234, email is john@example.com. I want to burn brush piles on my property behind the barn. My date of birth is 01/15/1980."
Claude (using apply_for_burn_permit tool):
Permit Application Successful! Permit Number: 123456.
Please download the permit from the provided link or save the confirmation page.Example 3: Complete Workflow
You: "I want to burn some brush in Portland. Can you check if it's safe and help me get a permit?"
Claude: First checks fire danger for Portland, then if conditions are appropriate, helps gather the required information and submits the permit application.
Available Tools
1. Check Fire Danger
Check the current fire danger rating for a specific Maine town.
Tool Name: check_fire_danger
Input Parameters:
town(string, required): The name of the town to check fire danger for
Example Response:
Fire Weather Data for Augusta (Zone 23):
Burning Index: 15
Fire Moisture (1-hr): 12%
Fire Moisture (10-hr): 15%
Fire Moisture (100-hr): 18%
Weather: 65°F, RH 45%, Wind 5 mph
Note: Please verify the official Class Day (Low/Moderate/High) on the main map...2. Apply for Burn Permit
Automates the process of applying for a Maine open burn permit.
Tool Name: apply_for_burn_permit
Input Parameters:
town(string, required): Town where burning will occuraddress(string, required): Physical address of the burn sitecity(string, required): City of the applicant's addressstate(string, optional): State of the applicant's address (default: "ME")zip(string, required): Zip codedob(string, required): Date of Birth in MM/DD/YYYY formatmaterial(string, required): Material to be burnedOptions: "Brush", "Wood Debris", "Agricultural", "Campfire"
applicantName(string, required): Full name of the applicantphone(string, required): Phone number (e.g., 207-555-1234)email(string, required): Email addressburnLocation(string, required): Description of burn location on property
Example Response:
Permit Application Successful! Permit Number: 123456.
Please download the permit from the provided link or save the confirmation page.Project Structure
publicmcp/
āāā src/
ā āāā index.ts # Main MCP server setup
ā āāā tools/
ā ā āāā applyPermit.ts # Burn permit application tool
ā ā āāā fireDanger.ts # Fire danger checking tool
ā āāā test_apply_permit.ts # Test script for permit application
ā āāā test_fire_danger.ts # Test script for fire danger check
āāā dist/ # Compiled JavaScript output
āāā package.json
āāā tsconfig.json
āāā README.mdTechnical Details
Technologies Used
@modelcontextprotocol/sdk: Official MCP SDK for building MCP servers
Puppeteer: Headless browser automation for web scraping
Zod: TypeScript-first schema validation
TypeScript: Type-safe development
How It Works
MCP Server: The main server (
src/index.ts) implements the Model Context Protocol, exposing tools via stdio transportTool Handlers: Each tool uses Puppeteer to interact with Maine government websites
Validation: Zod schemas ensure input parameters are valid before processing
Error Handling: Comprehensive error handling with user-friendly error messages
Important Notes
ā ļø Legal and Safety Disclaimer
This tool automates access to public Maine government websites
Always verify permit details and fire danger ratings manually
Follow all local regulations and burn restrictions
Burn permits are subject to approval and weather conditions
The user is responsible for safe burning practices
Troubleshooting
Puppeteer Issues
If Puppeteer fails to launch Chrome:
# On Linux, you may need to install additional dependencies
sudo apt-get install chromium-browserNetwork Errors
The tools require internet access to:
Ensure your network allows access to these domains.
Contributing
Contributions are welcome! Please feel free to submit pull requests or open issues for bugs and feature requests.
License
ISC
Acknowledgments
Maine Forest Service for providing the burn permit system
Maine Fire Weather for fire danger data
Model Context Protocol community
Support
For issues or questions, please open an issue on the GitHub repository.
Available Tools
2 toolsapply_for_burn_permitApply for Burn PermitB
Automates the process of applying for a Maine open burn permit.
| Name | Required | Description | Default |
|---|---|---|---|
| town | Yes | Town where burning will occur | |
| address | Yes | Physical address of the burn (and applicant's home address) | |
| city | Yes | City of the applicant's address | |
| state | No | State of the applicant's address | ME |
| zip | Yes | Zip code | |
| dob | Yes | Date of Birth (MM/DD/YYYY) | |
| material | Yes | Material to be burned | |
| applicantName | Yes | Full name of the applicant | |
| phone | Yes | Phone number (e.g., 207-555-1234) | |
| Yes | Email address | ||
| burnLocation | Yes | Description of burn location on property |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| success | Yes | |
| permitNumber | Yes |
TDQS
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 the tool 'automates the process' but doesn't clarify whether this is a read-only check or an actual submission that creates a permit, what permissions are needed, whether it's rate-limited, what happens on success/failure, or what the output contains. For a tool with 11 parameters that likely submits data, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the 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 that there's an output schema (though not shown), the description doesn't need to explain return values. However, for a complex tool with 11 parameters and no annotations, the description should provide more behavioral context about what the tool actually does (submission vs. simulation, authentication needs, etc.). The single sentence is adequate but leaves significant 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?
The schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly with descriptions, required status, enums, and formats. The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Automates the process of applying for a Maine open burn permit.' It specifies the action (apply for) and resource (burn permit), though it doesn't explicitly differentiate from the sibling tool 'check_fire_danger' beyond the different action verbs.
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 no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'check_fire_danger' or explain when an application is appropriate versus checking fire danger conditions. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_fire_dangerCheck Fire DangerA
Checks the current fire danger rating for a specific town in Maine to see if burning is allowed.
| Name | Required | Description | Default |
|---|---|---|---|
| town | Yes | The name of the town to check fire danger for |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| zoneId | Yes | |
| humidity | Yes | |
| windSpeed | Yes | |
| stationName | Yes | |
| temperature | Yes | |
| burningIndex | Yes | |
| fireMoisture1hr | Yes | |
| fireMoisture10hr | Yes | |
| fireMoisture100hr | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the purpose and outcome ('see if burning is allowed') but lacks details on behavioral traits such as data sources, update frequency, error handling, or authentication needs, which are important for a tool checking real-time danger ratings.
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-structured sentence that efficiently conveys the tool's purpose, scope, and intended use without any redundant or unnecessary information, making it highly concise and front-loaded.
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 low complexity (one parameter, no annotations, but with an output schema), the description is mostly complete. It covers the core purpose and usage intent, but could benefit from more behavioral context (e.g., data freshness, limitations) to fully compensate for the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the 'town' parameter. The description adds minimal value beyond the schema by implying the town is in Maine, but it does not provide additional semantics like format examples or constraints, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Checks'), resource ('current fire danger rating'), and scope ('for a specific town in Maine'), distinguishing it from the sibling tool 'apply_for_burn_permit' which is about applying for permits rather than checking ratings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'to see if burning is allowed,' which helps understand when to use this tool. However, it does not explicitly state when not to use it or mention alternatives like the sibling tool, leaving some guidance gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
- First observed
apply_for_burn_permit - First observed
check_fire_danger
TDQS
The two tools have clearly distinct purposes: one is for applying for a permit, and the other is for checking fire danger conditions. There is no overlap or ambiguity between them, making it easy for an agent to select the correct tool based on the task.
Both tools follow a consistent verb_noun pattern (apply_for_burn_permit and check_fire_danger), using snake_case and descriptive action-oriented names. This consistency aids in predictability and readability.
With only two tools, the server feels thin for its apparent scope of managing burn permits in Maine. Key operations like checking permit status, updating permits, or canceling permits are missing, which limits functionality and may require workarounds.
The tool set is severely incomplete for a burn permit management domain. It lacks essential CRUD operations such as viewing existing permits, updating permit details, or canceling permits, leaving significant gaps that could cause agent failures in real-world workflows.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Wildfire events and aggregates across global, U.S., and Canada sources. Paid via x402 USDC.
US outdoor recreation: 37k+ trails, 30k+ campgrounds, parks, weather + wildfire safety. Read-only.
Campground discovery, availability, planning, and booking handoffs across US public lands.
EPA AirNow MCP ā official US real-time AQI + forecast (free key)
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables AI assistants to access real-time US weather forecasts and alerts through the National Weather Service API.221MIT
- FlicenseNot gradedqualityDmaintenanceEnables users to get weather forecasts and alerts for any US city and state through natural language queries using the National Weather Service API.-
- FlicenseNot gradedqualityDmaintenanceDetects, monitors, and analyzes potential wildfires globally using NASA FIRMS, OpenWeatherMap, and Google Earth Engine data.1-
- AlicenseNot gradedqualityDmaintenanceEnables fetching weather alerts for US states and detailed 7-day forecasts for any US location via the National Weather Service API.80GPL 3.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/stringtheoryaccelerator/publicmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server