dfwmetro-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DFWMETRO_MCP_URL | No | Override the remote endpoint (testing only). | https://dfwmetro.net/mcp |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| submit_listingA | Submit a DFW service business to the dfwmetro.net verified directory. The business MUST be genuinely online-bookable: booking_url must point at a real scheduling flow (date/time picker or booking widget) — quote forms, contact forms, phone-only, and login-gated flows fail verification. You do not need to categorize it yourself: describe what the business does in 'description' and the trade is assigned automatically (send 'trade' only if you are sure of the category id). Find the business's real street address BEFORE submitting — check its website (footer/contact page) or the JSON-LD LocalBusiness block on its site or booking page — and send it as 'street_address': it drives the exact map pin. When the trade requires a state license (plumbing, electrical, HVAC, personal & specialty services), also send 'license_number' (e.g. 'TACLA40925C', 'TECL 12345', 'M-12345') — the server pre-checks the format and the human desk verifies it against the state registry. You may also send 'starting_price_cents' (integer cents, e.g. 8500 = $85.00, shown publicly as 'from $X') and 'price_note' (short qualifier, e.g. 'per visit'). Accepted submissions start as NOT_YET_VERIFIED and pass human review before going live. |
| find_verified_listingsA | Find VERIFIED service businesses in the dfwmetro.net directory for booking. Only listings that passed human verification-desk review are returned — this tool can never surface unverified businesses and can never change verification status. Each result includes the business's booking_url plus machine-booking capability and endpoint health when known. Use booking_url for human-style booking flows; use capability endpoints only when present. Kept for backward compatibility; new integrations should prefer find_listings with verified_only:true. |
| find_listingsA | Find service businesses in the dfwmetro.net directory for booking. Returns every listing with its verification status labeled: VERIFIED businesses (human verification-desk reviewed) rank first and carry machine-booking capability and endpoint health; NOT_YET_VERIFIED businesses are clearly labeled, ranked by automated pre-check score, and carry machine_ready:false. Pass verified_only:true for the strict VERIFIED-only shelf. This tool can never change verification status. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
submit_listing is clearly distinct from the two search tools, but find_verified_listings is fully subsumed by find_listings (the description itself says it's kept only for backward compatibility and recommends find_listings with verified_only:true). The descriptions do explicitly call out the relationship, which mitigates but does not eliminate misselection risk between the two finders.
All three tools follow a clean verb_noun snake_case pattern: submit_listing, find_verified_listings, find_listings. The find_ prefix is applied predictably and no conventions are mixed.
Three tools is thin for a directory service, and effectively only two distinct capabilities exist since find_verified_listings duplicates a mode of find_listings. The scope is narrow enough that it is defensible, but it sits at the borderline of under-provisioned.
Submit plus search covers the core loop, but there is no way to retrieve a single listing by id, no explicit status-check for a submission the caller just made, and no update/correct path despite submissions starting as NOT_YET_VERIFIED. Agents can partially work around this by filtering find_listings, but there are notable dead ends.