Skip to main content
Glama

dfwmetro.net directory

submit_listing

Idempotent

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "legal_name": "<legal_name>",
      "city": "<city>",
      "booking_url": "<booking_url>"
    },
    "name": "submit_listing"
  }
}

Input Schema

NameRequiredDescriptionDefault
dbaNoTrade/DBA name shown publicly. Defaults to legal_name.
cityYesDFW city, e.g. 'Plano'.
phoneNoThe business's public phone number. The verification desk runs an automated phone pre-check on it.
tradeNoOPTIONAL. Category id from https://dfwmetro.net/categories.json (e.g. 'plumbing', 'electrical', 'personal_specialty'). Pre-v2 ids (e.g. 'nail-salon') are accepted and stored as their v2 industry. If omitted, the server assigns the trade from your description — you do not need to get this right yourself.
websiteNoThe business's main website URL — not the booking page (that is booking_url). The verification desk runs an automated website pre-check on it.
zip_codeNoThe business's ZIP code, e.g. '75024'.
legal_nameYesLegal business name.
price_noteNoOPTIONAL. Short qualifier shown next to the starting price, e.g. 'per visit', 'up to shoulder length'.
booking_urlYesREQUIRED. Direct URL of the business's real online scheduling flow (date/time picker or booking widget). Generic contact/quote forms, phone-only, and login-gated flows fail verification — do not submit them.
descriptionNoWhat the business DOES, in plain words (e.g. 'mobile piano tuning, in-home appointments'). Used to categorize the listing when trade is omitted, and shown to the verification desk. The more specific, the better the categorization.
service_areaNoDefaults to 'DFW'.
submitted_byNoAgent identifier, e.g. 'agent:my-booking-bot'. Defaults to 'agent:unknown'.
subcategoriesNoMust match the trade's subcategory labels in categories.json.
license_numberNoSTRONGLY RECOMMENDED when the trade requires a state license (plumbing, electrical, HVAC, personal & specialty services). The trade's license number, e.g. 'TACLA40925C' (HVAC), 'TECL 12345' (electrical), 'M-12345' (plumbing). The server checks the format against the Texas pattern; the human desk verifies it against the state registry before VERIFIED.
street_addressNoSTRONGLY RECOMMENDED. The business's real street address, e.g. '2818 Satsuma Drive'. Find it on the business's website (footer / contact page) or in the JSON-LD LocalBusiness block on its site or booking page BEFORE submitting. It drives the exact map pin; without it the listing gets only a city-level dot. Not required — submissions without it are still accepted.
years_in_businessNoHow long the business has been operating, in whole years.
license_type_detailNoFree-text license detail, e.g. 'Master Plumber' or 'Class A ACR Contractor'. Shown to the verification desk alongside license_number.
starting_price_centsNoOPTIONAL. Starting price in cents, e.g. 8500 = $85.00. Shown publicly as 'from $X'. Omit when pricing varies too much to quote a starting point.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / phone / description
      Added value: +"The business's public phone number. The verification desk runs an automated phone pre-check on it."
    • addedInput schema / properties / website / description
      Added value: +"The business's main website URL — not the booking page (that is booking_url). The verification desk runs an automated website pre-check on it."
    • addedInput schema / properties / years_in_business / description
      Added value: +"How long the business has been operating, in whole years."
    • addedInput schema / properties / zip_code / description
      Added value: +"The business's ZIP code, e.g. '75024'."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: accepted submissions start as NOT_YET_VERIFIED and pass human review, license format is pre-checked by the server and verified against the state registry, unknown fields are ignored, and price fields become public 'from $X' displays. These are real behavioral consequences an agent could not infer from readOnlyHint=false/openWorldHint=true alone.

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

Conciseness3/5

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

The most important constraint (genuine booking flow required) is correctly front-loaded, but the text is long and repeatedly re-explains what the schema already documents, notably the booking_url, license_number, starting_price_cents and price_note definitions.

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?

Complete enough for an 18-parameter mutation with no output schema: workflow state, verification outcome, and server-side forcing of status/license_required are all covered. It never says what the call returns (submission id, status payload), a small gap given there is no output schema.

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 already 100%, so the baseline is 3, but the description adds sourcing guidance (look in site footer/contact page or JSON-LD LocalBusiness block for street_address), format examples for license and price fields, and explains that trade is auto-assigned from 'description'. It mostly restates schema text for booking_url and license_number rather than adding to it.

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 a specific verb and resource ('Submit a DFW service business to the dfwmetro.net verified directory'), which cleanly separates it from the sibling search tools find_listings and find_verified_listings without needing to name them.

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?

Gives explicit eligibility conditions (must be genuinely online-bookable with a date/time picker or booking widget) and explicit exclusions (quote forms, contact forms, phone-only, login-gated flows fail verification). It also says when to omit 'trade', when 'license_number' is required by trade type, and instructs the agent to find the street address before submitting.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.