Zoning Signal
Server Details
US municipal zoning intelligence — corridor analysis, place dossiers, named-pattern detection.
- 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.3/5 across 14 of 14 tools scored.
Each tool targets a distinct concept or action: listing vs describing, entity vs pattern vs place vs corridor. The descriptions provide clear boundaries and use cases, leaving no ambiguity.
Tool names follow a consistent verb_noun pattern (list_*, describe_*, semantic_search, get_track_record). Even 'meeting_index' aligns with the pattern. No mixed conventions or vague verbs.
14 tools cover the full scope of a zoning observatory: discovery, detailed dossiers, search, tracking, and calibration. The count is well-scoped for the domain without being bloated or sparse.
The tool surface provides comprehensive coverage for reading and querying the observatory's data. Minor gaps exist (e.g., no direct raw data export, no cross-pattern comparison), but core workflows are fully supported.
Available Tools
19 toolscurrent_named_patternsCurrent Named PatternsAInspect
DEPRECATED — use list_patterns instead. Routes to the same handler. Will be removed in v0.13.0. Lists every named pattern in the Pattern Atlas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| patterns | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the output (pattern name, brief, URL, coverage) and that patterns are currently tracked. It does not discuss limitations or freshness, but the tool is straightforward and read-only.
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. The parenthetical definition of a named pattern is efficient and helpful. The description is front-loaded with the key purpose.
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?
No output schema, but the description fully explains the return fields (pattern name, anchoring brief, brief URL, spatial coverage). For a simple list tool with no nested objects, this is 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 input schema has 0 parameters, so the baseline is 4. The description does not need to explain parameters, and it adds no extraneous parameter info.
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 lists named patterns, defines what a named pattern is, and specifies the return fields (pattern name, anchoring brief, URL, spatial coverage). This distinguishes it from sibling tools like describe_corridor or semantic_search.
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 the use case: retrieving all tracked patterns. It does not explicitly state when not to use it or mention alternatives, but the context of sibling tools (e.g., semantic_search for search, list_cities for cities) makes the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_corridorDescribe CorridorAInspect
Return the dossier projection for a corridor, in the requested cognitive lens. Same lens enum and default as describe_place. Corridor projections surface cross-municipal dialectics and shared-infrastructure dynamics that no single place dossier captures.
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | The cognitive position to project. Defaults to "synthesis". Canonical lenses: developer, investor, broker, attorney, business, resident, civic-leader. Aliases route to canonical: legal/lawyer/counsel/regulator → attorney; realtor/intermediary → broker; civic/government → civic-leader; homeowner → resident; operator/site-selector → business; builder → developer. | synthesis |
| slug | Yes | The corridor slug (e.g., "us-27-south-lake"). Use list_corridors to discover available slugs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| lens | Yes | |
| slug | Yes | |
| type | Yes | |
| title | No | |
| claims | Yes | |
| freshness | Yes | |
| projection | Yes | |
| frontmatter | No | |
| record_status | No | |
| available_lenses | No | |
| lens_was_requested | No | |
| fell_back_to_synthesis | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It describes the tool as returning a dossier projection, which implies a read operation, but does not mention side effects, authentication requirements, or error handling. The behavioral transparency is adequate but not thorough.
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 two sentences, front-loaded with the main purpose, and every sentence adds valuable information. No redundancy or extraneous text.
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 the tool has only two parameters and no output schema, the description explains what the tool returns and its unique value. However, it does not describe the output format or error behavior, leaving some gaps for an AI agent. It is minimally complete but lacks full detail.
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 both parameters documented. The description adds value by referencing the sibling tool's lens enum and default, and by explaining that single-lens values surface focused projections. This provides meaningful 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 the tool returns a dossier projection for a corridor with a cognitive lens. It distinguishes from the sibling describe_place by explaining that corridor projections surface cross-municipal dialectics and shared-infrastructure dynamics that place dossiers do not capture.
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 provides context by noting the same lens enum and default as describe_place, implying that this tool is for corridors instead of places. However, it does not explicitly state when to use or not use this tool, nor does it list alternatives beyond the sibling reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_entityDescribe EntityAInspect
Return the full structured dossier for a named entity — the canonical citable artifact for any actor, organization, ordinance, or project the corpus references. Returns: voxel_lead (134-167 word voxel-disciplined identity prose), canonical_role, the class-specific cluster (person.voting_record for board members; organization.type + jurisdiction; legislation.legal_status + effective_date + sunset_date + citation; creative_work.work_type + status + case_number), the bidirectional graph references (appears_in_meetings, appears_in_briefs, appears_in_watches, exhibits_patterns, related_entities, related_places, related_corridors), the provenance_chain, and the canonical surfaces (dossier URL, schema_id, decoder_index_hub). Each schema_id (/entities/{slug}#{class.toLowerCase()}) is the stable cross-page Schema.org reference — Person / Organization / Legislation / CreativeWork — that AI agents resolve to when citing the entity. Use when grounding a citation, when reasoning about an entity's full role across the corpus, or when traversing the entity graph from a single name.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The entity slug (e.g., "sb-180", "hanover-land-company", "anita-geraci-carver"). Use list_entities to discover available slugs. The Decoder Index hub at /entities lists every entity grouped by class. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| slug | Yes | |
| person | No | |
| named_at | No | |
| schema_id | Yes | |
| voxel_lead | No | |
| last_active | No | |
| legislation | No | |
| display_name | Yes | |
| entity_class | Yes | |
| organization | No | |
| creative_work | No | |
| canonical_role | No | |
| related_places | No | |
| provenance_chain | No | |
| related_entities | No | |
| appears_in_briefs | No | |
| exhibits_patterns | No | |
| appears_in_watches | No | |
| appears_in_meetings | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the return structure, including voxel_lead length, class-specific clusters, graph references, provenance, and schema ID format. It provides comprehensive behavioral context beyond mere safety hints.
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 somewhat lengthy but well-structured with bullet-like lists. Every sentence adds value, and the main purpose is 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?
Given no output schema, the description compensates by detailing the full output structure. It also contextualizes usage among siblings, making it complete for a one-parameter 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% and the schema describes 'slug' well. The description adds extra value by suggesting use of list_entities and referring to the Decoder Index, which helps the agent discover valid values.
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 'Return the full structured dossier for a named entity', which is a specific verb+resource combination. It distinguishes from siblings by specifying it returns the canonical citable artifact for entities, unlike describe_pattern or describe_place.
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?
Explicit usage guidance is provided: 'Use when grounding a citation, reasoning about an entity's full role, or traversing the entity graph.' It does not explicitly state when not to use, but the context of sibling tools implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_meetingDescribe MeetingAInspect
Return the full dossier projection for a meeting reading, in the requested cognitive lens. Same lens enum and default as describe_place / describe_corridor — eight total projections (seven stakeholder lenses — developer, investor, broker, attorney, business, resident, civic-leader — plus synthesis as the default). Returns the lens-projected body, full frontmatter (jurisdiction, board, meeting_date, document_type, key_signals, vote tallies), citation-stable claims[] (per the Phase 11 Citable Contract; populates as meeting claim scopes graduate), four-clock freshness, and the structured record_status block (record_type / meeting_status / outcome_status / minutes_available / vote_final) — the last prevents agents from summarizing agenda intent as completed action. Use to ground citations in a specific meeting's reading; pair with list_meetings or meeting_index for discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | Optional cognitive lens. Default: synthesis (the whole-picture multi-projection view). Canonical lenses: developer, investor, broker, attorney, business, resident, civic-leader. Aliases route to canonical (legal/lawyer/counsel/regulator → attorney; realtor/intermediary → broker; civic/government → civic-leader; homeowner → resident; operator/site-selector → business; builder → developer). When the requested lens is not present in the dossier body, the response falls back to synthesis with fell_back_to_synthesis: true. | |
| slug | Yes | The meeting slug (e.g., "leesburg-pc-2026-01"). Use list_meetings or meeting_index to discover available slugs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| lens | Yes | |
| slug | Yes | |
| type | Yes | |
| title | No | |
| claims | Yes | |
| freshness | Yes | |
| projection | Yes | |
| frontmatter | No | |
| record_status | Yes | |
| available_lenses | No | |
| lens_was_requested | No | |
| fell_back_to_synthesis | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: fallback to synthesis with a flag, return fields (frontmatter, claims, freshness, record_status), and the purpose of record_status to prevent premature summarization. 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?
The description is detailed but every sentence serves a purpose. It front-loads the main function and then lists return components. Slightly long but justified by the complexity of the tool.
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?
No output schema is provided, so the description fully explains the return structure (body, frontmatter, claims, freshness, record_status). It also integrates with sibling tools, making it complete for an agent to use.
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%, but the description adds value: explains lens enum values, default, and fallback; tells how to discover slugs (list_meetings/meeting_index). These details go 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 returns a full dossier projection for a meeting with a cognitive lens. It distinguishes from siblings by referencing the shared lens enum with describe_place/describe_corridor and mentions pairing with list_meetings/meeting_index for discovery.
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 provides a clear use case: ground citations in a specific meeting's reading. It pairs with discovery tools but does not explicitly state when not to use it or list alternatives beyond the sibling mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_patternDescribe PatternAInspect
Return the full dossier for a named pattern: voxel_lead, signal_status (score/direction/horizon/confidence/pips), scope (spatial/temporal/topical/corridors), full exhibits inventory with detection metadata, defensive responses, provenance chain, related briefs, related places, related corridors, audiences, and the canonical surfaces (dossier URL, DefinedTerm @id, DefinedTermSet @id, atlas list URL). Use when an agent needs the structured pattern data to cite or analyze. Each pattern is a citable entity in the corpus's entity graph; the DefinedTerm canonical home gives AI agents a stable reference.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The pattern slug (e.g., "self-storage-canary"). Use current_named_patterns to discover available slugs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | Yes | |
| slug | Yes | |
| scope | No | |
| claims | Yes | |
| exhibits | No | |
| named_at | No | |
| surfaces | No | |
| audiences | No | |
| freshness | Yes | |
| voxel_lead | No | |
| signal_status | No | |
| related_briefs | No | |
| related_places | No | |
| lifecycle_stage | No | |
| provenance_chain | No | |
| related_corridors | No | |
| defensive_response | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Describes output but does not explicitly state it is read-only or non-destructive. Adds contextual info on provenance and structure but misses safety 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?
Single paragraph, front-loaded with main purpose, then lists components. Slightly verbose but each sentence adds value. Could be more structured, but effective.
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 1-param tool with no output schema, the description enumerates the extensive dossier contents, covering detection metadata, provenance, related entities, etc. Provides good contextual completeness.
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 a clear description for the 'slug' parameter including an example. The tool description adds no further parameter information beyond the schema, so baseline 3 applies.
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?
Clearly states it returns the full dossier for a named pattern, listing specific components. Verb is 'return', resource is 'named pattern'. Differentiates from sibling 'describe_corridor' etc. by specifying pattern focus.
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 'Use when an agent needs the structured pattern data to cite or analyze.' Does not mention when not to use or contrast with alternatives, but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_placeDescribe PlaceAInspect
Return the dossier projection for a city, in the requested cognitive lens. Defaults to the synthesis projection (the multidimensional view that holds all lenses in superposition and names the dialectics). Pass a single-lens value to get the focused cognitive position — useful when the agent is acting on behalf of a user with a specific stake (developer underwriting, investor thesis, broker client argument, attorney precedent search, resident orientation, civic-leader regional coordination).
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | The cognitive position to project. Defaults to "synthesis". Canonical lenses: developer, investor, broker, attorney, business, resident, civic-leader. Aliases route to canonical: legal/lawyer/counsel/land-use-counsel/regulator → attorney; realtor/intermediary/real-estate-broker → broker; civic/government/official/governance → civic-leader; homeowner/citizen → resident; operator/site-selector/occupier → business; builder/land-developer → developer. | synthesis |
| slug | Yes | The place slug (e.g., "clermont-florida"). Use list_places to discover available slugs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| lens | Yes | |
| slug | Yes | |
| type | Yes | |
| title | No | |
| claims | Yes | |
| freshness | Yes | |
| projection | Yes | |
| frontmatter | No | |
| record_status | No | |
| available_lenses | No | |
| lens_was_requested | No | |
| fell_back_to_synthesis | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It explains the default behavior and the effect of lens values, but does not mention read-only nature, error responses, or permissions. Adequate but could be more thorough.
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 conveying the core function and parameter guidance without redundancy. Information is front-loaded, making it easy for an agent to parse quickly.
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?
With no output schema, the description could benefit from briefly stating what the projection contains, but the concept of 'dossier projection' is plausible given the domain. The tool's purpose and parameters are well-covered.
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 description coverage is 100%, but the description adds value by elaborating on the 'lens' parameter with stakeholder examples and cross-referencing 'list_cities' for the slug, providing practical guidance 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?
Clearly states it returns a 'dossier projection' for a city, with a specific verb and resource. Differentiates from sibling tools like describe_corridor by focusing on cities and introduces the novel concept of cognitive lenses.
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 explains when to use the default synthesis projection versus a single-lens value, including concrete examples of stakeholder use cases. Lacks explicit 'when not to use' or alternative tool suggestions, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_watchDescribe WatchAInspect
Return the full dossier for a watch item — the observatory's forward-looking observation primitive. Returns title, subtitle, scope (place / corridor / pattern / brief / region), trigger (type / date / condition), significance (score / horizon / confidence / confidence_pips / why_it_matters_voxel), full body prose, four-clock freshness, and citation-stable claims[]. For RESOLVED watches, also returns the outcome cluster (outcome_type, outcome_summary, prediction_assessment with directional/horizon/significance assessments, lesson, citations) — and the lesson surfaces as a stable claim_id (per the Phase 11 Citable Contract × Phase 8 Resolution Bridge compound). Use to ground citations in a specific watch's prediction or resolution; pair with list_watch_items for discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The watch slug (e.g., "lake-bright-council-mar-23"). Use list_watch_items to discover available slugs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| body | No | |
| slug | Yes | |
| type | Yes | |
| scope | No | |
| title | No | |
| claims | Yes | |
| outcome | Yes | |
| trigger | No | |
| subtitle | No | |
| freshness | Yes | |
| significance | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It details the return fields including special behavior for RESOLVED watches, and does not mention any destructive side effects. It is fairly transparent for a read 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?
The description is a single paragraph that front-loads the main purpose and then enumerates return fields. While somewhat verbose, every sentence adds value and the structure is logical.
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 the tool's complexity (many return fields, no output schema, no annotations), the description is thorough. It lists all major output components, including special handling for resolved watches and citation-stable claims, which is essential for correct usage.
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?
There is only one parameter 'slug' with 100% schema coverage including an example and a note to use list_watch_items. The description adds the context of pairing with that sibling tool, but the parameter is already well-documented in 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 'Return the full dossier for a watch item' and explains what a watch item is. It distinguishes from sibling tools by mentioning pairing with list_watch_items for discovery.
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 says 'Use to ground citations in a specific watch's prediction or resolution; pair with list_watch_items for discovery.' This provides clear use context and hints at alternatives, though it doesn't explicitly exclude other describe tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_zoning_signalDescribe Zoning SignalAInspect
Return the canonical product description for Zoning Signal — what the observatory is, the four artifact types it publishes, the regional scope of current coverage, and the methodology. Call once per session to ground subsequent tool calls in canonical context.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| built_by | No | |
| surfaces | Yes | |
| description | Yes | |
| methodology | Yes | |
| artifact_types | Yes | |
| regional_scope | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the intended behavior as a read-only retrieval of information, but does not explicitly state safety, idempotency, or lack of side effects. For a simple, parameterless tool, the description is adequate but lacks explicit behavioral disclosure.
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 two sentences, front-loading the action and then providing a usage hint. Every sentence adds value, with no wasted words. It is appropriately sized for the tool's simplicity.
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 parameterless tool without an output schema, the description is complete enough: it specifies the content and when to call. However, it does not mention the output format (e.g., text structure), which could be beneficial but is not critical given sibling tools likely behave similarly.
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 input schema is empty with zero parameters, and schema description coverage is 100% trivially. The description adds no parameter information, but none is required. Baseline for zero parameters is 4, and the description does not need to compensate.
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 returns a canonical product description for Zoning Signal, listing specific content: observatory, four artifact types, regional scope, and methodology. It distinguishes itself from sibling tools like 'describe_corridor' and 'describe_place' by focusing on a unique entity.
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 provides clear usage context: 'Call once per session to ground subsequent tool calls in canonical context.' This instructs when to use the tool, but does not explicitly exclude scenarios or mention alternatives. The sibling tools imply alternative describe actions for other entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_track_recordGet Track RecordAInspect
Return the observatory's public calibration scorecard — the aggregate accuracy of past watch-item directional reads, horizon calls, and significance assessments across resolved watches. Returns: total_resolved, directional accuracy (aligned + 0.5 × mixed), horizon accuracy (within / total), significance accuracy (confirmed / total), per-confidence-pip stratification, recent resolutions, and per-jurisdiction breakdown. Optionally scope to a single jurisdiction or corridor's constituent set. Use when an agent or user wants to assess Zoning Signal's historical forecasting accuracy before citing a current prediction. Misreads are reported.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | Optional: scope to a brief slug (e.g., "six-month-board-flip"). Returns the track record for watches linked to a specific named-pattern brief. | |
| corridor | No | Optional: scope to a corridor slug (e.g., "us-27-south-lake"). Returns the aggregate track record across the corridor's constituent places. | |
| jurisdiction | No | Optional: scope to a single place slug (e.g., "leesburg-florida") for that city's track record only. Use list_cities to discover available slugs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| scope | No | |
| recent | No | |
| horizon | No | |
| pending | No | |
| obsolete | No | |
| surfaces | No | |
| directional | No | |
| significance | No | |
| by_confidence | No | |
| total_resolved | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns public data and that misreads are reported. It implies read-only behavior. Additional detail on return fields enhances transparency, though it could explicitly state it does not modify data.
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?
Single paragraph, front-loaded with purpose, every sentence adds value. No repetition or unnecessary words. Efficiently communicates scope and return format.
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 thoroughly explains return fields (total_resolved, accuracy metrics, stratification, etc.). Covers optional parameters and scoping. Lacks mention of result ordering or pagination, but for an aggregate scorecard, it's likely a single record, so complete enough.
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. Description adds value by explaining each parameter's purpose, including optional scoping to jurisdictions or corridors, and suggesting list_cities to discover slugs. This goes beyond the schema descriptions.
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?
Clearly states the tool returns the observatory's public calibration scorecard, describing exactly what it provides. Distinguishes from siblings like current_named_patterns and describe_corridor by focusing on historical accuracy.
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 states when to use: 'when an agent or user wants to assess Zoning Signal's historical forecasting accuracy before citing a current prediction.' Lacks explicit when-not or alternative tools, but context from sibling names and the mention of 'Misreads' provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_citiesList CitiesAInspect
DEPRECATED — use list_places instead. Routes to the same handler. Will be removed in v0.13.0. Lists every place dossier (per-jurisdiction reading) the observatory publishes. Optionally filter by state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional US state name (e.g., "Florida") to filter the result set. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| cities | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses return fields and optional filter but does not mention pagination or rate limits, which is acceptable for a simple list 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 covering purpose, filter, return fields, and usage hint. No wasted words, front-loaded with purpose.
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 1 optional parameter and no output schema, description explains return fields and usage adequately. Could mention ordering or limits but not necessary for this tool's simplicity.
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%; description adds value by specifying state is optional, US state name, and providing an example, beyond the schema definition.
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 verb 'List' and resource 'every city with a published place dossier', and distinguishes from siblings like describe_place and list_corridors.
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 'Use to discover the available place-level coverage before calling describe_place', providing a clear usage context and a hint about an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_corridorsList CorridorsAInspect
List every published corridor page. A corridor is the cross-municipal economic-topology view — the cross-jurisdiction read on a shared infrastructure spine, aquifer, or commercial gravity field. Returns name, slug, constituent cities, primary axis, and URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| corridors | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the return fields but does not disclose any side effects, rate limits, or confirm read-only behavior. Adequate but not comprehensive.
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, front-loaded with the action, followed by concept and return fields. No extraneous information, every sentence earns its place.
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 parameterless list tool with no output schema, the description covers the purpose, concept, and return fields. Missing details on pagination or ordering, but acceptable for this simplicity.
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 input schema has zero parameters with 100% coverage. The description adds value by explaining the corridor concept, which aids understanding beyond the schema. Baseline for 0 params is 4.
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 all published corridor pages and explains the concept of a corridor. It distinguishes from siblings like describe_corridor and list_cities by specifying it's a cross-municipal economic-topology view.
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 usage for getting a comprehensive list of corridors but does not provide explicit guidance on when to use alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_entitiesList EntitiesAInspect
List every named entity in the Decoder Index — the smallest citable unit of authority in the corpus. Returns the four-class taxonomy (Person / Organization / Legislation / CreativeWork) with class-specific summary fields (jobTitle for Person; jurisdiction for Organization / Legislation / Project; legal_status for Legislation; case_number + work_status for Project) plus cross-reference counts (meetings_count, briefs_count, watches_count, patterns_count) for each entity. Filter by entity_class, place (jurisdiction), or search substring. Use as the discovery surface for the entity graph; pair with describe_entity for full structured detail. Each entity's schema_id is a stable cross-page reference (/entities/{slug}#{class.toLowerCase()}) that resolves to the canonical Schema.org node — Person / Organization / Legislation / CreativeWork — for AI-citation grounding.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Optional: filter to entities scoped to a specific place (e.g., "leesburg-florida"). Matches entities whose related_places, organization.jurisdiction, legislation.jurisdiction, or creative_work.jurisdiction includes the place slug. | |
| search | No | Optional case-insensitive substring search across display_name, canonical_role, voxel_lead, and slug. Use for natural-language entity discovery (e.g., "denial bloc", "intersection mitigation", "form-based code"). | |
| entity_class | No | Filter by entity class. "Person" = board members, attorneys, applicants (individuals), elected officials. "Organization" = developer firms, law firms, agencies, HOAs, planning consultancies. "Legislation" = state statutes, city ordinances, code sections, design standards. "CreativeWork" = specific projects, case numbers, master plans, infrastructure programs. Omit to return all classes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| filters | No | |
| by_class | No | |
| entities | No | |
| surfaces | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details return fields, filtering options, and the schema_id format, but omits potential behavioral details like 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with two paragraphs, front-loading the purpose. It is informative but slightly verbose, with some details that could be streamlined.
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?
Without an output schema, the description thoroughly explains return values including taxonomy, class-specific fields, and cross-reference counts, making it complete for a list tool with 3 parameters.
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%, baseline 3. The description adds meaning by explaining each entity class with examples and the purpose of filtering parameters, going beyond schema descriptions.
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 'List every named entity in the Decoder Index' with specific verb and resource, and distinguishes from sibling 'describe_entity' by positioning it as a discovery surface for the entity graph.
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?
It explicitly says 'Use as the discovery surface for the entity graph; pair with describe_entity for full structured detail,' guiding when to use and hinting at an alternative, though it does not cover all siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_meetingsList MeetingsAInspect
Return meeting readings across all cities, optionally filtered by date range or jurisdiction substring. Same response shape as meeting_index but with no required parameters — call with no args to get the full corpus, or pass a jurisdiction substring (e.g., "minneola") to filter by city without requiring an exact match. Use when you need to enumerate the full meeting record or scan across cities by date range.
| Name | Required | Description | Default |
|---|---|---|---|
| to_date | No | Inclusive upper bound (ISO 8601 date). Omit for the latest reading. | |
| from_date | No | Inclusive lower bound (ISO 8601 date). Omit to span back to the earliest reading. | |
| jurisdiction | No | Optional case-insensitive substring to filter by city (e.g., "minneola"). Omit for all cities. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| filters | No | |
| meetings | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently describes a read-only operation with consistent response shape compared to meeting_index, though it omits details on pagination or error handling.
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 three concise, front-loaded sentences with no wasted words, each serving a clear purpose: core functionality, response shape, and usage guidance.
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 the simplicity of 3 optional parameters and no output schema, the description sufficiently covers usage and return shape via comparison to meeting_index, though a more explicit return format mention would be beneficial.
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%, and the description adds valuable context beyond the schema (e.g., jurisdiction substring matching, inclusive date bounds, and default behaviors), justifying a score above baseline 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 it returns meeting readings across cities with optional filtering by date range or jurisdiction substring, distinguishing itself from sibling 'meeting_index' by noting no required parameters.
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?
It explicitly states when to use the tool ('enumerate full meeting record or scan across cities by date range') and provides usage examples, but does not explicitly mention when not to use it or alternatives for other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_patternsList PatternsAInspect
List every named pattern in the Pattern Atlas. A named pattern is a coined recurring structure observed across multiple jurisdictions or multiple meetings (e.g., "The Quiet Revolution"). Returns slug, display name, canonical pattern URL (/patterns/{slug}, the DefinedTerm canonical home as of Phase 9), lifecycle stage, signal score, exhibits count, spatial scope, related briefs, and the voxel_lead. Use as the discovery surface for the Pattern Atlas; pair with describe_pattern for full dossier detail. Phase 12 — renamed from current_named_patterns to align with the canonical content-type vocabulary (loader: getAllContent("pattern"); URLs: /patterns/{slug}; describe tool: describe_pattern).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| patterns | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It lists return fields and URL structure but does not disclose behavioral traits like rate limits, authentication, or any side effects. The read-only nature is implied but not explicit.
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?
Front-loaded with main purpose, but includes extra details like Phase 12 and renaming history. Every sentence adds value, but could be slightly more concise for an agent.
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?
Without an output schema, the description thoroughly explains return fields (slug, display name, URL, lifecycle stage, etc.) and the tool's role. It also mentions the underlying loader and URL pattern, making it complete for a parameterless 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?
Input schema has 0 parameters, so baseline is 4. The description does not need to add parameter info, and it correctly notes no parameters are required.
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 'List every named pattern in the Pattern Atlas' and distinguishes itself from sibling tools like describe_pattern by noting it is the discovery surface for a full dossier. The verb 'list' and resource 'named patterns' is specific.
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 'Use as the discovery surface for the Pattern Atlas; pair with describe_pattern for full dossier detail.' Provides context on Phase 12 renaming, but does not explicitly state when not to use it or alternatives beyond describe_pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_placesList PlacesAInspect
List every place dossier (per-jurisdiction reading) the observatory publishes. Optionally filter by state. Returns city, state, slug, signal strength, signal direction, and the dossier URL. Use to discover the available place-level coverage before calling describe_place. Phase 12 — renamed from list_cities to align with the canonical content-type vocabulary (the loader function is getAllContent("place"); URLs are /places/{slug}; the describe tool is describe_place).
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional US state name (e.g., "Florida") to filter the result set. Omit for all places across all states. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| cities | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses return fields (city, state, slug, signal strength, signal direction, dossier URL) and the optional state filter. It does not mention rate limits, side effects, or pagination, but given the tool's simple list nature, this is acceptable.
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 informative and front-loaded with core functionality. It includes a historical note about renaming (Phase 12) which adds length but provides context. Otherwise, it is efficiently structured with clear sentences.
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 the absence of an output schema, the description fully explains the return data (city, state, slug, signal strength, signal direction, dossier URL) and the tool's role in the workflow. For a simple list tool with one optional parameter, this covers all necessary operational context.
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 description coverage is 100% and already explains the 'state' parameter thoroughly (optional US state name, omit for all). The description adds no further parametric detail, so it reaches the baseline of 3 for effective schema coverage.
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?
Clearly states the tool lists place dossiers (per-jurisdiction reading) published by the observatory, optionally filtered by state. It specifies returned fields and distinguishes itself from describe_place by noting this is a discovery tool. The rename from list_cities aligns with vocabulary, but the sibling list_cities may cause confusion; however, the description clarifies the canonical intent.
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 directs using this tool before describe_place to discover available place-level coverage. It implies a discovery-before-detail workflow. No explicit when-not-to-use or alternatives listed, but the sibling list_cities is conceptually redundant; the description's rename notice may mitigate confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_watch_itemsList Watch ItemsAInspect
Return The Watch — the field's forward calendar of pending events, scheduled hearings, regulatory sunsets, and condition-triggered milestones the observatory is tracking. Filter by status (pending / resolved / obsolete), horizon (imminent / near-term / structural), or scope (place / corridor / brief). Use to surface what the field is watching from any cognitive position.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | Optional: filter to items linked to a specific named-pattern brief. | |
| place | No | Optional: filter to items scoped to a specific place dossier (e.g., "leesburg-florida"). | |
| status | No | Filter by lifecycle status. Defaults to 'pending' (active watch items only); pass 'all' for the full corpus including resolved + obsolete entries. | |
| horizon | No | Optional: filter to items in the named horizon band. Imminent = ≤14 days; near-term = ≤90 days; structural = >90 days or condition-triggered. | |
| corridor | No | Optional: filter to items scoped to a specific corridor (e.g., "us-27-south-lake"). |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| status | No | |
| watch_items | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a filtered list of watch items but does not mention defaults (e.g., default status='pending'), ordering, pagination, or empty results. Adequate but not thorough.
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 with no wasted words. First sentence defines the output, second lists filters, third states the use case. Perfectly front-loaded and concise.
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?
Without an output schema, the description fails to explain the structure of returned items (e.g., fields like title, date, type). It also omits whether results are sorted or limited. For a list tool, this gap reduces completeness.
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 covers all parameters (100%), but the description adds interpretation, e.g., horizon bands (imminent ≤14 days) and status defaulting to 'pending.' This adds meaningful context beyond the schema's enum descriptions.
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 explicitly states the tool returns 'The Watch' — a forward calendar of pending events, hearings, etc. The verb 'Return' and specific resource ('The Watch') clearly differentiate it from siblings like list_meetings or semantic_search.
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 explains filtering by status, horizon, or scope and suggests using the tool to 'surface what the field is watching.' It does not explicitly state when not to use it or provide direct alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meeting_indexMeeting IndexAInspect
Return meeting readings for a specific city across an optional date range. A meeting reading is a plain-English read of one harvested planning-board, council, or commission meeting, with signal extraction and entity mapping. Use to drill from a city or corridor into the temporal record.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name (e.g., "Clermont"). Case-insensitive. | |
| to_date | No | Inclusive upper bound (ISO 8601 date). Omit for the latest reading. | |
| from_date | No | Inclusive lower bound (ISO 8601 date). Omit to span back to the earliest reading. |
Output Schema
| Name | Required | Description |
|---|---|---|
| city | No | |
| count | No | |
| to_date | No | |
| meetings | No | |
| from_date | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns plain-English reads with signal extraction and entity mapping, indicating a read-only operation. However, it lacks details on behavior such as error handling, performance limits, or what happens for missing data.
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 extremely concise with two sentences. The first sentence states the core action, and the second provides definition and use case. No redundant text.
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 tool with 3 parameters, no output schema, and no annotations, the description adequately covers purpose, parameters, and use context. It explains what a meeting reading is and how to use the date range. Minor gaps: no mention of output format or empty result behavior.
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 description coverage is 100%, so the schema already documents all parameters. The description adds context (optional date range, specific city) but does not significantly enhance parameter meaning 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 uses specific verb 'Return' and resource 'meeting readings' with precise context (city, date range, and definition of meeting reading). It clearly distinguishes from sibling tools like list_cities or describe_place, which serve different purposes.
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 explicitly states 'Use to drill from a city or corridor into the temporal record,' providing a clear use case. However, it does not mention when not to use this tool or compare with alternatives like semantic_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
semantic_searchSemantic SearchAInspect
Semantic search across the full corpus — every place dossier, corridor signal, meeting reading, and named-pattern brief. Returns results ranked by cosine similarity in a 1024-dimensional embedding space (Voyage AI 4 + Supabase pgvector). Use when the agent does not know the canonical entity slug or named-pattern title in advance — the search returns the readings whose semantic structure best matches the natural-language query, with type, title, similarity, and resolved URL per hit. Threshold 0.55, top 12.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| hits | No | |
| count | No | |
| query | No |
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 discloses embedding model (Voyage AI 4, 1024-dim), database (pgvector), ranking method (cosine similarity), and constraints (threshold, limit). Lacks mention of read-only nature, but that is implied for a search 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?
Four sentences efficiently convey purpose, technique, usage, and output. Front-loaded with core function, followed by technical details and usage guidance. No redundancy or filler.
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 the tool's complexity (searching multiple sources with embeddings), the description is thorough: it lists all searchable content, explains ranking, output fields, threshold, and limit. No output schema, but hits format is described. Adequate for effective use.
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 'q' has full schema description. Tool description adds value by explaining acceptable query types (phrases, entities, concepts), character limit (500), and asymmetric embedding behavior, enriching understanding beyond 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 the tool performs semantic search across multiple corpora, lists the sources, and explains that results are ranked by cosine similarity. It distinguishes itself from siblings by specifying usage when exact identifiers are unknown.
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 'Use when the agent does not know the canonical entity slug or named-pattern title in advance,' providing a clear when-to-use condition. Additionally mentions threshold (0.55) and top-12 results, guiding expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_agent_feedbackSubmit Agent FeedbackInspect
Submit feedback to the observatory's operators about the MCP tool surface. The active counterpart to the passive invocation log. Categories: 'gap' (a capability you expected and didn't find), 'error' (an unexpected failure or wrong result), 'praise' (a tool or surface that did exactly what you needed), 'suggestion' (a refinement you'd recommend), 'citation_request' (a claim or fact you want surfaced with a stable @id you can cite). The submission auto-attaches the prior 10 invocations from your MCP-Session-Id, so operators read your feedback annotated with the call sequence that produced it — no need to repeat what you tried. Operators triage every submission and surface notable feedback at /agent-observatory. This is how the observatory evolves toward what agents actually need.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The feedback prose itself. Be specific. What were you trying to accomplish? What was missing or wrong? Voice that survives compression. Operators read every submission. | |
| category | Yes | Bounded categorization. 'gap' = expected capability is missing. 'error' = tool returned wrong/unexpected/malformed result. 'praise' = a surface or tool that worked exceptionally well. 'suggestion' = a refinement (better tool description, additional argument, alternative output shape). 'citation_request' = a claim or fact you want surfaced with a stable citation @id. | |
| about_url | No | Optional: a URL on the observatory this feedback references (e.g., "https://zoningsignal.com/corridors/us-27-south-lake"). | |
| about_tool | No | Optional: the tool name this feedback is about (e.g., "describe_corridor"). Lets operators rollup feedback per tool. | |
| agent_context | No | Optional: brief description of what the agent was trying to do — the user task that led to this surface. Helps operators understand intent without seeing only the failure point. | |
| suggested_resolution | No | Optional: if you have a concrete proposal — a new tool, a renamed parameter, a missing field on a response — name it here. |
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!