What can you do with this server?

This server provides read-only access to an excavation permit review system, enabling intelligent triage, risk analysis, and field verification planning across a portfolio of permits without direct action. * Search permits: Find pending excavation permits by street, city, applicant, project type, verdict, risk level, flagged status, or specific utility types. * Get permit details: Retrieve a complete review for a single permit, including every nearby utility line with owner, distance, ASCE 38-02 data quality grade, provenance, crossing risk, overall verdict, and lines requiring verification. * Find utility conflicts: Scan the entire portfolio to identify hazardous individual utility lines (e.g., close to excavation, poorly evidenced, or with conflicting data sources), ranked by consequence-weighted risk, with filters for distance, data quality, utility type, city, or source disagreements. * Portfolio summary: Generate aggregate statistics such as verdict distribution, risk concentration by city or project type, corroboration rates, and total unverified exposure. * Recommend field verification: Produce a prioritized potholing plan (list of lines to physically verify) for a single permit or the whole portfolio, optimized for limited field budgets. * Deep linking: All results include links to a human-facing dashboard for visual inspection of permits and utility lines. * Data provenance: Every utility line includes ASCE 38-02 quality grade and source information, enabling transparent risk assessment. Key constraints: read-only (no approval or dispatch); no authentication (runs as local user via stdio); distances are precomputed scalar values, not live GIS geometry.

How do I use Underground Utility Permit Review MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Underground Utility Permit Review MCP Server Which pending permits have unverified gas lines within 5 feet?" 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.

Underground Utility Permit Review MCP Server

by erincheong

Overview Schema Related Servers Score Discussions

JavaScript

Local

Underground Utility Permit Review — MCP Server

An MCP server that gives Claude direct, read-only access to a portfolio of pending excavation permit reviews and the underground utility lines near each one.

The permit review dashboard answers these questions for a human looking at a screen. This answers them for an agent — same data, same scoring rules, no interface.

Zero dependencies. node server.js is the entire install.

Why build this

A dashboard assumes a person sits down and browses. That works until the question is "across every permit I have open, what's about to hurt someone?" — at which point browsing twenty-four cases is the wrong shape of work.

The interesting shift is that the tools aren't a mirror of the database. There is no "conflicts" table; find_utility_conflicts exists because triage across a portfolio is a real question a reviewer asks and a screen answers badly. Designing the tool boundaries around questions rather than tables is most of the product work here.

Related MCP server: sqlens-mcp

What Claude can do with it

You:    Which pending permits have unverified gas lines within 5 feet of the dig?

Claude: [find_utility_conflicts · utility_types=["Gas line"] · max_distance_ft=5]

        Two, and both are high risk:

        Firestone Blvd. & Studebaker Rd. — 2 in gas main, 2.4 ft from the excavation,
        Level D. That's a county record with no independent verification, so the
        position is approximate and the line is well inside strike range.

        Artesia Blvd. & Carpintero Ave. — 2 in gas line at 4 ft, Level C. The county
        record and the independent detection disagree on diameter, so neither can be
        relied on until someone confirms it.

        I'd pothole both before either permit is signed.

Other things it handles well:

"Summarise my permit portfolio risk by city."
"I have one crew for one day. What should they pothole?"
"Walk me through PRM-1001 and tell me what's unresolved."
"How much of the county record have we actually corroborated?"

Install

Requires Node 18+. Nothing to npm install.

1. Point Claude Desktop at it. Edit the config file:

macOS ~/Library/Application Support/Claude/claude_desktop_config.json
Windows %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "utility-permits": {
      "command": "node",
      "args": ["/absolute/path/to/utility-mcp-server/server.js"]
    }
  }
}

The path must be absolute — Claude Desktop doesn't run from your project directory.

2. Restart Claude Desktop. Fully quit it; closing the window isn't enough.

3. Confirm. The tools appear in the tool menu. Ask "what permit tools do you have?"

The tools

Tool	The question it answers
`search_permits`	Which cases match this filter?
`get_permit`	What's the full review for this one case?
`find_utility_conflicts`	Across everything, what's dangerous to dig near?
`portfolio_summary`	How are we doing overall, and where is risk concentrated?
`recommend_verification`	Given a limited field budget, what do we pothole first?

