What can you do with this server?

The local-dfw-mcp server connects AI clients to official public data for the Dallas–Fort Worth metroplex through 10 tools — no required API keys. * dfw_events: Find events from official city calendars (Dallas Parks & Rec, Garland, Frisco, Mesquite) plus concerts, sports, and theater via Ticketmaster (optional free API key). * dfw_311: Search City of Dallas 311 service requests by address, type (e.g., potholes, illegal dumping, animal loose), status, and date range. * dfw_crime: Look up Dallas Police Department incidents by block-level address and/or offense type (not for FCRA purposes). * dfw_fema_flood: Check any DFW address for its FEMA flood zone, SFHA status, base flood elevation, and plain-English insurance guidance. * dfw_tea_schools: Search Texas public schools by campus, district, or county with TEA A–F accountability ratings, enrollment, and demographics. * dfw_nws_alerts: Get active National Weather Service alerts (tornado, severe thunderstorm, flood, heat, freeze, etc.) for a specific DFW location. * dfw_utility_providers: Identify the certified water and sewer utility obligated to serve any DFW address using Texas PUC CCN boundary data. * dfw_district_lookup: Resolve an address to its county, City of Dallas council district and member, city-limits status, and school district (ISD). * dfw_health: Ping all upstream data providers (Dallas Open Data, FEMA, NWS, Census, PUC, etc.) to check status and latency. * about: View server version, coverage, data sources, license, and provenance.

Which integrations are available for this server?

Enables querying ArcGIS-based data sources for crime incidents, 311 service requests, and other civic data in the Dallas-Fort Worth area.

How do I use local-dfw-mcp?

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., "@local-dfw-mcp What's the flood zone for 75204?" 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.

local-dfw-mcp

by LizzleChen

Overview Schema Related Servers Score Discussions

JavaScript

Remote

local-dfw-mcp

Your AI's local guide to Dallas–Fort Worth. An open-source MCP server that connects Claude (or any MCP client) to official city, county, state, and federal data — so you can ask things like:

🎪 "What's happening in Frisco this weekend?"
🌊 "Is 1500 Marilla St in a flood zone?"
🏫 "How are the schools rated near Garland?"
🚰 "Who provides water and sewer at this address?"
🕳️ "Any potholes or illegal dumping reported on my street?"
⛈️ "Are there severe weather alerts for Dallas right now?"
🏠 "What's this house appraised at, per the county?"

Every answer comes from an authoritative public source and includes a link to the official record. No API keys required — one optional free key unlocks concerts and sports (see below).

Quick start

Add this to your MCP client config (Claude Desktop, Claude Code, etc.):

{
  "mcpServers": {
    "local-dfw": {
      "command": "npx",
      "args": ["-y", "local-dfw-mcp"]
    }
  }
}

Requires Node ≥ 20. That's it — restart your client and start asking.

Related MCP server: DataDallas MCP

What you can ask

Tool	Coverage	What it answers
`dfw_events`	see below	What's happening: official city calendars, plus concerts/sports/theater with a free Ticketmaster key
`dfw_311`	City of Dallas only	311 service requests by address/type/status
`dfw_crime`	City of Dallas (default), Fort Worth (`city: "fortworth"`), or Denton (`city: "denton"`)	Police incidents by (block-level) address / offense
`dfw_permits`	Fort Worth (default), McKinney (`city: "mckinney"`, requires `address`), or Arlington (`city: "arlington"`)	Building/development permits by street name (+ house number) or address, type, or status
`dfw_code_cases`	Fort Worth (default), McKinney (`city: "mckinney"`), or Arlington (`city: "arlington"`)	Code-compliance violations (property maintenance, high grass, zoning, etc.) by address or complaint type
`dfw_traffic`	see below	Real-time incidents (Fort Worth), street/lane closures (Dallas + Arlington, merged and labeled by city), TxDOT annual traffic counts + construction projects (4 core counties)
`dfw_fema_flood`	national	FEMA flood zone + plain-English insurance interpretation
`dfw_tea_schools`	Texas	Public schools + TEA A–F ratings (2022-23) by campus/district/county
`dfw_nws_alerts`	national	Active NWS weather alerts for a DFW point
`dfw_utility_providers`	Texas	Who provides water/sewer at an address (PUC CCN)
`dfw_district_lookup`	DFW	County, City-of-Dallas council district + member, ISD for an address
`dfw_appraisal`	Texas (4 core counties verified)	County appraisal record for an address: owner, land/improvement/market value (2025 certified roll), year built, land use, acreage
`dfw_health`	—	Pings every upstream, reports per-source status
`about`	—	Version, coverage, license, provenance

