Skip to main content
Glama
stringtheoryaccelerator

Maine Burn Permit MCP Server

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:

  1. Check Fire Danger - Retrieves current fire danger ratings for Maine towns from the Maine Fire Weather system

  2. 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:

  1. Open your Claude Desktop config file:

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Windows: %APPDATA%\Claude\claude_desktop_config.json

  2. Add this configuration:

    {
      "mcpServers": {
        "maine-burn-permit": {
          "command": "npx",
          "args": ["-y", "github:yourusername/publicmcp"]
        }
      }
    }
  3. Restart Claude Desktop

  4. 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

  1. Clone the repository:

git clone <repository-url>
cd publicmcp
  1. Install dependencies:

npm install
  1. Build the TypeScript project:

npm run build

Usage

Starting the Server

Run the MCP server:

npm start

The 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 dev

Deploying to GitHub

To make your MCP server available via GitHub for easy distribution:

  1. Update the repository URL in package.json:

    Replace yourusername with your actual GitHub username:

    "repository": {
      "type": "git",
      "url": "https://github.com/yourusername/publicmcp.git"
    }
  2. 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 main
  3. Tag 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 dist folder is in .gitignore and won't be committed to GitHub

  • This is intentional! When users install from GitHub via npx, the prepare script automatically runs npm run build

  • This ensures the TypeScript is compiled fresh for each installation

  • Keep dist in .gitignore for 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.json

  • Windows: %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.json must include a bin field or start script (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.js

From GitHub:

npx -y github:yourusername/publicmcp

Example 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 occur

  • address (string, required): Physical address of the burn site

  • city (string, required): City of the applicant's address

  • state (string, optional): State of the applicant's address (default: "ME")

  • zip (string, required): Zip code

  • dob (string, required): Date of Birth in MM/DD/YYYY format

  • material (string, required): Material to be burned

    • Options: "Brush", "Wood Debris", "Agricultural", "Campfire"

  • applicantName (string, required): Full name of the applicant

  • phone (string, required): Phone number (e.g., 207-555-1234)

  • email (string, required): Email address

  • burnLocation (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.md

Technical 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

  1. MCP Server: The main server (src/index.ts) implements the Model Context Protocol, exposing tools via stdio transport

  2. Tool Handlers: Each tool uses Puppeteer to interact with Maine government websites

  3. Validation: Zod schemas ensure input parameters are valid before processing

  4. 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-browser

Network 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 tools
apply_for_burn_permitApply for Burn PermitB

Automates the process of applying for a Maine open burn permit.

ParametersJSON Schema
NameRequiredDescriptionDefault
townYesTown where burning will occur
addressYesPhysical address of the burn (and applicant's home address)
cityYesCity of the applicant's address
stateNoState of the applicant's addressME
zipYesZip code
dobYesDate of Birth (MM/DD/YYYY)
materialYesMaterial to be burned
applicantNameYesFull name of the applicant
phoneYesPhone number (e.g., 207-555-1234)
emailYesEmail address
burnLocationYesDescription of burn location on property

Output Schema

ParametersJSON Schema
NameRequiredDescription
messageYes
successYes
permitNumberYes

TDQS

B3.1/5.0
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 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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

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: '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.

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 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
townYesThe name of the town to check fire danger for

Output Schema

ParametersJSON Schema
NameRequiredDescription
noteYes
zoneIdYes
humidityYes
windSpeedYes
stationNameYes
temperatureYes
burningIndexYes
fireMoisture1hrYes
fireMoisture10hrYes
fireMoisture100hrYes

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/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 (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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 2 tool updates
    • First observedapply_for_burn_permit
    • First observedcheck_fire_danger

TDQS

B3.4/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness2/5

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

ActivityInactive
ResponsivenessSyncing

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

Related MCP Servers

Latest Blog Posts

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