Skip to main content
Glama
Sign In

Fron Research Agent API

by com.fronresearch
OverviewDiscussionsAdmin

Query venue and market data

data
Read-only

Structured rows from the Fron Research Data API (https://api.fronresearch.com/v1): markets, venues, bookable slots and a utilization and a revenue estimate per venue, market or day. Without a key every query reads one free sample day for every venue, whatever dates are asked (the response's tier, free_day and range say what was read); a caller that connects to https://fronresearch.com/api/agent with "Authorization: Bearer " reads the history its plan covers (a site's own /api/agent does not forward keys). Start with endpoint index (the sample day and endpoints), then markets or venues to get ids, then metrics. Fields, filters and how to get a key: https://fronresearch.com/data/history/

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": {
      "endpoint": "<endpoint>"
    },
    "name": "data"
  }
}

Input Schema

NameRequiredDescriptionDefault
paramsNoQuery parameters as the Data API names them, e.g. {"group_by": "market", "from": "2026-11-05", "to": "2026-11-05"}. limit (1-1000) and cursor (from next_cursor) page through lists.
endpointYesindex: the sample day, tier and endpoints. markets, venues: lists (filters: market, brand, venue_type, activity). venue: one venue with its products and resources (needs venue_id). slots: one venue's slots (params venue, from, to). metrics: one utilization and one revenue estimate per group (params group_by = market, brand, venue, venue_type or day, plus from, to (at most 92 days) and optional filters; day needs venue). observations: one slot's booking curve (param slot; needs an Investor key). polls: the first look at each slot, every look at which the count changed, and the last look, for a venue's slots on one day (params venue, date; needs an Investor key).
venue_idNoFor endpoint venue: a venue_id from venues.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / endpoint / description
      Previous value: -"index: the sample day, tier and endpoints. markets, venues: lists (filters: market, brand, venue_type, activity). venue: one venue with its products and resources (needs venue_id). slots: one venue's slots (params venue, from, to). metrics: rollups (params group_by = market, brand, venue, venue_type, activity or day, plus from, to and optional filters). observations: one slot's booking curve (param slot; needs a key on a plan that includes it)."New value: +"index: the sample day, tier and endpoints. markets, venues: lists (filters: market, brand, venue_type, activity). venue: one venue with its products and resources (needs venue_id). slots: one venue's slots (params venue, from, to). metrics: one utilization and one revenue estimate per group (params group_by = market, brand, venue, venue_type or day, plus from, to (at most 92 days) and optional filters; day needs venue). observations: one slot's booking curve (param slot; needs an Investor key). polls: the first look at each slot, every look at which the count changed, and the last look, for a venue's slots on one day (params venue, date; needs an Investor key)."
    • changedInput schema / properties / endpoint / enum
      Previous value: -[
-  "index",
-  "markets",
-  "venues",
-  "venue",
-  "slots",
-  "metrics",
-  "observations"
-]New value: +[
+  "index",
+  "markets",
+  "venues",
+  "venue",
+  "slots",
+  "metrics",
+  "observations",
+  "polls"
+]
  2. Added

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses the decisive caching behavior — "Without a key every query reads one free sample day for every venue, whatever dates are asked" — and that the response's tier/free_day/range echoes what was actually read. It also spells out the auth routing rule (a site's own /api/agent does not forward keys) and per-endpoint key requirements for observations and polls. Minor tension: it queries a remote service while openWorldHint=false, but the read-only profile is consistent.

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?

It front-loads what the tool returns before descending into auth and workflow, which is the right order. It is dense — long parentheticals and an inline URL-heavy sentence — but virtually every clause carries operational information an agent needs.

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 an eight-endpoint meta-query tool with nested params and no output schema, the description covers enough: return shape (markets, venues, slots, estimates), tier/range metadata, auth tiers, and a docs pointer. It deliberately defers field-level detail to the docs URL, which is reasonable given the endpoint-level detail already in the enum.

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 the baseline is 3, but the description adds a meaning the schema cannot: requested from/to dates are silently ignored on the keyless tier, which materially changes how `params` should be interpreted. It also ties specific endpoints to specific parameter sets (venue_id, group_by, slot, 92-day cap) and the index-first id-discovery flow.

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 description states a concrete resource and scope: "Structured rows from the Fron Research Data API" covering markets, venues, bookable slots, and utilization/revenue estimates. That is far more specific than the bare name `data` and the title. It does not, however, contrast itself with the `about`/`fetch`/`search` siblings, so an agent must infer the boundary.

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?

Explicit in-tool sequencing is given: "Start with endpoint index (the sample day and endpoints), then markets or venues to get ids, then metrics." That is a real onboarding path an agent can follow. It stops short of naming when another tool (e.g. `search`) is the better choice, so it is clear context without exclusions.

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

All Fron Research Agent API toolsInspect
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