Skip to main content
Glama
YichengYang-Ethan

oracle3

by YichengYang-Ethan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_relations

Read-only

List saved market relations from the local oracle3 store, optionally by status, market, or spread type, to reuse pairs offline or find one for check_constraint_live.

Instructions

List the market relations saved on this machine by the oracle3 research CLI, optionally filtered.

Reads ~/.oracle3/relations.json with no network calls. Use it to reuse pairs
already discovered or validated offline, then pass a pair to
check_constraint_live. For the abstract relation kinds and their bounds,
call list_relation_types instead. Returns the store path, a count and the
matching relations (markets, type, status and validation details); the list
is empty if the CLI has saved none.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoOnly this lifecycle status: discovered, validated, deployed, retired or invalidated. Empty returns all.
market_idNoOnly relations that include this market id (Kalshi ticker or Polymarket id). Empty returns all.
spread_typeNoOnly this relation type: same_event, cross_platform, implication, exclusivity, conditional, structural, cointegration or complement. Empty returns all.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.2.2
    • addedInput schema / properties / market_id / description
      Added value: +"Only relations that include this market id (Kalshi ticker or Polymarket id). Empty returns all."
    • addedInput schema / properties / spread_type / description
      Added value: +"Only this relation type: same_event, cross_platform, implication, exclusivity, conditional, structural, cointegration or complement. Empty returns all."
    • addedInput schema / properties / status / description
      Added value: +"Only this lifecycle status: discovered, validated, deployed, retired or invalidated. Empty returns all."
  2. First observedv1.2.1

TDQS

A4.4/5.0
Behavior4/5

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

The description adds real behavioral context beyond the annotations: it reads ~/.oracle3/relations.json and makes no network calls, and notes the list is empty if nothing has been saved. readOnlyHint and openWorldHint=false already cover the safety/offline profile, but the concrete file path is useful added detail.

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-loaded with the core action, then file/read behavior, then routing guidance, then return summary. Every sentence carries information, though the return-details run slightly long given an output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full output schema present and 100% parameter coverage, the description need only establish purpose, usage and environment. It does all three, including the offline/local-file nature and the empty-result case, so an agent can call it correctly.

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 the schema already documents the status, market_id and spread_type filters including their empty-value semantics. The description only restates that results are optionally filtered and adds no filter syntax or format detail, so the baseline 3 applies.

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 (List) and resource (market relations) plus the precise scope (saved on this machine by the oracle3 research CLI, optionally filtered). It explicitly names the sibling list_relation_types as the tool for the different concept of abstract relation kinds, so an agent can separate them without opening schemas.

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

Usage Guidelines5/5

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

Gives explicit when-to-use (reuse pairs already discovered or validated offline) and what to do next (pass a pair to check_constraint_live). It also cleanly routes to an alternative for the abstract relation kinds via list_relation_types.

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

Deploy Server

Other Tools