Every tool is annotated readOnlyHint: true. Nothing here can approve a permit or dispatch a crew. That's a deliberate boundary, not an unfinished feature: an agent that can sign off on an excavation without a human in the loop is a liability, and the fastest way to lose a utility customer's trust is to build one.

Results link back into the dashboard

Every result carries a deep link to the human UI — down to the specific utility line that triggered it:

https://erincheong.github.io/permit-review-dashboard/#permit=PRM-1001&line=4&set=PRM-2008,PRM-1001&label=Gas+lines+within+5+ft

That opens the permit with the offending line already expanded and highlighted, and Back returns to the permits from the query rather than the full portfolio.

The agent is a second door onto the same data, not a replacement for it. It's good at "across everything, what's dangerous." It's bad at "let me see the county record with my own eyes." So it hands off to the thing that's good at that, and remembers where you came from.

Hash routing rather than query strings, so the links also work against a copy opened straight off the filesystem. Point them elsewhere with UTILITY_DASHBOARD_URL.

Provenance travels with every result

Every utility line comes back carrying its ASCE 38-02 quality grade, what that grade means in plain language, and where the record came from. The server's instructions tell the model to keep them attached:

A Level D record is not a known position — it is a decades-old drawing whose source disclaims any guarantee of accuracy, and treating it as fact is how people get hurt.

This matters more for an agent than for a dashboard. A human looking at a red badge infers uncertainty. A model summarising into prose will flatten "county record, unverified, position approximate" into "there's a gas line at 4 feet" unless the data fights back.

One scoring module, two surfaces

src/scoring.js holds the risk rules, and the dashboard uses the same ones. If they diverged, a reviewer and an agent could look at the same permit and disagree about whether it's safe to approve — which is worse than either being wrong alone. The test suite asserts the server's numbers for the shared corridors match what the dashboard displays.

Protocol notes

This is a dual-era server, written directly against the spec rather than an SDK.

MCP changed its negotiation model in revision 2026-07-28: instead of an initialize handshake establishing a session, every request carries its own protocol version in _meta and the server accepts or rejects each one independently. Older clients still open with initialize. This server speaks both:

Client	Flow
Modern (`2026-07-28`)	`server/discover` → `tools/call` with `_meta` on every request
Legacy (`2025-11-25`, `2025-06-18`)	`initialize` → `notifications/initialized` → `tools/call`

An unsupported version gets UnsupportedProtocolVersionError (-32022) listing what the server does support, so the client can retry instead of guessing.

Transport rule worth knowing: stdio MCP is newline-delimited JSON, and the server must write nothing to stdout that isn't a valid MCP message. A stray console.log corrupts the stream and the server appears to hang — it's the single most common way these break. All logging here goes to stderr, and there's a test asserting stdout stayed clean.

Writing the protocol by hand instead of importing the SDK was a deliberate choice: it's about 250 lines, and it means there's nothing in this repo I can't explain.

Tests

122 checks, run against a real spawned server process speaking actual JSON-RPC over stdio — nothing stubbed.

npm test          # or: node tests/verify_server.js

Covers both handshakes, version rejection, every tool's behaviour and schema conformance, error handling for unknown tools and bad arguments, malformed-JSON resilience, the rule that notifications are never answered, stdout hygiene, determinism across processes, and cross-artifact agreement with the dashboard.

The schema validator is hand-written (~30 lines) so the test suite has no dependencies either.

Data

The first six permit cases are real corridors from the LA County Substructure Grid Map (County of Los Angeles Open Data), carried over verbatim from the dashboard. The other eighteen are synthetic, generated from a fixed seed so the portfolio is big enough for search and filtering to mean something.

Every case carries a dataSource field saying which it is. An agent answering questions about this data should never have to guess whether a record is real — and neither should anyone watching a demo.

Per the county's own disclaimer, it makes no warranty as to the accuracy, timeliness, or completeness of the data, and recommends utility research be conducted under the supervision of a licensed civil engineer. That disclaimer is why county-only records are graded Level D by default.

Known limitations

