Skip to main content
Glama

Plan a night out

drinkedin_plan_night_out
Idempotent

Plan a walkable 2-4 stop night out around a place using only venues DrinkedIn has validated against the venue's own site or an official register. Free. Saves the planned route (public venue data only, 30 days) so it can be shared; never saves the user's location. The most reliable input is a point: give latitude and longitude. Choose it from the user's context, never from a default: 'near me' is the user's current location; an area the user names (a neighbourhood or district) is the centre of that area; for a trip the user is planning, look up the destination they name (use its country to pick the right place) and give its coordinates. If the context holds no location, ask the user. With no coordinates, a free-text address or landmark in address also works: it is geocoded to one point and planned like coordinates (coordinates win if both are given). The text is sent to a public geocoding service (OpenStreetMap Nominatim), which ranks matches and does not confirm them: the reply's geocoded_as says what it matched, so confirm that with the person when the text was ambiguous. A place name also works when it identifies one place, so give it with its country or region; a name several places share returns needs_input with labelled choices: pick the one that fits the user's context and call again with its place_key or coordinates. Never guess between choices. Walking times are estimates (straight line x 1.3). Hours and prices are never asserted: tell the user to check with the venue (its own site when the stop has own_site). Say the plan is for adults of legal drinking age where they are; never state an age as a number. If the user says they are under the legal drinking age, do not call this tool. Show only the stops returned and add no venues, details or place names of your own.

Input Schema

NameRequiredDescriptionDefault
cityNoCity name. Add the country or state when several places share the name.
nearNoWhat the point stands for, e.g. 'near me' or the area the user named. Echoed back as the route's 'near_as_given'; it is your label, not ours, and never changes the plan.
stopsNo
styleNoOptional route shape, from the styles in drinkedin_get_guide. It limits which kinds of place the route uses and sets the default stops and walking limit; your own stops and max_walk_m win. It says nothing about hours, prices or atmosphere. Too few matching venues gives partial or no_coverage, never other kinds of place. The reply echoes style_applied.
vibesNoFrom drinkedin_get_guide. Vibes we cannot verify yet are noted, not applied.
budgetNoAccepted but ignored: never used to filter or sort the route; prices are not known. The reply adds the notice budget_not_verifiable.
regionNoState or province, a name or a code such as a two-letter US state code; narrows a name several places share.
addressNoOptional free text: a street address, a landmark or the name of an area, used only when no latitude and longitude are given. It is geocoded to one point and planned like coordinates. The address is sent to a public geocoding service (OpenStreetMap Nominatim) to find the point. The reply echoes geocoded_as and geocoded_point with the notice address_geocoded: a match is a ranking, not a confirmation, so confirm it with the person when the text was ambiguous. No match is needs_input.
countryNoCountry name or code; narrows a name several places share.
languageNoen
latitudeNo
longitudeNo
place_keyNoFrom a needs_input answer: names exactly one of its choices.
max_walk_mNo
party_sizeNoInformational only: does not change the route.
start_timeNoLocal HH:MM. Informational only: does not change the route.
exclude_idsNovenue_id values to leave out, to swap a stop.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / budget / description
      Previous value: -"Soft hint only; prices are not verified."New value: +"Accepted but ignored: never used to filter or sort the route; prices are not known. The reply adds the notice budget_not_verifiable."
    • addedInput schema / properties / party_size / description
      Added value: +"Informational only: does not change the route."
    • changedInput schema / properties / start_time / description
      Previous value: -"Local HH:MM, informational only."New value: +"Local HH:MM. Informational only: does not change the route."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: it saves the route for 30 days with public venue data only and never the user's location, sends free text to a public Nominatim geocoder, and warns that walking times are straight-line × 1.3 and that hours/prices are never asserted. These are exactly the side effects and limits an agent needs before invoking an openWorld, non-read-only tool.

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 is front-loaded, but the body is one dense block where geocoding behavior and the 'geocoded_as is a ranking, not a confirmation' caution are stated twice (once for address, once for place names). The content is valuable, but it reads as a wall of prose rather than ordered guidance.

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, 17 parameters and nested objects, the description still covers the important reply signals: geocoded_as, geocoded_point, style_applied, near_as_given, needs_input with labelled choices, partial/no_coverage, and budget_not_verifiable. It stops short of describing the shape of a returned stop list beyond mentioning own_site, which is the main remaining gap.

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 71%, and the description fills the most consequential gaps: precedence of latitude/longitude over address, that 'near' is only an echoed label and never filters, that place_key comes from a needs_input choice, and that budget is accepted but ignored (producing budget_not_verifiable). It says little about language, stops, or max_walk_m bounds, which the schema already carries.

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?

Opens with a specific verb and resource — 'Plan a walkable 2-4 stop night out around a place' — and narrows it to venues 'validated against the venue's own site or an official register'. It also differentiates itself from the sibling by deferring styles/vibes to drinkedin_get_guide, so an agent can tell the two apart without opening either 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?

Explicitly states when to use coordinates vs address vs place name, the precedence rule ('coordinates win if both are given'), how to derive the point from user context ('never from a default'), and what to do when the result is needs_input. It also names exclusions: never guess between choices, and do not call the tool at all if the user says they are under the legal drinking age.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.