Skip to main content
Glama
mavrovde

ViaFrei

by mavrovde
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

find_address

Read-onlyIdempotent

Looks up a street address: its coordinate, and the named OpenStreetMap objects at it (company, shop, office) or that none are.

Instructions

Looks up a street address: its coordinate, and the named OpenStreetMap objects at it (company, shop, office) or that none are. Use when the person gives a STREET AND NUMBER — "Bahnhofstraße 12, Fulda" — for the point or the business there, never who lives there. The coordinate passes to any other tool as lat/lon. Do NOT use for a town/district/station name alone (find_place) or a company/shop/landmark by name (find_poi). At most 5 points; a door mapped twice is folded, points far apart say how far; several towns are a question. OpenStreetMap ODbL 1.0; show the attribution line.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many results to return (1–5, default 3) — more than one means the same address carries more than one OpenStreetMap object.
queryYesA street address, as a person writes one: street and house number, plus a town or postcode — "Bahnhofstraße 12, 36037 Fulda" or "Bahnhofstraße 12, Fulda". Both orders work. A street and number with neither a town nor a postcode cannot be placed (the same street name exists in about two thousand German towns) and is refused.
languageNoSet this on every call to the language the person is writing in: "en" if they wrote English, "de" if they wrote German. Do not leave it out: it defaults to German ("de"), which is only the fallback when the language is genuinely unclear, so an English question sent without it is answered in German — a wrong answer. Place names, station names and road numbers are never translated in either language; in English the German term is kept in parentheses so the person recognises it on signs and in local apps.de

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.18
    • changedInput schema / properties / language / description
      Previous value: -"Set this on every call to the language the person is writing in: \"en\" if they wrote English, \"de\" if they wrote German. Do not leave it out because it has a default — the default is only the fallback when the language is genuinely unclear, and an English question answered in German is a wrong answer. Place names, station names and road numbers are never translated in either language; in English the German term is kept in parentheses so the person recognises it on signs and in local apps."New value: +"Set this on every call to the language the person is writing in: \"en\" if they wrote English, \"de\" if they wrote German. Do not leave it out: it defaults to German (\"de\"), which is only the fallback when the language is genuinely unclear, so an English question sent without it is answered in German — a wrong answer. Place names, station names and road numbers are never translated in either language; in English the German term is kept in parentheses so the person recognises it on signs and in local apps."
  2. Changed1 schema field changedv1.8.29
    • changedInput schema / properties / query / description
      Previous value: -"A street address, as a person writes one: street and house number, plus a town or postcode — \"Hauptstraße 12, 36037 Fulda\" or \"Hauptstraße 12, Fulda\". Both orders work. A street and number with neither a town nor a postcode cannot be placed (the same street name exists in about two thousand German towns) and is refused."New value: +"A street address, as a person writes one: street and house number, plus a town or postcode — \"Bahnhofstraße 12, 36037 Fulda\" or \"Bahnhofstraße 12, Fulda\". Both orders work. A street and number with neither a town nor a postcode cannot be placed (the same street name exists in about two thousand German towns) and is refused."
  3. Changed1 schema field changedv1.7.3
    • addedInput schema / properties / query / maxLength
      Added value: +160
  4. Addedv1.4.8

TDQS

A4.6/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, closed-world, but the description adds real behavioral detail beyond them: a hard cap of 5 points, deduplication of a door mapped twice, distance reporting for far-apart points, handling of multi-town results as a question, and an ODbL 1.0 attribution obligation. That is material context annotations do not carry.

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-loads the purpose and immediately follows with the disambiguating rules, then edge cases and licensing. It is dense and every sentence carries information, though the run-on construction packs several distinct rules into single sentences and could be separated slightly more cleanly.

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 compensates by explaining what is returned (coordinate plus named objects or none) and how the coordinate is reused by other tools. Required input constraints, the multi-result ceiling, dedup behavior, and the legal attribution requirement are all covered for a tool of this complexity.

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 query, limit, and language, including the town/postcode requirement and the language default. The description mostly reinforces these rather than adding new parameter meaning; the lat/lon pass-through is a downstream usage hint, not an input detail. Baseline 3 is appropriate.

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 (looks up a street address) plus exactly what it returns (coordinate + named OSM objects at it, or none). It explicitly names the siblings it is not (find_place, find_poi) and the input shape that selects it, so an agent can distinguish it without opening any schema.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('person gives a STREET AND NUMBER'), an explicit exclusion ('never who lives there'), and routes two alternative cases to named siblings (find_place for town/district/station, find_poi for named company/shop/landmark). When-to-use and when-not-to-use are both covered.

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

Deploy Server

Other Tools