ZoningVerdict
Server Details
Human-reviewed zoning answers with ordinance citations for covered US municipalities.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose with no overlap; for example, ask_zoning_question handles Q&A, check_coverage does coverage preflight, and create_watch manages subscriptions.
All tool names follow a consistent verb_noun snake_case pattern, e.g., list_municipalities, get_district_rules, and resolve_parcel_district.
With 7 tools, the set is well-scoped for the domain of zoning ordinance coverage, covering listing, querying, resolution, and subscriptions without being excessive.
The tool surface covers all key operations for the domain, including listing, resolution, rule retrieval, coverage checks, and watch creation, though minor gaps like deleting watches exist.
Available Tools
7 toolsask_zoning_questionAInspect
Look up a published question-and-answer for a municipality and topic. Returns the matching reviewed answer with its citations, or reports honestly that no published answer exists and lists the topics that do have reviewed answers. Never generates new answers; confirm with the municipality before acting.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | The question in plain words, used to find the best match. | |
| topic | No | Optional filter, one of: permitted_uses, special_land_uses, setbacks, height, lot_coverage, lot_size, parking, adu, accessory_structures, fences, signs, home_occupation, variance_process. | |
| municipality | Yes | Municipality slug from list_municipalities. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It clearly states the tool does not generate new answers, reports honestly when no answer exists, and lists available topics. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, behavior, warning. Front-loaded and no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is remarkably complete. It explains what is returned (answer with citations or honest report with topic list) and key constraints. No gaps for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter descriptions. The tool description adds marginal value by mentioning 'municipality and topic' but does not provide additional semantics beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('look up') and a clear resource ('published question-and-answer for a municipality and topic'). It distinguishes itself by stating it returns only reviewed answers or reports absence, differentiating from sibling tools like list_municipalities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (need a published Q&A) and includes a key guideline: never generates new answers, confirm with municipality. However, it does not explicitly compare to sibling tools or state when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_coverageAInspect
Free coverage preflight for an address or municipality string. Returns whether ZoningVerdict covers it, available topics, pack version, and last-reviewed date. It does not identify a parcel's zoning district; use resolve_parcel_district only when the district determination is needed. Results are for information purposes only.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Address or municipality string. | |
| address | No | Street address text; city and state improve matching. | |
| municipality | No | Municipality slug or name. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states return fields and that results are informational, implying read-only behavior. Does not explicitly confirm safety, idempotency, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose. No redundant or extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 optional parameters, description covers return values, limitations, and sibling differentiation. Could mention required parameter combinations, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions. Description adds value by noting that city and state improve matching for address parameter, which helps agent use the tool effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb ('Free coverage preflight') and resource (address/municipality string). Distinguishes from sibling tool resolve_parcel_district by explicitly stating what it does not do and when to use the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear context: it's a free preflight for coverage. Explicitly advises using resolve_parcel_district for district determination, but doesn't mention other siblings or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_watchAInspect
Start a $49/month watch on a covered municipality (optionally one topic): an email whenever a human-reviewed rule change is published, with the citation and the updated page. Returns a Stripe checkout URL; the subscription activates only after checkout completes, and every email carries unsubscribe and billing links. Alerts are reviewed summaries for information purposes. Use list_municipalities for coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional: watch one topic only, one of: permitted_uses, special_land_uses, setbacks, height, lot_coverage, lot_size, parking, adu, accessory_structures, fences, signs, home_occupation, variance_process. | |
| municipality | Yes | Municipality slug from list_municipalities. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully compensates by disclosing price, Stripe checkout URL, activation timing, email content (unsubscribe/billing links), and that alerts are reviewed summaries for information purposes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with three sentences. It front-loads the key action and price, then covers behavior and usage note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (Stripe checkout URL) and the subscription lifecycle. For two simple parameters, this is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 specifying that municipality is a slug from list_municipalities, and it lists the possible topic values inline, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts a $49/month watch on a covered municipality with optional topic filtering, which is a specific verb+resource. It distinguishes from siblings like list_municipalities by focusing on creating a subscription alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use list_municipalities for coverage, providing a clear alternative. It implicitly indicates when to use this tool (to get email alerts) but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_district_rulesAInspect
Get the published rules for one zoning district by topic (setbacks, fences, accessory structures, and so on). District codes come from list_districts or resolve_parcel_district — do not guess them. Every rule carries its ordinance citation and source link plus the pack's last-reviewed date. Summaries for information, not legal advice; confirm with the municipality before acting.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | One of: permitted_uses, special_land_uses, setbacks, height, lot_coverage, lot_size, parking, adu, accessory_structures, fences, signs, home_occupation, variance_process. | |
| district | No | District code, e.g. R-2. Get valid codes from list_districts or resolve_parcel_district; do not guess. | |
| municipality | Yes | Municipality slug from list_municipalities. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses that output includes ordinance citation, source link, and last-reviewed date, and states the information is summary not legal advice, adding transparency beyond a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose, then critical guidance and disclaimers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with no output schema, describes output contents and limitations, and provides sourcing guidance. Fully adequate for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage. Description reinforces the no-guessing rule for district, lists examples for topic, and clarifies municipality slug source, adding value over schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Get', the resource 'published rules', and the scope 'one zoning district by topic'. It distinguishes from siblings by referencing list_districts and resolve_parcel_district for valid district codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns not to guess district codes and directs to sibling tools. Includes legal disclaimer. Could further contrast with ask_zoning_question but still provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_districtsAInspect
List the zoning district codes for one municipality, with each district's name, category, and summary. Use these codes with get_district_rules; do not guess codes. If you have a street address, resolve_parcel_district identifies the district for you. Free, like list_municipalities. Reviewed summaries for information purposes only.
| Name | Required | Description | Default |
|---|---|---|---|
| municipality | Yes | Municipality slug from list_municipalities. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the summaries are for information purposes only, implying non-authoritative output. It also mentions the tool is free, suggesting no cost or rate limits. Missing explicit mention of read-only or side-effect-free operation, but inferred.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, usage guidance, and additional info (free, info-only). No fluff, front-loaded with core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple list tool with one parameter and no output schema. Description sufficiently explains output (codes, name, category, summary) and how to use with sibling tools. Could mention limits or pagination, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'municipality' with 100% schema description coverage (mentions slug from list_municipalities). Description adds context that it lists for 'one municipality' but doesn't add significant semantics beyond schema. Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists zoning district codes for one municipality with details. It distinguishes from siblings by directing to get_district_rules for rules and resolve_parcel_district for address-based lookup, preventing misuse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (to get district codes for a municipality) and when not to (use resolve_parcel_district for addresses). Warns not to guess codes and directs to get_district_rules for further use. Also notes it's free like list_municipalities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_municipalitiesAInspect
List the municipalities ZoningVerdict covers, with each pack's version and last-reviewed date. Coverage is reviewed summaries of public zoning ordinances, for information purposes only. Start here when you do not have a street address; with an address, start with resolve_parcel_district.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses it's for information purposes only and gives the scope of coverage. No destructive behavior expected; adequate transparency for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states action and output, second adds usage guidance and disclaimer. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool with no annotations or output schema, the description covers purpose, output, usage context, and a disclaimer. It is complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist. The description adds meaning by specifying what items are listed (municipalities, pack version, last-reviewed date), which is essential since there is no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists municipalities covered with version and last-reviewed date. It distinguishes from siblings by advising when to use this tool versus resolve_parcel_district.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Start here when you do not have a street address; with an address, start with resolve_parcel_district.' Provides clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_parcel_districtAInspect
Resolve a street address to its municipality and, where a GIS path exists, its zoning district. Start here when you have an address, then pass the returned district code to get_district_rules. The response discloses how the district was identified. Parcel boundaries and zoning lines can disagree near edges; confirm with the municipality before acting.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Street address, city, MI. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the response reveals how the district was identified and warns about potential boundary disagreements. These are valuable behavioral insights beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three focused sentences. It front-loads the core action, then provides workflow and cautionary advice, all without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers the workflow and edge cases (boundary disagreements). It lacks explicit mention of error handling or the case when no GIS path exists, but overall it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the address parameter with 100% coverage. The description adds no additional parameter details beyond the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves an address to its municipality and zoning district. It distinguishes itself from siblings by explicitly positioning it as the starting point before using get_district_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to start here when you have an address and to pass the returned district code to get_district_rules. It provides workflow context but does not explicitly exclude other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!