No spatial geometry. Distances are precomputed scalars, not a real GIS layer. A production version sits on PostGIS and takes a bore path, not a permit ID.
Read-only by design, so there's no write path to argue about yet. When there is, it should require explicit human confirmation rather than a tool annotation.
No auth. stdio means it runs as the local user with their file permissions. A hosted version needs real per-customer access control, since permit and utility data is commercially sensitive and sometimes security-sensitive.
Consequence weights are asserted, not derived. Gas at 10× and fiber at 1× is a judgment. In a real deployment those come from the customer's own liability exposure and would differ between a gas utility and a fiber contractor.

Available Tools

5 tools

find_utility_conflictsFind hazardous unverified crossingsA

Read-onlyIdempotent

Scan the whole permit portfolio for individual utility lines that are dangerous to dig near: close to the excavation, poorly evidenced, or where the county record and the independent detection disagree. This is the cross-portfolio triage question — 'what is about to hurt someone' — rather than a per-permit lookup. Results are ranked by consequence-weighted risk.

ParametersJSON Schema

Name	Required	Description
`city`	No	Restrict to one city.
`limit`	No	Maximum results. Default 20.
`max_quality`	No	Worst acceptable data quality: 'C' returns lines graded C or D. Default 'C'.
`utility_types`	No	Utility types to scan. Defaults to hazardous types (gas, power, joint trench).
`conflicts_only`	No	Only lines where the two sources disagree.
`max_distance_ft`	No	Only lines within this distance of the excavation. Default 10.

Output Schema

ParametersJSON Schema

Name	Required	Description
`criteria`	No
`conflicts`	Yes
`matchCount`	Yes
`totalConsequenceExposure`	No

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful context: it scans the whole portfolio, considers distance, evidence quality, and disagreement between county records and independent detection, and ranks results by consequence-weighted risk.

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 efficient and front-loaded, with the main purpose in the first sentence. The second sentence adds useful positional context (cross-portfolio vs per-permit), and the third explains output ranking; while not as terse as a two-sentence ideal, there is no wasted wording.

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?

With a rich input schema, full schema coverage, and an output schema present, the description provides sufficient context for a complex portfolio-scanning tool. It explains the risk-based selection criteria and ranking approach, making the tool's behavior clear without needing to restate return values.

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?

Input schema coverage is 100%, so the baseline is 3. The description alludes to key semantics such as 'close to the excavation' (max_distance_ft) and 'where the county record and the independent detection disagree' (conflicts_only), but it does not systematically detail each parameter beyond what the schema already provides.

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 identifies the tool's purpose: scanning the entire permit portfolio for utility lines that are hazardous to dig near. It distinguishes this from per-permit lookups and emphasizes the cross-portfolio triage nature, matching the tool name and title.

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 positions this as a cross-portfolio safety-triage tool and contrasts it with per-permit lookups, giving a clear when-not-to-use signal. However, it does not name specific sibling alternatives like 'get_permit' or 'portfolio_summary', so it falls short of full explicit alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_permitGet full permit reviewA

Read-onlyIdempotent

Retrieve the complete review for one permit case: every utility line near the excavation, its owner, distance, ASCE 38-02 data quality grade, provenance, and crossing risk, plus the overall verdict and which lines need field verification before sign-off.

ParametersJSON Schema

Name	Required	Description	Default
`permit_id`	Yes	Permit ID such as PRM-1001. A street name also works if it matches exactly one case.

Output Schema

ParametersJSON Schema

Name	Required	Description
`lines`	Yes
`permit`	Yes
`verificationRequired`	No

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context about the response contents, including types of data returned and the presence of a verdict and verification list, going beyond annotation coverage.

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?

One dense, information-rich sentence that lists all key outputs without waste. It is front-loaded with the main purpose and uses a colon to introduce specifics, making it easy to parse.

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?

For a simple single-parameter read tool with full annotations and an output schema, the description thoroughly conveys what the caller will receive. It covers the complete review and even highlights the overall verdict and verification recommendations, which are likely the most important outputs.

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 already provides 100% coverage for permit_id, including an example and note about street names. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies.

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 verb 'Retrieve' and the resource 'complete review for one permit case', then enumerates the specific contents (utility lines, owners, distances, grades, verdict, verification needs). This is unambiguous and distinguishes itself from sibling tools like search_permits (searching) and portfolio_summary (aggregation).

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 a single permit's detailed review but does not explicitly state when to prefer this over alternatives. It lacks direct comparison to siblings or exclusion criteria, leaving the agent to infer context from scope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

