suburbs_shapes_busy_roadsBusy-road line segments clipped to the suburb — the report's road-noise exposure proxy.
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | No | When false, geometry is dropped — every Feature keeps its `properties` but its `geometry` is null. Use it to fetch the counts and per-feature attributes without the coordinates (default true — response unchanged). | |
| suburb_name | Yes |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -{
- "properties": {
- "available": {
- "anyOf": [
- {
- "type": "boolean"
- },
- {
- "type": "null"
- }
- ],
- "description": "`false` on no-data responses. Omitted on success — branch on `data !== null` if you want a single discriminator.",
- "title": "Available"
- },
- "data": {
- "anyOf": [
- {
- "additionalProperties": true,
- "description": "Busy-road segments (road-noise proxy) clipped to the suburb.",
- "example": {
- "area_level": "suburb",
- "area_name": "Belmont North",
- "count": 71,
- "geojson": {
- "features": [
- {
- "geometry": {
- "coordinates": [
- [
- 151.66,
- -32.99
- ],
- [
- 151.67,
- -33
- ]
- ],
- "type": "LineString"
- },
- "properties": {
- "road_class": "primary"
- },
- "type": "Feature"
- }
- ],
- "type": "FeatureCollection"
- }
- },
- "properties": {
- "area_level": {
- "const": "suburb",
- "description": "Always 'suburb'.",
- "title": "Area Level",
- "type": "string"
- },
- "area_name": {
- "description": "Canonical ABS SAL name.",
- "title": "Area Name",
- "type": "string"
- },
- "count": {
- "description": "Number of road-segment features returned.",
- "title": "Count",
- "type": "integer"
- },
- "geojson": {
- "additionalProperties": true,
- "description": "GeoJSON FeatureCollection — line geometries of busy road segments clipped to the suburb boundary. Properties: `road_class` (OSM fclass, e.g. motorway/primary/secondary). Geometry is null on every Feature when the request passes `?geojson=false`.",
- "title": "Geojson",
- "type": "object"
- }
- },
- "required": [
- "area_name",
- "area_level",
- "count",
- "geojson"
- ],
- "title": "SuburbBusyRoads",
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "The endpoint's payload, or `null` when Microburbs has no value."
- },
- "message": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Human-readable explanation. Omitted on success.",
- "title": "Message"
- },
- "reason": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Machine-readable slug naming the no-data condition (e.g. `no_avm_for_GANSW704074813`). Stable per endpoint. Omitted on success.",
- "title": "Reason"
- }
- },
- "title": "ApiResponse[SuburbBusyRoads]",
- "type": "object",
- "x-fastmcp-top-level-schema": "ApiResponse_SuburbBusyRoads_"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds the clipping-to-suburb context and the proxy purpose, but does not disclose additional behavioral details such as error handling or performance. With annotations covering safety, a 3 is appropriate.
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?
A single, front-loaded sentence that communicates the core purpose without any waste. It is concise and to the point, ideal for quick comprehension.
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 simple tool with two parameters and no output schema, the description plus annotations and schema are largely sufficient. It could note the geojson option but that is covered in the schema, so the missing piece is minor.
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 50% (only geojson is documented). The description does not mention either parameter, nor does it compensate for the undocumented suburb_name. Since the description adds no parameter meaning, it scores low.
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 exactly what the tool does: returns busy-road line segments clipped to a suburb, and positions it as the road-noise exposure proxy. This clearly distinguishes it from sibling shape tools like noise_heatmap (heatmap vs segments) and boundary/mesh_blocks tools.
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 provides clear context (use for road-noise exposure proxy) but does not explicitly mention when not to use it or name alternatives like suburbs_shapes_noise_heatmap. Since the context is clear and no exclusions are needed, it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.