Read-only Paris catalogue: events and dates, places, free things, booking links.
Scored across 6 tools
get_event, get_place, and moment_now are clearly distinct, and the two targeted searches divide cleanly along resource type. The only overlap is search_all versus search_events/search_places, but the description explicitly says to use it when the kind is unknown, which resolves most confusion.
Five of six tools follow a clean verb_noun or verb_resource pattern (get_event, get_place, search_all, search_events, search_places). moment_now breaks the pattern with a noun_adverb form, which is a minor deviation but still readable.
Six tools is well-scoped for a city-guide server: two lookups, three searches, and one contextual tool. Each earns its place without redundancy.
Events and places have both search and detail retrieval, and moment_now covers seasonal context, so core workflows are closed. However, search_all can return guides but there is no get_guide tool, leaving guides as a dead end.
Returns one event by slug: its dates, venue, subject tags, our own description where we have written one, and a booking link where we hold an offer. Use it after search_events, or when you already have an event URL.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The event's slug — the last path segment of its page URL. | |
| locale | No | Language for our own prose. The event's title is never translated. |
| Name | Required | Description |
|---|---|---|
| event | Yes | The event, with its full date list and venue resolved. |
| attribution | Yes | Who to credit and under what licence. The ODbL datasets behind most of this data require attribution wherever the data is used, including inside an answer you generate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds value beyond that by noting that two returned fields are conditional — 'our own description where we have written one' and 'a booking link where we hold an offer' — warning the agent that these may be absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the identity of the resource and the returned payload front-loaded before the usage hint. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-resource fetch with rich annotations, a full output schema, and 100%-documented parameters, the description covers what it does, when to call it, and which fields are conditionally present. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema itself explains slug as the last path segment and locale as the language for prose with title never translated, so the schema carries the semantic load. The description only restates 'by slug' and adds no format or edge-case detail beyond it — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns one event by slug') and immediately names the fields returned, so it cannot be confused with the list-oriented sibling search_events. An agent knows exactly what this tool produces without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: 'Use it after search_events, or when you already have an event URL' — naming the prerequisite sibling and the alternative entry condition. It stops short of stating when NOT to use it (e.g., bulk lookups or searching by keyword), which keeps it at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one place by slug with its address, coordinates, amenities, opening hours and how reliably it stays cool, plus the nearest other places. Use it after search_places, or when you already have a place URL.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The place's slug — the last path segment of its page URL. | |
| locale | No | Language for our own prose. The place's name is never translated. |
| Name | Required | Description |
|---|---|---|
| place | Yes | The place, with its photo credit and opening hours where we hold them. |
| nearby | Yes | Other places within walking distance, nearest first — the next stop. |
| attribution | Yes | Who to credit and under what licence. The ODbL datasets behind most of this data require attribution wherever the data is used, including inside an answer you generate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety bar is met structurally. The description adds domain context (what fields come back, including the unusual 'how reliably it stays cool') and that nearest places are included, but says nothing about not-found behavior, locale effects, or cost. Useful addition, not a rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the return payload front-loaded and the usage trigger second. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema handling return shape and annotations covering the safety profile, the description only needs to convey purpose and entry point, which it does. Minor gaps (what happens on an unknown slug, whether locale affects only prose) remain but are not blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — slug's 'last path segment of its page URL' and locale's 'name is never translated' are already documented. The description's 'by slug' and 'when you already have a place URL' only echo the schema, adding no new semantics; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns one place by slug') and enumerates the payload: address, coordinates, amenities, opening hours, coolness reliability, and nearest places. The singular 'one place by slug' cleanly separates it from search_places, so an agent can pick it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: 'Use it after search_places, or when you already have a place URL' — a clear trigger and a named alternative. It stops short of stating when-not to use it (e.g. vs. search_all or get_event), but the positive guidance is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the seasonal or cultural moment currently running in Paris — Fashion Week, Christmas, a heatwave — with its hub URL and dates, or the city's seasonal mode when none is running.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for titles and taglines. |
| Name | Required | Description |
|---|---|---|
| card | Yes | The next one alongside it, if any. |
| hero | Yes | The moment currently taking over the home page, if any. |
| attribution | Yes | Who to credit and under what licence. The ODbL datasets behind most of this data require attribution wherever the data is used, including inside an answer you generate. |
| seasonal_default | Yes | The city's mode when no moment is taking over. Always meaningful. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds genuinely non-obvious behavior: the response shape (hub URL plus dates) and, critically, the fallback to a seasonal mode when no moment is active — an agent would otherwise not know a null-ish result still carries meaning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the outcome and followed by examples and the fallback case. Every clause carries information; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero required parameters, rich annotations, and an output schema, the description covers everything needed to invoke it correctly. Only minor ambient details (what 'now' is anchored to, caching/freshness) are absent, and those are arguably outside its remit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One optional parameter with 100% schema description coverage and an enum, so the schema fully documents locale. The description adds nothing about it (e.g., default locale), which is acceptable at this coverage level but no better than baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns') and a precisely scoped resource: the seasonal/cultural moment currently running in Paris. The concrete examples (Fashion Week, Christmas, heatwave) plus the fallback case ('seasonal mode when none is running') make it unmistakably distinct from siblings like search_events or get_event, which operate on explicit entities rather than ambient city state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'currently' implies the usage context (real-time, no arguments needed), but the description never states when to prefer this over get_event or search_events, nor any exclusion. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches events, activities, places and guides at once by name or text, for when the kind of thing is not known in advance. Each hit says which kind it is and carries the slug to pass to get_event or get_place.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Restrict to one kind. Omit to search everything. | |
| limit | No | Defaults to 20. | |
| query | Yes | What to look for. At least two characters — one matches most of the catalogue. | |
| offset | No | For paging. |
| Name | Required | Description |
|---|---|---|
| hits | Yes | Matches across every kind, best first. |
| total | Yes | How many this response carries. |
| counts | Yes | How many matched per kind — useful for saying 'also 12 places' without a second call. |
| attribution | Yes | Who to credit and under what licence. The ODbL datasets behind most of this data require attribution wherever the data is used, including inside an answer you generate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value beyond that by describing the shape of a hit: each carries its kind plus a slug usable with get_event/get_place. Pagination and limit behavior are left entirely to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero padding, and the most decision-relevant clause (searching across kinds when the kind is unknown) comes first. The follow-up routing information is packed into the second sentence rather than expanded into a paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return values are covered by an output schema, safety by annotations, and all parameters by a fully described schema; the description fills the remaining gaps (cross-kind search purpose, what a hit contains, where to go next). Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (query, type, limit, offset) are already documented with defaults, bounds and enum values. The description only adds 'by name or text', a light hint about how query matches; it says nothing about type/limit/offset beyond what the schema states. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (searches) and enumerates the resources covered (events, activities, places, guides) plus the cross-cutting scope ('at once'). The phrase 'for when the kind of thing is not known in advance' lets an agent distinguish it from the narrower search_events and search_places siblings 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear selecting condition ('when the kind of thing is not known in advance') and routes the follow-up step to get_event or get_place via the returned slug. It never names search_events or search_places as the alternative for known-category searches, so the sibling-routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds dated events in Paris by time window, subject, price, free text or distance from a point. Returns each event with its page URL and, where we hold one, a booking link. Relaxes the window or radius when fewer than three events match, and says so in relaxed.
| Name | Required | Description | Default |
|---|---|---|---|
| free | No | Only events with free entry. | |
| near | No | Restrict to a radius around a point in the Paris area. | |
| when | No | Time window. Mutually exclusive with date_from/date_to. | |
| limit | No | Defaults to 20. | |
| query | No | Free text over title, venue and organiser. | |
| locale | No | Language for our own prose. Event titles and place names are never translated. | |
| offset | No | For paging. | |
| date_to | No | Paris day, YYYY-MM-DD. Inclusive. Defaults to date_from. | |
| date_from | No | Paris day, YYYY-MM-DD. | |
| interests | No | Filter by subject. Read the `interests` resource for the list. | |
| price_max | No | Budget ceiling in EUR. |
| Name | Required | Description |
|---|---|---|
| items | Yes | The matching events, in the order we would show them. |
| total | Yes | How many this response carries. |
| window | Yes | The date window actually searched, after any relaxation. |
| relaxed | Yes | Empty when the search ran as asked. Otherwise the steps taken to find anything at all — tell the reader, because the answer is no longer exactly what they asked for. |
| attribution | Yes | Who to credit and under what licence. The ODbL datasets behind most of this data require attribution wherever the data is used, including inside an answer you generate. |
| match_count | Yes | Matches across every page. Null means we could not determine it — never zero. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description focuses on non-obvious behavior: it silently relaxes the time window or radius when fewer than three events match and flags that in `relaxed`. That is exactly the kind of side effect an agent cannot get from structured fields. It does not mention rate limits or what the relaxed result looks like beyond the flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with zero filler: capability first, return shape second, non-obvious relaxation behavior last. Each sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter, all-optional tool with an output schema, the description covers capability, return contents and the surprising relaxation rule. The one gap is default behavior on an empty call, which matters given zero required parameters and a limit/offset paging model.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter, including nested lat/lng/radius_km and the when-vs-date_from exclusivity, is already documented in the schema. The description's phrase 'by time window, subject, price, free text or distance' merely restates those parameters without adding format or precedence detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ('Finds dated events in Paris') and enumerates the filter dimensions (time window, subject, price, free text, distance). It implicitly separates itself from get_event (single event) and search_places (places), but never names the closest sibling search_all, so differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope ('dated events in Paris') implies when this tool applies, and the mention of a distance filter hints at geo use, but there is no explicit when-to-use guidance, no exclusion of search_all/search_places, and no statement about what an empty call does with 11 optional parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds cafés, parks, museums, pools, libraries and other places in Paris by kind, amenity, whether they are open now, or distance from a point. Each place carries how reliably it stays cool, what it suits, and its page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | Sort by distance from a point in the Paris area instead of by arrondissement. | |
| wifi | No | Only places with verified wifi. | |
| limit | No | Defaults to 20. | |
| query | No | Free text over name and address. | |
| locale | No | Language for our own prose. Place names are never translated. | |
| offset | No | For paging. | |
| category | No | Restrict to one kind of place. | |
| good_for | No | What the visitor wants to do there: work, study, shelter, family, quick_cool. | |
| open_now | No | Only places open at the time of the call. | |
| free_entry | No | Only places you can enter without paying. | |
| power_outlets | No | Only places with verified power sockets. | |
| has_air_conditioning | No | Only places with verified AC. |
| Name | Required | Description |
|---|---|---|
| items | Yes | The matching places, in the order we would show them. |
| total | Yes | How many this response carries. |
| attribution | Yes | Who to credit and under what licence. The ODbL datasets behind most of this data require attribution wherever the data is used, including inside an answer you generate. |
| match_count | Yes | Matches across every page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that results carry a cool-reliability signal, suitability tags and a page URL – a useful hint, but it says nothing about result volume, ordering defaults, or what empty results mean.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the resource and scope front-loaded and the return-value note trailing. Nothing in it is redundant padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 optional parameters, 100% schema coverage, an output schema, and rich annotations, most of the informational burden is already carried by structured fields. The description supplies the domain framing (Paris places, cooling-oriented attributes) that structured data doesn't, though it omits any note on result limits or paging behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter (including the nested `near` lat/lng bounds and the enums for category and good_for) is documented in the schema. The description only restates the filter categories generically, adding no syntax, defaults, or combination semantics beyond what the schema already carries, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Finds ... places in Paris') and enumerates both the filtering axes (kind, amenity, open now, distance) and the notable return fields (cool reliability, what it suits, page URL). It never names its siblings, so an agent can't tell from the description alone why it should pick this over search_all or get_place.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by kind, amenity, whether they are open now, or distance from a point' implies the filtering workflows this tool is for, but there is no explicit when-to-use/when-not or pointer to alternatives like get_place for a single place or search_all for a broader sweep. Usage is inferable, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_eventget_placemoment_nowsearch_allsearch_eventssearch_placesUpcoming events and outings in Paris and Île-de-France, plus permanent places across France.
French cultural events search with multi-reseller ticket price comparison (theatre, concerts...)
Live events in 50 cities: AI/tech meetups, hackathons, conferences, concerts. Free, read-only.
Read-only search of cultural and nightlife events in Bizkaia (Basque Country, Spain).
Add one secure layer between your agents and this server.
