PlaceRoot

Neighborhood verdict

neighborhood_verdict

Read-onlyIdempotent

Life-decision neighborhood verdict, not a data dump.

Instructions

Life-decision neighborhood verdict, not a data dump.

Accepts a point plus free-form life context (household, mobility,
priorities) and returns a ranked verdict: strengths, weak points, and
the one thing to verify in person. Empty context still answers a
generic walk-first daily-needs check and says what was assumed.
Optional radius_m / minutes / mode override what the context implies
(no car / walk-first -> walk, bike -> cycle, car -> drive; default
walk, 15 minutes). Does not call out to extra remote APIs; the
"transit" need additionally reads base/infrastructure transit stops
(bus_stop, subway_station, ferry_terminal, ...) alongside the
places-theme categories, since places alone under-reports bus stops
(#454).

Returns a structured {"error": ...} for bad coordinates, an unknown
mode, a radius past the mode cap, upstream failure, or a degraded
schema. Missing street graph degrades to straight-line times with a
note rather than failing the verdict.

Input Schema

Name	Required	Description
`lat`	Yes
`lon`	Yes
`mode`	No	Travel mode override. Default: inferred from context, else walk.
`context`	No
`minutes`	No
`radius_m`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.10.0Aug 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: it states inference rules (no car/walk-first -> walk, bike -> cycle, car -> drive; default walk 15 min), that no extra remote APIs are called, that the transit need reads base/infrastructure stops (#454), the exact error conditions, and that a missing street graph degrades to straight-line times with a note rather than failing. This is exactly the behavioral context annotations cannot convey.

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

Conciseness4/5

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

Front-loaded with the key framing sentence and organized around purpose, inputs, behavior, and error handling. It is somewhat dense with parentheticals and an internal issue reference (#454), which slightly dilutes signal, but most sentences carry real information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return structure, yet it still names the verdict components and comprehensively covers error handling, degraded operation, and mode inference. For a 6-parameter tool it leaves nothing an agent needs in order to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 17%, so the description must carry the load, and it largely does: it defines context (household, mobility, priorities), explains that radius_m/minutes/mode override what the context implies, and gives the mode defaults. It leaves the units/limits of minutes and radius_m (beyond the 'mode cap' error note) somewhat implicit, so it falls short of fully compensating.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

State a specific verb+resource: it accepts a point plus life context and returns a ranked life-decision verdict (strengths, weak points, one thing to verify). The opening clause 'not a data dump' and the described output contrast it against sibling summarizers like summarize_area / within_distance, so an agent can pick it without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for use (a point plus free-form household/mobility/priorities context) and explicitly covers the empty-context case and the mode-override rules. It does not name an alternative tool or state a when-not-to-use condition, so it stops short of full routing guidance.

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