LLPRO Campus

Find local businesses of one kind in one town from OpenStreetMap (name, website, phone, opening hours; credited, signed)

local_business_find

Read-onlyIdempotent

Find local businesses of one kind in one town from OpenStreetMap open data. Send kind (cafe, dentist, plumber, bakery, car repair, ... see the list in the error if yours is not known) and place (a town, suburb or district, optionally country_code like IE or US). Get up to 100 businesses, each with name, website, phone, opening hours as mapped, address, position and its OpenStreetMap link, plus a hand-off to the Hub for the next job. Signed and dated. Free, no sign-up, 50 searches a day per caller. Businesses only (no people, no e-mail addresses); the data is volunteer-mapped, so it is incomplete and sometimes out of date, and every answer says so and carries the OpenStreetMap credit (ODbL). No model, nothing about you or your search is stored. Road: Search for agents - agents that need local business lists find this tool through the Campus gateway.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>",
      "place": "<place>"
    },
    "name": "local_business_find"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	Kind of business, e.g. cafe, dentist, plumber, bakery, car repair, hairdresser.
`limit`	No	How many results to return, 1-100 (default 25).
`place`	Yes	Town, suburb or district, e.g. Galway or 'Brooklyn, New York'. Not a whole country or state.
`only_with`	No	Keep only businesses that have all of these mapped: website, phone, opening_hours.
`country_code`	No	Optional two-letter country code to pick the right town (IE, US, DE ...).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already establish the read-only, idempotent, open-world safety profile, and the description adds substantial behavior beyond that: a concrete 50-searches-per-day rate limit, ODbL credit/signed responses, explicit data-quality caveats (volunteer-mapped, incomplete, sometimes stale), a privacy statement (nothing stored), and the presence of a Hub hand-off in the result. These are exactly the operational facts an agent needs and none are recoverable from annotations or schema.

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

Conciseness3/5

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

Purpose and required inputs are front-loaded, which is good, but the paragraph then runs long with stacked clauses covering rate limits, licensing, data quality, privacy and a hand-off in one breath. The closing line ('Road: Search for agents - agents that need local business lists find this tool through the Campus gateway') reads as promotional filler rather than invocation guidance and does not earn its place.

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

Completeness4/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 carries the return-value burden and does so well, enumerating name, website, phone, opening hours, address, position, OSM link and the Hub hand-off. Rate limits, licensing and data-quality caveats are all present. The gaps are minor: the only_with filter is never explained in prose and the 'hand-off to the Hub' is named but not described.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents kind, place, limit, only_with and country_code, and the description largely restates them (kind examples, 100 cap, country_code like IE or US). The one genuine addition is the error-driven discovery path for unknown kinds, but the description never mentions the only_with filter at all, so it adds only marginal meaning over the schema. Baseline 3 applies.

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?

States a specific verb and resource ('find local businesses') with both scoping dimensions spelled out: one kind, one town. It also names the data source (OpenStreetMap) and the return contents, so an agent knows exactly what this tool produces without reading the schema. No sibling overlaps with this purpose, so no differentiation is needed.

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?

Gives concrete usage context: supply kind and place, optionally a country code, and it points out the 'list in the error' fallback when a kind is unknown. It also bounds the tool ('businesses only, no people, no e-mail addresses') and specifies a one-town scope. It stops short of explicitly naming when-not-to-use or any alternative tool, which keeps it below a 5.

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

All LLPRO Campus 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.

Resources

Need Help?