portfolio_summarySummarise portfolio riskA

Read-onlyIdempotent

Roll up the whole permit portfolio: how many cases sit at each verdict, where the risk is concentrated by city and project type, overall record corroboration, and how much unverified consequence exposure is outstanding. Use this for 'how are we doing' questions rather than per-permit ones.

ParametersJSON Schema

Name	Required	Description	Default
`group_by`	No	Dimension to break the portfolio down by. Default 'verdict'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`totals`	Yes
`breakdown`	No
`byVerdict`	Yes
`totalPermits`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context: it aggregates across the whole portfolio and includes specific metrics, which goes beyond the annotations. It does not contradict 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?

Two sentences, front-loaded with the verb 'Roll up', and every sentence earns its place. No filler or repetition of schema details.

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?

For a simple one-parameter aggregate tool with a rich output schema and strong annotations, the description fully covers what it does and when to use it. No gaps are apparent.

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 coverage is 100% with a clear description of group_by and its default. The description mentions city and project type, which are enum values, reinforcing their meaning but not adding substantial new information 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 explicitly states the tool rolls up the entire permit portfolio and lists concrete outputs: verdict counts, risk concentration by city and project type, corroboration, and unverified consequence exposure. This clearly distinguishes it from per-permit siblings like get_permit.

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?

Directly provides usage context: "Use this for 'how are we doing' questions rather than per-permit ones." This explicitly contrasts with per-permit tools and tells the agent when to choose this tool over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recommend_verificationRecommend field verification planA

Read-onlyIdempotent

Produce a prioritised potholing plan: which specific lines should be physically exposed before excavation, in what order, and why. Ranks by consequence-weighted risk so a limited field budget is spent where a strike would cost the most. Call with a permit_id for one case, or with no arguments for a portfolio-wide plan.

ParametersJSON Schema

Name	Required	Description	Default
`max_items`	No	Cap the plan at N test holes, e.g. what a single crew can do in a day. Default 10.
`permit_id`	No	Limit the plan to one permit. Omit for a portfolio-wide plan.

Output Schema

ParametersJSON Schema

Name	Required	Description
`scope`	Yes
`planItems`	Yes
`candidateCount`	Yes
`exposureAddressed`	No
`exposureRemaining`	No

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only and non-destructive behavior. The description adds valuable context: it 'Ranks by consequence-weighted risk' and ties the plan to a limited field budget, which 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?

Three sentences cover purpose, prioritization rationale, and usage modes. Every sentence contributes information without redundancy or fluff.

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?

The description covers the tool's purpose, prioritization approach, invocation modes, and budget-cap intent. With an output schema present and annotations clarifying safety, nothing critical is missing for an agent to invoke it correctly.

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 already provides full descriptions for both parameters (100% coverage), including the 'Omit for a portfolio-wide plan' behavior that the description repeats. No new parameter meaning is added, so the baseline score of 3 applies.

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?

States clearly it 'Produce[s] a prioritised potholing plan' with explicit scope (which lines, order, why). Distinguishes from siblings by focusing on field verification planning rather than permit search or conflict finding.

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?

Explicitly describes two invocation modes: 'Call with a permit_id for one case, or with no arguments for a portfolio-wide plan.' However, it does not mention alternative tools or when not to use it, so it stops short of a perfect 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_permitsSearch permit casesA

Read-onlyIdempotent

Search and filter pending excavation permit cases. Use this to find permits by street, city, applicant, project type, permit verdict, or risk level. Returns a summary of each match, not the full utility line detail — call get_permit for that.

ParametersJSON Schema

Name	Required	Description
`city`	No	Exact city filter, e.g. 'Bellflower, CA'.
`limit`	No	Maximum results to return. Default 10.
`query`	No	Free text matched against street name, city, scope, applicant, and permit ID.
`verdict`	No	Filter by the permit's current verdict.
`min_risk`	No	Only permits at or above this crossing-risk band.
`only_flagged`	No	Only permits with at least one line flagged for field verification.
`project_type`	No	High-level project category.
`contains_utility_type`	No	Only permits with at least one line of this utility type near the excavation.

Output Schema

