Skip to main content
Glama

Zoning Signal

by com.zoningsignal
OverviewDiscussionsAdmin

Search

semantic_search
Read-onlyIdempotent

Search every record by exact words and by meaning at once: meeting agendas and minutes, place dossiers, corridors, named patterns and briefs, entities and watch items. Finds a case, ordinance or resolution number, a parcel id or alternate key, an address, a project, firm or person, or a plain-language question. Ranking fuses three lists by reciprocal rank: full-text match (every word as written; "quotes", OR and -word work as in web search), title match, and voyage-4 embedding similarity. Each hit carries its true cosine similarity and matched (title, text, meaning). Every response states scope (the query names a covered place, a place outside coverage, or no place) and evidence (strong when a top record contains the query's terms or closely resembles it); when either needs explaining it adds a note and the coverage. weak_match is deprecated and will be removed in 2.4.0: it is true when scope is outside or evidence is not strong, so read those instead. Coverage: 25 jurisdictions in Lake, Orange, Osceola, Polk and Seminole counties, Florida, from 2024, listed in the coverage resource. Top 12.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesA name, a number or a question. Text matching needs every word to appear in a record, so extra words narrow it; meaning matching tolerates any wording. Maximum 500 characters.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsYes
noteNoPresent when scope is outside, evidence is weak, or nothing matched.
countYes
queryYes
scopeYesWhether the query names a covered place, a place outside coverage, or no place.
coverageNoWhat the corpus covers; present with note. Same object as the coverage resource.
evidenceYesstrong: a top record contains the query terms or closely resembles it (cosine >= 0.5). weak: records only loosely resemble it. none: nothing returned.
weak_matchNoDeprecated since 2.3.0; removed in 2.4.0. True when scope is outside or evidence is not strong. Read scope and evidence instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • changedInput schema / properties / q / description
      Previous value: -"The natural-language query. A phrase, an entity name, or a thematic concept all work. Asymmetric query-time embedding handles short queries cleanly. Maximum 500 characters."New value: +"A name, a number or a question. Text matching needs every word to appear in a record, so extra words narrow it; meaning matching tolerates any wording. Maximum 500 characters."
    • addedOutput schema / properties / coverage
      Added value: +{
+  "description": "What the corpus covers; present with note. Same object as the coverage resource.",
+  "type": "object"
+}
    • addedOutput schema / properties / evidence
      Added value: +{
+  "description": "strong: a top record contains the query terms or closely resembles it (cosine >= 0.5). weak: records only loosely resemble it. none: nothing returned.",
+  "enum": [
+    "strong",
+    "weak",
+    "none"
+  ],
+  "type": "string"
+}
    • addedOutput schema / properties / hits / items / properties / matched
      Added value: +{
+  "description": "Which rankings found the record: its title holds every query term, its text does, and/or it is among the 50 nearest by meaning.",
+  "items": {
+    "enum": [
+      "title",
+      "text",
+      "meaning"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedOutput schema / properties / hits / items / properties / similarity / description
      Added value: +"True cosine between the query and the record embedding."
    • changedOutput schema / properties / hits / items / required
      Previous value: -[
-  "slug",
-  "type",
-  "title",
-  "similarity",
-  "url"
-]New value: +[
+  "slug",
+  "type",
+  "title",
+  "similarity",
+  "url",
+  "matched"
+]
    • addedOutput schema / properties / note
      Added value: +{
+  "description": "Present when scope is outside, evidence is weak, or nothing matched.",
+  "type": "string"
+}
    • addedOutput schema / properties / scope
      Added value: +{
+  "description": "Whether the query names a covered place, a place outside coverage, or no place.",
+  "enum": [
+    "covered",
+    "outside",
+    "unknown"
+  ],
+  "type": "string"
+}
    • addedOutput schema / properties / weak_match
      Added value: +{
+  "deprecated": true,
+  "description": "Deprecated since 2.3.0; removed in 2.4.0. True when scope is outside or evidence is not strong. Read scope and evidence instead.",
+  "type": "boolean"
+}
    • addedOutput schema / required
      Added value: +[
+  "query",
+  "hits",
+  "count",
+  "scope",
+  "evidence"
+]
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "type": "number"
+    },
+    "hits": {
+      "items": {
+        "properties": {
+          "similarity": {
+            "type": "number"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "subtitle": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "title": {
+            "type": "string"
+          },
+          "type": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "slug",
+          "type",
+          "title",
+          "similarity",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "query": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already establish readOnly, idempotent, non-destructive safety. The description adds substantial behavioral context beyond that: the reciprocal-rank fusion of full-text/title/embedding lists, query operator syntax ('quotes', OR, -word), response fields (similarity, matched, scope, evidence, note), the weak_match deprecation and its 2.4.0 removal, and the 25-jurisdiction/5-county coverage limit. This is exactly the kind of operational detail annotations cannot convey.

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 long (~200 words) but every sentence carries information: coverage, ranking, response contract, deprecation, result cap. It is well front-loaded with the core action and resource list, followed logically by mechanics, response shape, and caveats. Slightly dense, but the complexity of a fused-ranking search tool justifies the length.

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 a rich output schema present, the description still explains the response contract (similarity, matched, scope, evidence, note, coverage), the deprecation path, geographic/jurisdictional coverage, and the 'Top 12' result cap. For a single-parameter search tool, nothing an agent needs to invoke it correctly is missing.

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% and the schema already explains the q parameter well (names/numbers/questions, word-matching semantics, 500-char limit). The description adds value beyond the schema by documenting the query operators (quotes, OR, -word) and enumerating the concrete input types (parcel id, alternate key, ordinance/resolution number) — genuine supplementary meaning.

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 precise verb-resource pair — 'Search every record by exact words and by meaning at once' — and enumerates the exact record types covered (meeting agendas, place dossiers, corridors, patterns, entities, watch items) and the kinds of queries it resolves (case numbers, parcel ids, addresses, people). This clearly distinguishes it from the resource-specific describe_*/list_* siblings, which retrieve single known resources rather than searching across all.

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 makes usage context clear by specifying scope ('Search every record') and query styles (names, numbers, questions), which implies it is the cross-cutting lookup tool versus the per-resource siblings. It does not explicitly name alternatives with when-not conditions, but the resource enumeration and 'Finds a case... or a plain-language question' framing make the intended usage unambiguous.

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

All Zoning Signal toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources