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.5/5 across 17 of 17 tools scored.
Every tool addresses a distinct artifact type or operation (describe, list, search, feedback) with no overlapping purposes. Even similar prefixes like describe_* are clearly differentiated by the artifact name.
Consistent verb_noun pattern with describe_* for dossiers, list_* for enumerations, and standalone verbs for other actions (get_track_record, semantic_search, submit_agent_feedback). Even meeting_index follows the pattern (meeting is the noun, index implies listing).
17 tools is slightly above the typical 3-15 range, but the server covers a detailed domain with multiple artifact types (places, corridors, meetings, entities, patterns, watches, track record, search, feedback), each earning its place.
The tool surface provides comprehensive retrieval and discovery for all artifact types plus search and feedback. Missing create/update/delete tools are reasonable for an observatory's read-heavy domain; only minor gap is lack of a tool to create watch items, which might be out of scope.
Available Tools
17 toolsdescribe_corridorDescribe CorridorARead-onlyIdempotentInspect
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is clearly safe and idempotent. The description adds behavioral context by explaining that the output surfaces cross-municipal dialectics and shared-infrastructure dynamics, and that the lens parameter controls the cognitive projection.
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 sentences, each serving a purpose: action, alignment with sibling, and added value. No wasted words, front-loaded with the core action.
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 presence of an output schema and comprehensive annotations, the description fully covers the tool's purpose, behavioral traits, and unique value. It references sibling tools appropriately and leaves no important gaps.
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 both parameters are well-documented in the schema. The description adds context by aligning the lens parameter with describe_place and referencing list_corridors for slug discovery, but does not provide additional semantic detail 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 specific cognitive lens. It distinguishes itself from sibling describe_place by explaining that corridor projections capture cross-municipal dialectics and shared-infrastructure dynamics that place dossiers do not.
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 guidance by referencing describe_place for the same lens enum and explaining the unique value of corridor projections. However, it does not explicitly state when not to use this tool or enumerate alternatives beyond the sibling listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_entityDescribe EntityARead-onlyIdempotentInspect
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?
Discloses detailed return structure including specific fields and formats (e.g., voxel_lead word count, schema_id format). Annotations confirm read-only, idempotent, non-destructive behavior; description adds rich behavioral context beyond annotations.
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?
Description is somewhat long but each sentence contributes necessary information about the complex return structure. Front-loaded with main purpose. Could be slightly more concise but not verbose.
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?
Fully complete for a complex entity retrieval tool: covers return content, use cases, parameter discovery, and entity types. Output schema exists, so return format details are sufficient. No gaps.
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 detailed description for 'slug'. Description adds value by providing examples, referencing list_entities for discovery, and mentioning Decoder Index hub, going 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 structured dossier for a named entity, listing specific return fields. It distinguishes itself from siblings like describe_meeting by focusing on entities and mentioning the canonical citable artifact.
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: 'Use when grounding a citation...' and includes prerequisite discovery via list_entities and Decoder Index. Lacks explicit 'when not to use' or direct sibling differentiation, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_meetingDescribe MeetingARead-onlyIdempotentInspect
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?
Annotations already indicate read-only, idempotent, non-destructive. The description adds valuable behavioral details: lens projection with fallback, citation-stable claims per Citable Contract, four-clock freshness, and a record_status block that 'prevents agents from summarizing agenda intent as completed action.' This significantly enhances transparency beyond the annotations.
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 packs in necessary detail without being overly verbose. It could benefit from slight structuring (e.g., bullet points for the eight projections or return fields), but it remains efficient and readable. No filler 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 tool's complexity (lens system, many return fields, citation contract) and the existence of an output schema (not shown but noted), the description covers all key aspects: return structure, lens behavior, freshness, and purpose of the record_status block. It feels complete for an agent to understand what to expect.
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 provides base descriptions. The description adds context: for slug, it references list_meetings/meeting_index for discovery; for lens, it explains the default and canonical vs. alias routing, and notes the fallback behavior. This adds meaningful value 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 states it returns 'the full dossier projection for a meeting reading, in the requested cognitive lens.' It distinguishes from siblings by referencing the shared lens enum with describe_place and describe_corridor, and mentions companion tools for discovery. Clear verb+resource+scope.
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 says 'Use to ground citations in a specific meeting's reading; pair with list_meetings or meeting_index for discovery.' This gives clear usage context. While it doesn't explicitly state when not to use, the purpose is well-defined and the pairing suggestion provides practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_patternDescribe PatternARead-onlyIdempotentInspect
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?
Annotations already indicate readOnly and idempotent; description adds what is returned (provenance, related items) and mentions stable reference, with 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?
Front-loaded with purpose, but the listing of many fields makes it verbose; still efficient and well-structured.
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 one parameter and an output schema, the description covers the essential purpose and all returned components, making it 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?
Schema already documents the single parameter well (slug with example and discovery hint). Description does not add new parameter semantics beyond echoing the example.
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 specifies returning a full dossier for a named pattern, listing many fields, and distinguishes from siblings like describe_corridor and describe_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?
Explicitly states when to use (agent needs structured pattern data to cite or analyze) and mentions discovering slugs via current_named_patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_placeDescribe PlaceARead-onlyIdempotentInspect
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial context: explains the concept of 'synthesis projection' and the meaning of cognitive lenses, which goes beyond what annotations provide.
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 relatively long but well-structured: the first sentence states the core purpose, followed by elaboration on usage. Every sentence adds value, though minor trimming could improve conciseness.
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 rich annotations, 100% schema coverage, and presence of an output schema, the description is complete. It covers purpose, parameter usage, and intents for different user personas.
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 significant meaning beyond the schema: it explains the purpose of the 'lens' parameter (cognitive position for different stakeholders), and the 'slug' parameter references list_places for discovery. The description enriches parameter understanding.
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 ('Return the dossier projection') and resource ('for a city'), immediately clarifying the tool's purpose. It distinguishes from sibling tools like describe_corridor and describe_entity by focusing on places.
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 when to use the default 'synthesis' lens versus a single-lens value, listing example stakeholder contexts. However, it does not explicitly state when not to use the tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_watchDescribe WatchARead-onlyIdempotentInspect
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering safety and side effects. The description adds value by detailing the return structure, including the outcome cluster for RESOLVED watches. No contradictions with annotations.
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 and front-loaded with the main purpose. While it is relatively long (several sentences), each sentence adds important detail about the output and usage. It strikes a good balance between completeness and efficiency.
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 one parameter with full schema coverage, and an output schema exists, the description is fully adequate. It explains all relevant output fields and provides context for resolved watches, making it complete for the agent's needs.
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% for the single parameter 'slug', which already includes a description. The description does not add new parameter information beyond restating the slug usage. Baseline 3 is appropriate since the schema carries the full load.
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's purpose: 'Return the full dossier for a watch item.' It specifies the resource (watch item) and the action (return dossier). The description also distinguishes from siblings by mentioning pairing with list_watch_items for discovery, making the purpose precise and unambiguous.
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 explicit usage guidance: 'Use to ground citations in a specific watch's prediction or resolution; pair with list_watch_items for discovery.' This clarifies when to use the tool and how to discover inputs. While it does not explicitly state when not to use or alternatives, the context is clear and sufficient for decision-making.
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 SignalARead-onlyIdempotentInspect
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?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safety. The description adds value by detailing what the description includes, and the 'call once per session' instruction aligns with idempotent behavior. No contradiction.
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: the first defines the tool's purpose and content, the second gives usage guidance. No filler or redundancy.
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 zero-parameter tool with an output schema, the description comprehensively covers what the output contains and how often to call it. This is complete for its 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?
No parameters exist, and schema coverage is 100% (empty schema). Baseline 4 applies since there is no need for parameter-level detail. Description focuses on output content and usage.
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 the canonical product description for Zoning Signal, specifying the exact content (observatory, artifact types, regional scope, methodology). This distinguishes it from sibling 'describe_' tools like describe_corridor or describe_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?
Explicitly says 'Call once per session to ground subsequent tool calls in canonical context,' providing clear when-to-use guidance. It does not explicitly list alternatives or when not to use, but the context strongly implies it's for initial context.
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 RecordARead-onlyIdempotentInspect
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?
Annotations already indicate read-only, idempotent, non-destructive. The description adds that the tool returns historical data and includes the phrase 'Misreads are reported,' acknowledging potential inaccuracies. It also details output structure, enhancing transparency.
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: purpose, return fields, usage guidance, and notable behavior. Concise, front-loaded, and 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 the output schema exists, the description covers purpose, parameters, and usage comprehensively. It is complete for a read-only tool with strong annotations.
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 descriptions for each parameter. The description reiterates the optional scoping but doesn't add significant new 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 clearly states the tool returns the observatory's public calibration scorecard with detailed accuracy metrics. It distinguishes itself from sibling tools (e.g., describe_corridor, list_places) by focusing on historical forecasting 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?
Explicit usage context: 'Use when an agent or user wants to assess Zoning Signal's historical forecasting accuracy before citing a current prediction.' Also notes optional scoping, implying when parameters are useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_corridorsList CorridorsARead-onlyIdempotentInspect
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?
Annotations already declare safe read-only, idempotent behavior. The description adds valuable context: it explains the corridor concept and lists return fields, going beyond what annotations provide. No hidden side effects are implied.
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 with no wasted words. The action is front-loaded ('List every published corridor page.'), followed by a clear definition of the corridor concept and a brief summary of return fields.
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 zero parameters and an existing output schema, the description covers all essential information: what the tool does, what it returns, and the conceptual context. No gaps remain for an AI agent to correctly invoke the 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?
With zero parameters and 100% schema coverage, the description need not add parameter details. It remains concise and does not repeat schema information. Baseline 4 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 a specific verb ('List') and resource ('corridor pages'), clearly defining what the tool does. It distinguishes from siblings like 'describe_corridor' and other 'list_*' tools by specifying the corridor concept and scope.
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 clearly indicates when to use the tool (when you need a list of all published corridors) and provides enough context for an AI agent to understand its purpose. However, it does not explicitly state when not to use it or mention alternatives like 'describe_corridor' for single-corridor details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_entitiesList EntitiesARead-onlyIdempotentInspect
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?
Adds significant context beyond annotations: explains return taxonomy, class-specific summary fields, cross-reference counts, and schema_id stability. No contradiction with annotations.
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 purpose, then details. Somewhat long but every sentence adds value; well-structured.
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?
Covers purpose, usage, filtering, pairing, and output details. Output schema exists, so no need to describe return values. Complete for a list 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%, baseline 3. Description adds extra context by explaining class-specific meanings for entity_class values, enhancing 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 'List every named entity in the Decoder Index' and specifies the taxonomy and fields. It distinguishes from sibling tools like describe_entity by positioning as a discovery surface.
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?
Provides guidance to 'use as the discovery surface' and 'pair with describe_entity for full structured detail.' Implicitly suggests when to use, but does not explicitly exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_meetingsList MeetingsARead-onlyIdempotentInspect
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns meeting readings, can be called with no args for full corpus, and explains filtering behavior (case-insensitive substring, date range). 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, front-loaded with the core purpose. Every sentence adds value with no fluff. The structure is efficient and easy to parse.
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?
Has an output schema (though not shown), with description clarifying response shape same as meeting_index. Covers all parameters and use case (full corpus, date range, jurisdiction filter). Complete for a read-only enumeration 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%, so parameters are well documented. The description adds value by providing a practical example ('minneola') and clarifying that jurisdiction is a substring filter. It also hints at date range semantics (no required parameters).
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 verb 'return', the resource 'meeting readings', and the scope 'across all cities' with optional filters. It also distinguishes from the sibling 'meeting_index' by noting the same response shape but 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?
The description explicitly says when to use: 'when you need to enumerate the full meeting record or scan across cities by date range.' It mentions no required parameters and provides an example of filtering. It does not explicitly mention when not to use or alternative tools beyond meeting_index.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_patternsList PatternsARead-onlyIdempotentInspect
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is not needed for safety disclosure. However, it adds useful behavioral context such as the list nature, returned fields, and canonical URL pattern.
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?
Description is somewhat lengthy (includes Phase 12 historical note) but well-structured and front-loaded with the core purpose. 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 0 parameters, full annotations, and an output schema, the description sufficiently covers the tool's behavior, return fields, and relationship to sibling tools.
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 (0 params, schema coverage 100%). Baseline for 0 params is 4; description does not need to add param details.
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 verb ('List'), resource ('every named pattern in the Pattern Atlas'), and scope. It differentiates from siblings like describe_pattern by noting this is the discovery surface for the Pattern Atlas.
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 clear context and suggests 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_placesList PlacesARead-onlyIdempotentInspect
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?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint false. The description adds valuable behavioral context: the rename from list_cities, alignment with canonical vocabulary, internal loader function, and the exact fields returned. 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 concise and front-loaded with the main purpose. It includes useful context but contains some technical detail (loader function) that may be unnecessary. Still efficient overall.
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?
The description lists the exact fields returned (city, state, slug, signal strength, signal direction, dossier URL) and contextualizes its role. With an output schema present, the description is sufficient to understand the tool's output.
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% for the single optional parameter 'state'. The description does not add significant detail beyond the schema's own description, but it does reiterate the filter purpose. Baseline 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 clearly specifies the verb 'list', the resource 'place dossiers', and the scope 'every place dossier (per-jurisdiction reading) the observatory publishes'. It distinguishes from siblings by noting it is for discovering place-level coverage before calling 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?
Explicitly states 'Use to discover the available place-level coverage before calling describe_place', providing clear context and ordering. It also mentions optional filtering by state, giving a specific use case.
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 ItemsARead-onlyIdempotentInspect
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's additional disclosure about returning a forward calendar adds moderate context. The description does not contradict annotations.
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: the first defines the output, the second describes filters and usage. It is front-loaded, efficient, and every sentence contributes 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 that an output schema exists, the description need not explain return values. It covers the tool's purpose, filter capabilities, and usage context. For a list tool with optional parameters, it 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?
Schema coverage is 100% with descriptions for all 5 parameters. The description mentions filtering by status, horizon, and scope, which aligns with schema but does not add new semantic meaning beyond what the schema already provides.
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 that the tool returns 'The Watch — the field's forward calendar of pending events, scheduled hearings, regulatory sunsets, and condition-triggered milestones'. It uses specific verbs 'Return' and 'Filter', and distinguishes itself from sibling tools (e.g., list_corridors, list_places) by focusing on watch items.
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 filter options (status, horizon, scope) and states 'Use to surface what the field is watching from any cognitive position.' However, it does not explicitly mention when not to use this tool or name alternative tools for different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meeting_indexMeeting IndexARead-onlyIdempotentInspect
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?
The description explains that meeting readings are 'plain-English read of one harvested planning-board, council, or commission meeting, with signal extraction and entity mapping,' adding behavioral context beyond annotations. Annotations already indicate readOnly and idempotent, and the description aligns with 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 two sentences: the first states the core functionality, the second defines 'meeting reading' and suggests usage. Every sentence adds value with no redundancy.
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 (3 params, output schema exists), the description covers purpose, output nature, and usage context. It could mention that the tool returns multiple readings per city or that it supports date range filtering, but output schema likely details the return structure.
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 does not add additional semantics beyond what the schema provides for city, to_date, and from_date. It explains the output nature but not parameter-specific details.
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 a specific verb ('Return') and resource ('meeting readings' for a city across date range). It clearly distinguishes from siblings like list_meetings (which lists raw meetings) and describe_meeting (which describes a single meeting), as meeting readings are computed extracts with signal extraction.
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 states 'Use to drill from a city or corridor into the temporal record,' providing a clear usage context. However, it does not explicitly state when not to use it or name alternative tools for different scenarios, such as using list_meetings for raw meeting lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
semantic_searchSemantic SearchARead-onlyIdempotentInspect
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?
The description discloses the embedding space (Voyage AI 4 + pgvector), ranking by cosine similarity, result threshold (0.55), maximum results (12), and the properties per hit (type, title, similarity, URL). This significantly adds context beyond the annotations (readOnlyHint, idempotentHint) which already indicate a safe, read-only 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?
The description is well-structured, front-loading the core action and corpus scope, then providing technical details and usage guidance. It is slightly verbose but every sentence adds value, striking a good balance between completeness and conciseness.
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 that an output schema exists (presumably defining the return format), the description still provides essential details about result ranking, threshold, and included fields. It fully addresses what a semantic search tool should clarify: what is searched, how results are scored, and what the output contains.
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 'q' parameter as a natural-language query. The description adds that it accepts phrases, entity names, thematic concepts, has a maximum of 500 characters, and uses asymmetric query-time embedding. This enriches the parameter understanding beyond the raw 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 explicitly states 'semantic search across the full corpus' and enumerates the types of content searched. It distinguishes from sibling tools like describe_* and list_* by explaining that this tool is for when the agent does not know the canonical entity slug or name.
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 guidance on when to use this tool: 'when the agent does not know the canonical entity slug or named-pattern title in advance.' It implies alternatives (describe_* or list_*) 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.
submit_agent_feedbackSubmit Agent FeedbackAInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True when the feedback was accepted and stored. |
| message | No | Human-readable acknowledgement. |
| category | No | The category the feedback was filed under. |
| feedback_id | Yes | Stable id for the stored feedback record. |
| received_at | No | ISO-8601 timestamp the feedback was recorded. |
| attached_invocation_count | No | How many prior invocations (from your MCP-Session-Id) were auto-attached for operator context. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (not read-only, not destructive, etc.), so the description must disclose behavior. It clearly states the submission auto-attaches prior 10 invocations, which is a key behavioral trait. It does not mention any side effects or permissions, but the non-destructive nature is implied.
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 and well-structured, with front-loaded purpose and clear categorization. Every sentence adds value, from explaining categories to describing auto-attachment. No fluff.
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 6 parameters, required fields, and an output schema, the description covers the purpose, categories, auto-attachment behavior, and how feedback is used by operators. It is complete for an agent to understand when and how to use this 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%, so baseline is 3. The description adds value by explaining the categories in detail and the purpose of auto-attachment. It also elaborates on the behavior of 'agent_context' and 'suggested_resolution', providing context 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?
The description clearly states the tool 'submit feedback to the observatory's operators about the MCP tool surface' with a specific verb and resource. It distinguishes itself from siblings, which are query-oriented tools like describe_corridor or list_corridors, by being the active counterpart to passive invocation logs.
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 implicitly guides when to use through categories like 'gap', 'error', 'praise', etc. It doesn't explicitly state when not to use or name alternatives, but the categories effectively define appropriate use cases. The auto-attach context explains a benefit that encourages use.
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!