SafeStreets

get_walkability_score

Read-onlyIdempotent

Score a US location on how good and how safe it is to walk, from a street address or from latitude/longitude.

Call this when someone asks whether a place is walkable, how safe it is to walk, whether they could live somewhere without a car, how a neighborhood compares to another on foot, or when evaluating a specific address or property for walkability or pedestrian risk.

The server geocodes an address itself. Coordinates estimated from memory can land on a different place, which then gets a confident score of its own. When an address is given, the reply carries resolvedFrom with the address that was matched.

Returns a JSON object: overallScore 0-100 composite displayScore the same score as 0-10, which is how SafeStreets presents it grade A to F tier plain label, e.g. "Very walkable", "Car-dependent" confidence 0-100, how much underlying data was available for this point reportUrl the full SafeStreets report for this point: map, metrics, PDF dataSources the sources that fed this specific result components four scored sub-dimensions, each with a 0-100 score and the individual metrics behind it: dailyReach errands reachable on foot streetSafety street design and pedestrian crash risk transitReach usable transit access walkingComfort shade, heat, air quality, surface

              plus networkDesign, which carries its metrics (network
              density, intersection density, block length, dead-end ratio)
              but reports score 0 at weight 0, so it does not contribute to
              the composite. Read its metrics, not its score.

              The keys safety, environmentalComfort and densityContext are
              backward-compatibility aliases of streetSafety,
              walkingComfort and dailyReach. They duplicate those objects
              rather than adding signal.

The per-component metrics are the point: you can re-weight or rebuild the composite yourself instead of trusting one number.

Coverage and limits: United States only. Pedestrian crash inputs are county-level, so two nearby points can share crash figures. Where the underlying crash record is missing, the safety component is reported as unavailable rather than guessed, and confidence drops accordingly. This does not return driving directions, transit timetables, crime statistics, or property listings.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_walkability_score"
  }
}

Input Schema

Name	Required	Description
`lat`	No	Latitude in decimal degrees, WGS84. US locations only. Required unless address is given.
`lon`	No	Longitude in decimal degrees, WGS84. Negative for the US. Required unless address is given.
`address`	No	A US street address, intersection or place name, e.g. "1200 W Foster Ave, Chicago". Give this or lat/lon. The server geocodes it, so it is the reliable input when exact coordinates are not known.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

changedInput schema / properties / address / description

Previous value: -"A US street address, intersection or place name, e.g. \"1200 W Foster Ave, Chicago\". Give this OR lat/lon. Preferred when you have not been given exact coordinates: do not guess coordinates from memory, they will score a different place and the answer will look correct."New value: +"A US street address, intersection or place name, e.g. \"1200 W Foster Ave, Chicago\". Give this or lat/lon. The server geocodes it, so it is the reliable input when exact coordinates are not known."

First observedOct 22, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive and open-world, yet the description still adds substantive behavior: the server geocodes addresses itself, coordinates recalled from memory can resolve to a different place and yield a confidently wrong score, resolvedFrom echoes the match, crash inputs are county-level, missing crash records make the safety component explicitly unavailable and lower confidence, and coverage is US-only. That is exactly the extra 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-loading is good: purpose, then triggering scenarios, then return shape, then coverage limits. Size is justified because no output schema exists and the return object is intricate, but the block documenting backward-compatibility aliases and the networkDesign weight-0 quirk, while genuinely useful, is dense and could be tightened.

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 no output schema, the description takes full responsibility for the return contract and does so field by field, including the four components, the weight-zero networkDesign caveat, and the duplicate alias keys. Combined with the explicit coverage and data-gap behavior, an agent has everything needed to call this correctly and to interpret the result.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description goes beyond by warning that hand-estimated coordinates are the unreliable path and that supplying an address offloads geocoding to the server, which is practical guidance not fully spelled out in the schema. It stops short of adding format or validation detail for lat/lon beyond what the schema states.

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

Purpose4/5

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

The opening sentence names a specific verb (score), resource (a US location), attribute (walkability and pedestrian safety), and accepted input forms (address or lat/lon). The scope makes it clearly distinct from aggregate tools like get_city_walkability or find_walkable_neighborhoods, though no sibling is named explicitly and the phrase 'how a neighborhood compares to another on foot' mildly overlaps compare_locations.

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 a concrete, well-enumerated set of triggering user questions (is this place walkable, can I live here without a car, is this property pedestrian-safe), which is stronger than implied usage. It lacks explicit exclusions or named alternatives, so the agent must infer that bulk/compare scenarios belong to compare_locations or score_many.

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

All SafeStreets tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.