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). 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "performer": "<performer>"
    },
    "name": "resolve_intent"
  }
}

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.6/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, non-destructive, closed-world), and the description goes well beyond them with real matching policy: TBD definitions, the two-year cutoff, exclusion of parking and cancelled listings, conditional matching of tribute/themed shows, precedence between certain and if-necessary dates, the 24-hour meaning of same_day, and duplicate collapsing. A large share of the text instead enumerates return fields already implied by the output schema, which slightly dilutes the behavioral value.

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?

It is front-loaded with purpose, which is good, but the middle is a dense run-on listing of array fields and nested fact keys with heavy parentheticals. Much of that space restates the output schema rather than adding decision-relevant information for the caller.

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 100% schema coverage, full annotations, and an output schema, the description is comfortably complete on behavior and result interpretation. Its remaining gap is routing: nothing tells the agent when to prefer resolve_intent over search_events or search_performers in the sibling set.

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 all six parameters are documented in the schema itself, including the event_date versus date_text distinction and the limit cap. The description adds no per-parameter meaning beyond that baseline, so this sits at the standard 3.

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 opening sentence gives a specific verb and resource: resolve a post's words to the XP catalog event it refers to, with the added stance that 'XP decides the match, not the reader.' That is far clearer than the title alone, but it never contrasts itself with the sibling search_events, so an agent must infer the boundary between resolving free text and running a search.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the tool is for turning post language into a single best event, and the precedence rules (upcoming certain show beats a past one; cancelled and parking listings never match) hint at when it is appropriate. There is no explicit when-to-use/when-not-to-use guidance and no mention of search_events as the alternative for open-ended browsing.

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