Skip to main content
Glama

Resolve Event From Post

resolve_intent
Read-only

Find the XP event a post means, from the words it uses. XP decides the match, not the reader.

Returns ranked candidates [{event_id, name, venue, city, date_utc, score (0-1), why, facts: {country, hours_until (null when the date or time is TBD), date_tbd, started, same_day}}], ambiguous (why no single event wins, e.g. "3 nights at Sphere", else null), match (matched, ambiguous or not_in_catalog: only whether XP found the event) and, when matched, verdict for the top candidate: {qualified, reason (null, non_us, unknown_country or past_event), rule_set}. Same-day and date-TBD events qualify; a postponed event or a date more than two years out counts as TBD. Parking listings and cancelled events never match, and a tribute, themed or inspired show or a season-ticket package matches only when the post says so. An upcoming, certain show beats a past or if-necessary one unless the post names that date. same_day means within 24 hours, or today at the venue when only the time is TBD. Duplicate listings resolve to one event.

Input Schema

NameRequiredDescriptionDefault
cityNoCity as written, e.g. 'Chicago' or 'Chicago, IL'.
limitNoHow many candidates to return (max 20).
venueNoVenue as written, e.g. 'Soldier Field'.
date_textNoThe date as the post words it when there is no exact date, e.g. 'this weekend'.
performerYesArtist or teams as the post writes them, e.g. 'Bears vs Packers'.
event_dateNoEvent date when the post gives one (YYYY-MM-DD).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.5/5.0
Behavior5/5

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

Beyond the readOnly/openWorld=false annotations, the description discloses substantive behavior: parking listings and cancelled events never match, tribute/themed/inspired shows only match on explicit mention, postponed or >2-year-out dates count as TBD, duplicate listings collapse to one, and same_day means within 24 hours. These are exactly the operational rules an agent needs and none are in the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

A large share of the text enumerates return fields (`match`, `verdict`, `facts`, `score`, `why`) that an output schema already declares, which is wasted budget. The genuinely valuable matching rules are buried mid-paragraph in a dense wall of prose, so the most decision-relevant content is not front-loaded.

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 fuzzy natural-language resolution tool this covers the hard parts: candidate ranking, ambiguity signaling, disqualifiers, date edge cases, and verdict reasons. With annotations carrying safety and an output schema carrying shape, only recovery guidance (e.g., narrow with city/venue and retry) and a gloss on "XP" are missing.

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 performer/city/venue/date_text/event_date are already documented with examples; the baseline is 3. The description adds only the implicit hint that inputs are 'the words the post uses' (i.e., verbatim, unnormalized text) and that XP, not the caller, decides the match — no per-parameter detail beyond the schema.

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?

"Find the XP event a post means, from the words it uses" gives a specific verb (resolve/find) and resource (event) plus the input source (free-text post), which distinguishes it from structured siblings like search_events or search_performers. It stops short of naming any sibling explicitly, and "XP event" is internal jargon an agent may not know.

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

Usage Guidelines2/5

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

The text is dominated by match-resolution policy (what qualifies, what never matches), not by when-to-use guidance. Nothing states when to reach for this over search_events or get_event_details, nor what to do when the result is `not_in_catalog` or `ambiguous` — the agent must infer routing from the tool name alone.

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.

Resources