ParametersJSON Schema

Name	Required	Description
`permits`	Yes
`matchCount`	Yes
`totalPermits`	Yes
`filtersApplied`	No

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint=true and destructiveHint=false already in annotations, the description adds scope ('pending') and return shape ('summary of each match, not the full utility line detail'). It doesn't discuss rate limits or side effects, but annotations cover the safety profile, so this is adequate.

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?

Two sentences, front-loaded purpose, then usage, then a pointer to get_permit. Every clause earns its place; no filler.

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?

The tool is a search/filter operation with no required params and an output schema, so the description doesn't need to explain return structure. It covers the main purpose, the pending-case scope, and directs to get_permit for deeper detail. This is fully sufficient for an agent to select and invoke the tool.

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?

All 8 parameters have descriptions in the schema (100% coverage), and the description merely restates a few filter criteria without adding new semantics. The schema already explains query, verdict, min_risk, etc., so the description adds marginal value.

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 a specific verb+resource ('Search and filter pending excavation permit cases') and lists concrete search dimensions (street, city, applicant, project type, permit verdict, risk level). It also distinguishes itself from the sibling get_permit by noting it returns summaries rather than full detail.

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 says 'Use this to find permits by...' and provides an alternative path for full detail with 'call get_permit for that.' This gives clear when-to-use and a named alternative, though it doesn't contrast with the other sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool addresses a distinct question: per-permit search and retrieval, cross-portfolio risk triage, portfolio-wide summary, and prioritized verification planning. Even search_permits and find_utility_conflicts are clearly separated by intent (query-based vs risk-based scanning).

Naming Consistency4/5

Four of five tools use a clear verb_noun pattern (search_permits, get_permit, find_utility_conflicts, recommend_verification), but portfolio_summary breaks the pattern by using a noun_noun structure instead of something like summarize_portfolio. This is a minor deviation.

Tool Count5/5

Five tools is ideal for this domain. Each tool has a unique role and the count is not excessive or sparse; the server is well-scoped to the permit review workflow.

Completeness5/5

The tool surface covers the full read/analysis lifecycle: search (search_permits), detail (get_permit), cross-cutting risk (find_utility_conflicts), roll-up (portfolio_summary), and actionable recommendation (recommend_verification). There are no obvious dead ends or missing operations for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Dataassist-IO
io.github.DataAssistIO
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Search Databases
2
Permit Verdicts A
io.github.okwithit9-debug
Building-permit verdicts by address, with cited records. SF, Seattle, Austin, NYC. Pay per call.
Government Data Search Open Data
101
mcpmyadmin
ai.mcpmyadmin
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Databases Security
2
brandonbosco-sigao-scf-mcpOAuth
ai.smithery
Provides access to Civic Plus - See Click Fix, allowing you to interact with your data via an LLM.…
Government Data Open Data App Automation
2

Related MCP Servers

ServiceTitan MCP Server
CRM ERP Systems
jrhoades1
F
license
Not graded
quality
D
maintenance
Enables Claude Desktop to query ServiceTitan data about technician jobs and business performance via natural language, while protecting customer personal information.
Updated 5 months ago (2026-03-19 21:02 UTC)
sqlens-mcp
Databases Developer Tools
dicoy
A
license
A
quality
C
maintenance
Provides Claude with read-only access to local development databases (Postgres, MySQL, SQLite) to inspect schemas, run SELECT queries, and explain query plans without leaving the conversation.
Updated 2 months ago (2026-07-02 01:32 UTC)
5
MIT
DC Hub
Energy Open Data Research & Data
azmartone67
A
license
Not graded
quality
B
maintenance
Connects Claude to live data-center, power & grid intelligence data, enabling query and citation of over 21,000 facilities, power markets, grid telemetry, and more.
Updated 2 months ago (2026-07-17 20:40 UTC)
MIT
BackCrew FieldRoutes MCP
CRM Customer Data Platforms
jayson-svg
A
license
A
quality
B
maintenance
Enables AI assistants like Claude to read and optionally write data in FieldRoutes (formerly PestRoutes) using plain English, with read-only mode by default and granular safety profiles.
Updated a month ago (2026-07-22 15:31 UTC)
39
MIT

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/erincheong/utility-permit-mcp-server'

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