Manchester Tonight

Make a night-out plan to share

plan_night_out

Idempotent

Turn a night out you have planned with someone (or a few days out) into a Manchester Tonight plan: a link that opens the plan on manchestertonight.co.uk, where they can change it and send it to friends on WhatsApp, plus the message text. Find the stops first with whats_on or search_listings. Listed venues get their area and page filled in, and a stop with no time gets the start time of the night on at that venue that day. The first stop each day is where everyone meets. Give the plan an intro and each stop a blurb, written to the person's friends: what you'll do there, why it's a good pick, and anything to book, bring or know (opening times, dietary notes, tickets). Returns a short link that previews as a card with the plan's name, a full message and a short one; offer whichever suits (the short one or just the link is best for a group chat). The plan is kept only to serve that link, until a month after its last day.

Input Schema

Name	Required	Description
`date`	Yes	The night, or the first day: tonight, tomorrow, a weekday name, YYYY-MM-DD or DD/MM/YYYY (UK time).
`intro`	No	Optional few sentences to everyone about the plan, e.g. "Birthday week! Rough plan below, come to whatever you can."
`stops`	Yes	The stops in order. On a plan over several days, give each stop its day.
`title`	No	Optional name, e.g. "Sam's birthday". Default "Night out".
`end_date`	No	Optional last day, for a plan over several days (up to 14), in the same formats.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 18, 2026

addedInput schema / properties / intro

Added value: +{
+  "description": "Optional few sentences to everyone about the plan, e.g. \"Birthday week! Rough plan below, come to whatever you can.\"",
+  "maxLength": 600,
+  "type": "string"
+}

addedInput schema / properties / stops / items / properties / blurb

Added value: +{
+  "description": "A sentence or two for friends about this stop: what you'll do, why it's a good pick, anything to book, bring or know.",
+  "maxLength": 400,
+  "type": "string"
+}

changedInput schema / properties / stops / items / properties / note / description

Previous value: -"Optional short note, e.g. \"Book a table\"."New value: +"Older name for blurb; use blurb."

AddedOct 18, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare it is a non-read-only, open-world, idempotent, non-destructive write. The description adds genuine lifecycle context the annotations lack: the plan is persisted only to serve the link and is kept until a month after its last day, and it describes the returned preview card and message variants. It does not clarify whether repeated calls create separate links.

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?

Dense but information-bearing throughout; nearly every clause carries actionable detail (auto-fill rules, message variants, retention). The opening sentence is long and clause-heavy, so it is not maximally front-loaded, but there is little waste.

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?

No output schema exists, and the description compensates fully by describing the return (short link, preview card, full and short message) and recommending which to offer for a group chat. Combined with the retention window and stop-resolution rules, an agent has everything needed to call and use this tool correctly.

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 100%, so baseline is 3, but the description adds real semantics beyond the schema: listed venues get area and page auto-filled, a stop without a time inherits the venue's start time that day, and the first stop each day is the meeting point. That is meaningful behavioral meaning layered on top of the field docs.

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+resource: turning a planned night out into a 'Manchester Tonight plan' link with message text. It explicitly names the sibling tools used to gather stops (whats_on, search_listings), so an agent can distinguish this creation tool from the discovery tools.

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 a clear prerequisite and alternative path ('Find the stops first with whats_on or search_listings'), which routes the agent correctly. It does not state when-not to use the tool or what happens if stops are already known, so it falls short of fully explicit when/when-not guidance.

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

All Manchester Tonight 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?