Skip to main content
Glama

Google Search Remote MCP Server

google_serp_events: GET /

hasdata_google_serp_events_getEventInformation

Get Google Event Details

Looks up a single Google event by the pageToken returned in a google/serp response's eventsResults array (or the ready-to-call hasdataLink next to it). Returns the venue name/rating/reviews/website/phone, a map link, a description, ticket sources (with official/unofficial flags), and the primary ticket link — details the SERP events widget does not show inline. The pageToken expires a few minutes after it is minted, so fetch it and call this endpoint promptly. Use to enrich an events search result with full venue and ticketing information.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageTokenYesToken identifying a single event, taken from the `pageToken` field of an `eventsResults` entry in a `google/serp` response. Expires a few minutes after it is minted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • removedInput schema / properties / domain
      Removed value: -{
      -  "description": "Google domain to use. Default is google.com. Provide one exact documented value (195 allowed), e.g. `google.ac`, `google.ad`.",
      -  "type": "string"
      -}
    • removedInput schema / properties / gl
      Removed value: -{
      -  "description": "The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`.",
      -  "type": "string"
      -}
    • removedInput schema / properties / hl
      Removed value: -{
      -  "description": "The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`.",
      -  "type": "string"
      -}
    • removedInput schema / properties / htichips
      Removed value: -{
      -  "description": "Filter parameter for refining event search results. Supports various filters for events. Multiple filters can be passed using a comma. The available filters are:\n\n- `date:today`: Today's Events\n- `date:tomorrow`: Tomorrow's Events\n- `date:week`: This Week's Events\n- `date:weekend`: This Weekend's Events\n- `date:next_week`: Next Week's Events\n- `date:month`: This Month's Events\n- `date:next_month`: Next Month's Events\n- `event_type:Virtual-Event`: Online Events\n\nFor example, to filter for today's online events, use: `event_type:Virtual-Event,date:today`.\n",
      -  "type": "string"
      -}
    • removedInput schema / properties / location
      Removed value: -{
      -  "description": "Google canonical location for the search.",
      -  "type": "string"
      -}
    • addedInput schema / properties / pageToken
      Added value: +{
      +  "description": "Token identifying a single event, taken from the `pageToken` field of an `eventsResults` entry in a `google/serp` response. Expires a few minutes after it is minted.",
      +  "type": "string"
      +}
    • removedInput schema / properties / q
      Removed value: -{
      -  "description": "Specify the search term for which you want to scrape the SERP.",
      -  "type": "string"
      -}
    • removedInput schema / properties / start
      Removed value: -{
      -  "description": "This parameter specifies the number of search results to skip and is used for implementing pagination. For example, a value of 0 (default) indicates the first page of results, 10 refers to the second page, and 20 to the third page.\n",
      -  "type": "number"
      -}
    • removedInput schema / properties / uule
      Removed value: -{
      -  "description": "The encoded location parameter.",
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "q"
      -]New value: +[
      +  "pageToken"
      +]
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the response payload (venue fields, map link, ticket sources with official/unofficial flags) and a critical timing constraint (pageToken expires in minutes). It omits auth/rate-limit details, but the behavioral profile is largely conveyed.

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?

Front-loads the purpose, then layers in token provenance, return contents, and the expiry warning. Slightly dense, but every sentence contributes actionable information and none is filler.

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, the description appropriately enumerates the returned fields so the agent knows what to expect. Combined with parameter sourcing and the expiry warning, an agent has enough to call the tool correctly; only auth/prerequisite context is missing.

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 already 100%, so the baseline is 3. The description adds value beyond the schema by naming two sources for the value (the `eventsResults` array field or the ready-to-call `hasdataLink`) and reiterating the expiry, which helps the agent obtain a valid token.

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 ('looks up') and resource ('a single Google event'), and clearly positions itself as the detail-enrichment step for SERP events. It is distinguishable from sibling SERP search tools because it operates on a single event via a pageToken rather than returning result lists.

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 context ('use to enrich an events search result') and an operational constraint ('fetch it and call this endpoint promptly' due to token expiry). It implies the preceding google/serp call but never names an alternative sibling or a when-not-to-use condition, so it stops short of full routing guidance.

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.