scanner

Find direct places

find_direct_places

Read-onlyIdempotent

Places in a city that take a booking or an order on their own website, best Agent-Direct Scores first, with the direct booking or ordering link for each (the owner's corrected link where the business is claimed), the vendor behind it, verified_at when a browser reached the step before confirming, the vendor's terms for agents when noted, the hours, and follow links (https://directindex.org/go/{domain}/book, /order, /menu) that count. Use it to recommend places a person can book or order from directly, without a marketplace. Optional query: a cuisine, a dish or a few words, for example pizza, sushi, vegan, francesinha. Optional filters: lat, lon and radius_m for places near a point; open_now for places open at this moment in the city's zone (unknown hours stay in, marked null); verified_only for links a browser verified; vendor for one booking or ordering vendor (slug as on https://directindex.org/vendors). The same lists exist as pages at https://directindex.org/city/{slug}/direct, /direct/book, /direct/order and /direct/{want}; the full record of one place is available by domain.

Input Schema

Name	Required	Description	Default
`lat`	No	Latitude of the person; with lon, only places within radius_m
`lon`	No	Longitude of the person
`city`	Yes	City slug, for example lisbon; see list_cities
`want`	No	book: a table; order: food to collect or deliver; any: either	any
`limit`	No
`query`	No	What the person wants: a cuisine, a dish or a few words. Empty for any.
`vendor`	No	Only places on this booking or ordering vendor, by slug: zenchef, sevenrooms, toast ...
`context`	Yes	Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
`open_now`	No	Only places open right now by their OpenStreetMap hours, in the city's zone; places with unreadable hours stay in with open_now null
`radius_m`	No	Metres around lat, lon
`llm_model`	Yes	The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
`verified_only`	No	Only links a browser verified: an agent reached the step before confirming
`conversation_id`	No	Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 16, 2026

addedInput schema / properties / context

Added value: +{
+  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
+  "type": "string"
+}

addedInput schema / properties / conversation_id

Added value: +{
+  "description": "Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.",
+  "type": "string"
+}

addedInput schema / properties / llm_model

Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "city"
-]New value: +[
+  "city",
+  "context",
+  "llm_model"
+]

Changed6 schema fields changedOct 14, 2026

addedInput schema / properties / lat

Added value: +{
+  "description": "Latitude of the person; with lon, only places within radius_m",
+  "type": "number"
+}

addedInput schema / properties / lon

Added value: +{
+  "description": "Longitude of the person",
+  "type": "number"
+}

addedInput schema / properties / open_now

Added value: +{
+  "default": false,
+  "description": "Only places open right now by their OpenStreetMap hours, in the city's zone; places with unreadable hours stay in with open_now null",
+  "type": "boolean"
+}

addedInput schema / properties / radius_m

Added value: +{
+  "default": 1000,
+  "description": "Metres around lat, lon",
+  "maximum": 50000,
+  "minimum": 50,
+  "type": "integer"
+}

addedInput schema / properties / vendor

Added value: +{
+  "description": "Only places on this booking or ordering vendor, by slug: zenchef, sevenrooms, toast ...",
+  "type": "string"
+}

addedInput schema / properties / verified_only

Added value: +{
+  "default": false,
+  "description": "Only links a browser verified: an agent reached the step before confirming",
+  "type": "boolean"
+}

AddedOct 14, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds useful context about ranking (Agent-Direct Scores first), the follow-link domain pattern, verified_at semantics, and 'unknown hours stay in, marked null'. However, it doesn't explain pagination, total counts, or the conversation_id protocol, which is partly in the schema. 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.

Conciseness3/5

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

The description is a single very long sentence followed by more sentences, and it front-loads the core purpose well. However, it's dense and packs many concepts (ranking, links, verification, terms, hours, follow links) into one run-on sentence, making it harder to parse than necessary. It earns most of its length but could be restructured for clarity.

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?

For a 13-parameter, no-output-schema tool, the description covers the core purpose, the ranking logic, key filters, and the URL pattern for follow links. It's fairly complete, though it could mention result limits or pagination behavior. The required context and conversation_id parameters are well-documented in the schema, so the description needn't repeat them.

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 coverage is 92%, so the schema already documents all 13 parameters thoroughly, including enums and defaults. The description restates the query, lat/lon/radius_m, open_now, verified_only, and vendor semantics without adding format details beyond the schema. Baseline of 3 is correct when schema does the heavy lifting.

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 description states a specific verb and resource: finding places that take direct bookings/orders on their own site, ranked by Agent-Direct Scores, with booking links. It differentiates from siblings like search_places by the 'direct, without a marketplace' framing, though it never names the sibling it competes with explicitly.

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 clear context: 'Use it to recommend places a person can book or order from directly, without a marketplace.' It explains the optional query and filters but doesn't explicitly exclude cases where search_places would be a better choice, leaving some ambiguity about when to prefer one over the other.

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

All scanner tools Inspect

Try in Browser

Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?