Events coverage, stated plainly

Source	Cities / scope	Key needed
Official city calendars	Dallas (Parks & Recreation calendar only — no citywide Dallas feed exists), Garland, Frisco, Mesquite, McKinney	none
Ticketmaster (concerts, sports, theater)	whole metroplex	free key, see below

Plano, Arlington, Fort Worth, Irving, and other suburbs don't publish a usable calendar feed today — the tool says "not covered" instead of guessing.

How the tools chain

There's no composed "property report" tool (yet) — there doesn't need to be. The tools share natural join keys: address, lat/lon, parcel, council district, and ISD, so your AI can chase a question across them:

Moving to a house — dfw_appraisal (what's it worth, who owns it) → dfw_fema_flood (flood zone + insurance) → dfw_district_lookup (county, council district, ISD) → dfw_tea_schools (rate that ISD's campuses) → dfw_crime (incidents nearby) → dfw_utility_providers (who to call for water/sewer).
Development watch on a block — dfw_permits (what's being built) → dfw_code_cases (violations on the same address) → dfw_311 (what neighbors are reporting).
Weekend planning — dfw_events (what's on) → dfw_traffic (incidents and closures on the way) → dfw_nws_alerts (weather worth knowing about).

Ask the composite question ("we're thinking about buying near Frisco — check schools, flood risk, and what it's appraised at") and a capable client walks the chain itself.

Optional setup

Everything works out of the box. Two free keys unlock more:

Env var	What it unlocks
`DFW_TICKETMASTER_API_KEY`	Concerts, sports, and theater in `dfw_events`. Free (5000 calls/day): https://developer.ticketmaster.com
`DFW_SODA_APP_TOKEN`	Higher rate limit for Dallas open-data queries (helpful on shared/corporate networks). Free: https://dev.socrata.com/register

Env var	Purpose
`DFW_LIMIT_<SOURCE>`	Per-upstream concurrency cap override (`SODA`, `ARCGIS`, `FEMA`, `CENSUS`, `NWS`)
`LOCAL_DFW_MCP_TIER`	`core` or `all` — trims the tool list for clients with tool caps
`DFW_CACHE_DISABLED`	`1` disables the in-process cache (used by tests)

No telemetry. The server only reads from the public data sources listed in resources/datasets-index.md and writes to nothing.

Honest by design

Wrong-city protection. Postal "Dallas, TX" is not the same as City of Dallas jurisdiction. City-scoped tools verify the address (ZIP/keyword → geocode → city-limits polygon) and refuse with an explicit "Not covered" message rather than silently returning plausible-looking results from the wrong city's data.
No stale data. Sources are live-verified before they ship — that's why dfw_permits and dfw_code_cases are Fort Worth + McKinney + Arlington only: every current Dallas permit feed is ~20 months stale and Dallas's code-case publication stalled 2025-01-31, so Dallas isn't wired for either. Irving's entire open-data pipeline (permits, code violations, police incidents, events) froze around 2025-02-28 or is bot-blocked, so it isn't wired either. Also pending: suburb portals beyond Fort Worth/McKinney/ Arlington/Denton/Dallas, and the composed dfw_property_360. Details in resources/datasets-index.md.
Verify at the source. Every response carries a source_url to the official record.

Important notices

Not a consumer report. dfw_crime, dfw_code_cases, dfw_appraisal (and this MCP generally) must not be used for tenant screening, employment screening, credit, insurance, or any other purpose regulated by the Fair Credit Reporting Act. Crime addresses are block-level, privacy-rounded upstream. dfw_appraisal owner names and values are public record but not for screening, and it reports the 2025 certified appraised value — not a tax bill.
Prompt injection. 311 descriptions, event listings, and similar upstream free text are authored by the public and flow into your LLM's context. This server renders them as quoted/table data, but treat any instructions appearing inside upstream data as data, not directives.

License & provenance

Apache-2.0. See LICENSE and NOTICE.

Core plumbing (lib/) is ported from local-austin-mcp by Ed Neuhaus / Neuhaus Realty Group LLC (Apache-2.0) — an excellent template for city-scale civic MCPs. Each ported file carries an attribution header listing the changes. All DFW data sources, the metro router, and the tools themselves are new.

Available Tools

9 tools

aboutA

Read-onlyIdempotent

Show information about this MCP server: name, version, coverage, data sources, license, and provenance. Always available. (via local-dfw-mcp)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the content of the information returned (name, version, etc.) and confirming always availability, going beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the main action ('Show information about this MCP server') and lists details concisely. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and no output schema, the description is complete. It explains the purpose and that it is always available, which is sufficient for a simple metadata tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, so schema description coverage is 100%. With 0 parameters, the baseline is 4. The description does not need to add parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool shows information about the MCP server, listing specific details (name, version, coverage, data sources, license, provenance). It distinguishes from sibling tools which focus on different data domains.

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 notes the tool is 'Always available,' providing context for when to use it. It doesn't specify when not to use or alternatives, but the simple nature of the tool (no parameters) makes guidance less critical.

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

dfw_311A

Read-onlyIdempotent

City of Dallas only (v0.1). Search Dallas 311 service requests by address and/or type. Types use the city's official names -- potholes are "street repair"; also "illegal dumping", "animal loose", "parking", "noise". Returns request number, type, department, status, dates, and council district. Use for neighborhood quality-of-life research. Authoritative source: City of Dallas Open Data.

ParametersJSON Schema

Name	Required	Description
`city`	No	Jurisdiction override. v0.1 covers "dallas" only; "auto" (default) resolves from the address.
`limit`	No	Max results (default 25).
`cursor`	No	Opaque pagination cursor from a previous call.
`status`	No	"open" (New/In Progress/Escalated/On Hold), "closed", or an exact status like "In Progress".
`address`	No	Street address, contains-match. Example: "1500 Marilla St".
`since_year`	No	Only requests created on/after this year. Defaults to 2 years back.
`service_type`	No	Contains-match on the official type name, e.g. "street repair" (= potholes), "illegal dumping", "animal loose".

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results in this page.
`query`	No	Echo of the input filters.
`offset`	No	Current page offset for pagination.
`results`	Yes	Result rows.
`nextCursor`	No	Opaque pagination cursor for the next page; null if no more results.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by stating 'City of Dallas only (v0.1)' and clarifying the city parameter semantics, which goes beyond what annotations provide. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two main sentences plus a list of examples. It is front-loaded with the core purpose, and every sentence adds value without redundancy.

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 complexity (7 parameters, output schema exists), the description covers scope, type examples, return fields, and authoritative source. It could mention pagination behavior explicitly, but with output schema present, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description enhances understanding by explaining that 'street repair' corresponds to potholes and listing other official type names. It also describes the return fields, adding value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Search Dallas 311 service requests by address and/or type', specifying the verb (Search), resource (Dallas 311 service requests), and scope. It also distinguishes itself from sibling tools (e.g., dfw_crime, dfw_health) by focusing on 311 requests for neighborhood quality-of-life research.

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 provides clear context, stating 'Use for neighborhood quality-of-life research' and noting the authoritative source. While it doesn't explicitly list when not to use or mention alternatives among siblings, the context implies it's for 311-specific queries, making it sufficient for an AI agent.

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

dfw_crimeA

Read-onlyIdempotent

City of Dallas only (v0.1). Search Dallas Police incidents by (block-level) address and/or offense type. Returns incident number, offense, date, premise, division/sector/beat, and status. Addresses are block-level (privacy-rounded upstream). NOT a consumer report — do not use for tenant, employment, or other FCRA-regulated screening. Source: Dallas Police Department Open Data.

ParametersJSON Schema

Name	Required	Description
`city`	No	Jurisdiction override. v0.1 covers "dallas" only; "auto" (default) resolves from the address.
`limit`	No	Max results (default 25).
`cursor`	No	Opaque pagination cursor from a previous call.
`address`	No	Block-level street address, contains-match. Example: "3400 Ladd St".
`offense`	No	Free-text offense filter, e.g. "burglary", "theft", "assault".
`since_date`	No	ISO date (YYYY-MM-DD); only incidents on/after it. Defaults to 90 days ago.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results in this page.
`query`	No	Echo of the input filters.
`offset`	No	Current page offset for pagination.
`results`	Yes	Result rows.
`nextCursor`	No	Opaque pagination cursor for the next page; null if no more results.

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint; description adds useful details such as block-level address rounding, source, and output fields. However, it omits pagination behavior and potential rate limits.

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?

Description is concise with four sentences, front-loads scope and action, includes necessary legal warning, and contains no redundant or wasteful text.

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 presence of output schema and annotations, the description provides sufficient context including source, privacy details, and legal restrictions, though it could mention pagination and the 'auto' city option.

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 baseline is 3. Description summarizes the main parameters (address, offense) but does not add meaning 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?

Description clearly states the tool searches Dallas Police incidents by address or offense type, distinguishes itself from sibling tools like dfw_311 and dfw_health by focusing on crime data, and specifies scope (City of Dallas only, v0.1).

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 provides context for when to use (search for Dallas crime incidents) and includes an explicit restriction (not for FCRA-regulated screening), but does not compare with sibling tools or state when not to use 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.

dfw_district_lookupA

Read-onlyIdempotent

Given a DFW street address, returns the districts/jurisdictions it falls in: county (all 4 core counties), City of Dallas council district + council member (City of Dallas only), whether it is inside City of Dallas limits, and school district (ISD). Pipeline: U.S. Census geocoder → point-in-polygon against Dallas GIS and statewide Texas ArcGIS layers.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Full street address. Example: "1500 Marilla St Dallas TX 75201".

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already indicate readOnly, idempotent, openWorld. The description adds the pipeline (U.S. Census geocoder, point-in-polygon against Dallas GIS and Texas ArcGIS layers), providing valuable behavioral context.

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: first states functionality, second explains pipeline. No unnecessary words, efficient and clear.

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?

With one parameter, no output schema, and robust annotations, the description sufficiently covers input, output contents, and data source.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter, but the description adds meaning by specifying 'DFW street address' and listing return types, aiding agent understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns districts/jurisdictions for a DFW street address, listing specific items (county, council district, limits, ISD). It distinguishes from sibling tools like dfw_crime or dfw_fema_flood.

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 for DFW address lookups but does not explicitly state when not to use or mention alternatives among sibling tools.

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

dfw_fema_floodA

Read-onlyIdempotent

Look up the FEMA flood zone for a DFW address. Returns the zone code (A, AE, X, V, VE, etc.), Special Flood Hazard Area (SFHA) status, base flood elevation, and a plain-English risk + insurance interpretation (Zone A/AE/V require federal flood insurance). Source: FEMA National Flood Hazard Layer (NFHL). Geocodes via U.S. Census.

ParametersJSON Schema

Name	Required	Description
`address`	No	Full address. Example: "1500 Marilla St Dallas TX 75201". Either address or lat+long required.
`latitude`	No
`longitude`	No

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral context: the specific fields returned, the data source (FEMA NFHL), and the geocoding method. This enriches the agent's understanding.

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, no fluff. The purpose is stated first, followed by output and source details. Every sentence adds value.

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?

The description covers purpose, output, source, and geocoding. With no output schema, it explains return values well. It could mention error handling or address format requirements, but overall it is sufficient for a read-only lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 33% schema description coverage, the description compensates by explaining that 'address' or 'latitude'+'longitude' is required and providing an example address. However, it does not describe the latitude/longitude parameters beyond what the schema offers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's verb ('Look up'), resource ('FEMA flood zone'), and scope ('for a DFW address'). It lists specific output fields, distinguishing it from sibling tools that cover other DFW services like crime or schools.

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 the tool is for DFW addresses and mentions geocoding via U.S. Census, providing context. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, which would be helpful.

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

dfw_healthA

Read-onlyIdempotent

Diagnostic. Pings every upstream data provider this MCP depends on (Dallas Open Data, data.texas.gov, FEMA NFHL, PUC CCN, Dallas GIS, Census, NWS) in parallel with a 3.5s timeout and reports per-source status, HTTP code, and latency. Use when many tools return errors to tell which provider is down vs which tool is broken.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`checks`	Yes
`summary`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds parallel pinging with a 3.5s timeout and report contents, providing useful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with two sentences that cover purpose and usage guidance with no filler words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists, the description fully covers the tool's purpose, behavior, and when to use it, leaving no gaps for its intended use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters and schema coverage is 100%. The description adds no param info, which is appropriate. Baseline score of 4 applies for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool pings upstream providers and reports status, HTTP code, and latency. It lists specific providers and distinguishes itself from sibling tools which are data retrieval tools.

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 says to use when many tools return errors to diagnose provider issues. It does not mention when not to use, but for a diagnostic tool this is sufficient.

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

dfw_nws_alertsA

Read-onlyIdempotent

Active National Weather Service alerts (severe thunderstorm, tornado, flood, heat, freeze, fire weather) for a DFW location. Defaults to downtown Dallas when no address is supplied. Returns severity, urgency, headline, area, and expiration for each active alert covering the point. Source: National Weather Service (api.weather.gov).

ParametersJSON Schema

Name	Required	Description
`lat`	No	Latitude (WGS-84). Use with lng to skip geocoding.
`lng`	No	Longitude (WGS-84). Use with lat to skip geocoding.
`address`	No	Street address to check (geocoded). Example: "1500 Marilla St Dallas TX". Defaults to downtown Dallas.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results in this page.
`query`	No	Echo of the input filters.
`offset`	No	Current page offset for pagination.
`results`	Yes	Result rows.
`nextCursor`	No	Opaque pagination cursor for the next page; null if no more results.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already provide safety and idempotency hints. Description adds valuable behavioral details: return fields (severity, urgency, etc.), data source (NWS api.weather.gov), and default location. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. Front-loaded with purpose and scope, then details on defaults and return fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given annotations, output schema, and parameter descriptions, the description covers purpose, source, default behavior, and return fields. No gaps for a simple read-only alert 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?

Schema coverage is 100% with descriptions for all 3 params. Description adds context about defaulting to downtown Dallas and lat/lng skipping geocoding, but this is minor beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description specifies verb 'returns', resource 'active NWS alerts', and location scope 'for a DFW location'. Lists alert types and distinguishes from sibling tools (e.g., dfw_fema_flood) by naming specific NWS alert categories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly states default behavior when no address is supplied (downtown Dallas) and explains optional lat/lng parameters. Although it doesn't explicitly contrast with siblings, the tool's focus on NWS alerts is distinct enough to guide selection.

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

dfw_tea_schoolsA

Read-onlyIdempotent

Texas public schools + TEA A-F accountability ratings (latest published: 2022-2023). Search by campus name, district, or county (e.g. DALLAS, TARRANT, COLLIN, DENTON). Returns overall rating, sub-scores (Student Achievement, School Progress, Closing the Gaps), enrollment, and demographics. Does NOT map an address to its assigned schools — attendance zones are managed by individual ISDs. Source: Texas Education Agency.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results (default 25).
`campus`	No	Campus name, contains-match. Example: "Booker T Washington", "Frisco HS".
`county`	No	County name. Example: "DALLAS", "TARRANT", "COLLIN", "DENTON".
`rating`	No	Filter by overall A-F rating.
`district`	No	District name, contains-match. Example: "Dallas ISD", "Frisco ISD", "Plano".
`school_type`	No	Filter by campus level.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results in this page.
`query`	No	Echo of the input filters.
`offset`	No	Current page offset for pagination.
`results`	Yes	Result rows.
`nextCursor`	No	Opaque pagination cursor for the next page; null if no more results.

TDQS

A4.4/5.0

Behavior4/5

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds data freshness (2022-2023), data source (Texas Education Agency), and the specific fields returned (overall rating, sub-scores, enrollment, demographics). It does not contradict annotations. This is good context but could mention pagination or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (5 sentences) with no waste. It front-loads the main purpose, includes essential caveats, and is well-structured. Every sentence adds value.

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 has 6 parameters and an output schema, the description covers the key return fields and limitations. It lacks information on error handling or zero-result scenarios, but with 100% schema coverage and output schema present, it is sufficiently complete for an experienced user.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by providing example values for county and campus parameters, and explains the meaning of rating filter. This enhances understanding beyond the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns Texas public school accountability ratings from TEA, with specific search criteria. It distinguishes from siblings by focusing on a unique domain (schools vs. crime, health, etc.). The verb 'search' and resource 'schools with ratings' are specific and unambiguous.

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 provides clear search categories (campus, district, county) and explicitly states what the tool does NOT do (address-to-school mapping). It includes examples for county values. However, it could explicitly contrast with sibling tools, though that is not necessary given different domains.

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

dfw_utility_providersA

Read-onlyIdempotent

Find the WATER and SEWER (wastewater) utility obligated to serve a DFW address — the 'who turns on my water' question. DFW is a patchwork of cities, MUDs/WCIDs, water-supply corporations, and private utilities. Returns the certificated (CCN) provider for the exact point. Source: Texas PUC Certificate of Convenience and Necessity boundaries. Covers all of Texas. Does NOT start service — it tells you who to contact.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Street address in DFW. Example: "6801 Warren Pkwy, Frisco TX 75034".

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint true, and destructiveHint false. The description adds that it returns the certificated provider for the exact point and clarifies it does not start service, providing extra behavioral context without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (three sentences) and front-loaded with the main purpose. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is complete. It explains the source, coverage, and what the tool returns, leaving no ambiguity.

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 and example. The tool description adds an example address but no further semantics beyond the schema. Baseline score of 3 is appropriate for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds the water and sewer utility for a DFW address, using a specific verb ('Find') and resource ('utility obligated to serve'). It distinguishes from sibling tools which cover other DFW services like crime, flood, and schools.

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 provides clear context (answering 'who turns on my water') and states what it does not do ('Does NOT start service'). However, it does not explicitly mention when not to use this tool or alternatives among siblings, though no sibling overlaps.

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.

9 tool updatesv0.1.0Jul 7, 2026
- First observedabout
- First observeddfw_311
- First observeddfw_crime
- First observeddfw_district_lookup
- First observeddfw_fema_flood
- First observeddfw_health
- First observeddfw_nws_alerts
- First observeddfw_tea_schools
- First observeddfw_utility_providers

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct domain (311, crime, districts, flood, weather, schools, utilities, health check, server info). No two tools overlap in purpose, making selection unambiguous.

Naming Consistency4/5

Eight of nine tools follow the consistent 'dfw_<descriptive_noun>' pattern. The 'about' tool breaks the pattern by lack of prefix, creating a minor inconsistency.

Tool Count5/5

9 tools is ideal for a local data server. The count covers a broad range of DFW-specific datasets without being overwhelming or sparse.

Completeness4/5

The tool set covers major DFW query needs: civic services, crime, districts, flood, weather, schools, utilities, and system health. Minor gaps exist (e.g., property data, trash pickup) but are not essential given the server's focus.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

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

mcp A
org.ungovr
Resolve any government entity worldwide and submit service requests. Open civic data for AI agents.
Government Data Open Data
121
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
mcpOAuth
ai.parceled
Real estate data for AI agents: US parcel boundaries (tiles), owners, sale history, permits, hail.
Real Estate Open Data Government Data
2
Weather & Geo Intel MCP A
io.github.selflabbs
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
Weather Services Location Services
2

Related MCP Servers

data-austin
Open Data Government Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables querying Austin, TX open data from data.austintexas.gov using the Socrata SODA API, allowing AI agents to access municipal datasets through natural language.
Updated 11 days ago (2026-08-26 16:52 UTC)
15
MIT
DataDallas MCP
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables querying Dallas open data via the Socrata SODA API, allowing access to municipal datasets through natural language.
Updated 11 days ago (2026-08-26 16:53 UTC)
14
MIT
local-houston-mcp
mindwear-capitian
A
license
A
quality
C
maintenance
Provides AI assistants with plain-English access to official Houston-area public data including weather alerts and school ratings, no API keys required.
Updated a month ago (2026-08-10 22:08 UTC)
3
1
Apache 2.0
Local Dallas MCP
mindwear-capitian
A
license
A
quality
C
maintenance
A Model Context Protocol server that provides AI assistants with plain-English access to official Dallas-area public data (weather alerts, school ratings, and 311 service requests) without requiring API keys or logins.
Updated a month ago (2026-08-10 22:08 UTC)
4
1
Apache 2.0

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/LizzleChen/local-dfw-mcp'

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