Skip to main content
Glama
Sign In

EquiReason

by com.equireason
OverviewDiscussionsAdmin

Get a company's forward PIT history

get_company_history
Read-onlyIdempotent

Read EquiReason's forward-observed revision ledger as of an ISO date or offset timestamp. Coverage starts at the system's first capture for each domain: values before that capture are unknown, not reconstructed, and overwritten pre-ledger intraday data is not recovered. Each row carries revision, fiscal period, basis, source lineage, first-seen and observed-at. Requires signing in; financial, estimate, guidance, verdict and transcript-reading domains follow the plan's existing feature entitlements. Bounded paging with cursor/high_watermark.

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": {
      "ticker": "<ticker>",
      "as_of": "<as_of>"
    },
    "name": "get_company_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
as_ofYesISO date (YYYY-MM-DD) or timestamp with offset, e.g. 2026-11-05T14:00:00Z
limitNoRows per page (default 50)
cursorNonext_cursor from the previous page
tickerYesUS ticker, e.g. AAPL
domainsNoOptional domains; omit for all available domains
high_watermarkNohigh_watermark from the first page; pins the snapshot

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, yet the description adds substantial behavior beyond them: coverage caveats (pre-capture values unknown, overwritten pre-ledger intraday data not recovered), the exact row payload (revision, fiscal period, basis, source lineage, first-seen, observed-at), an auth requirement, entitlement gating per domain, and bounded cursor/high_watermark paging. This is rich behavioral context well beyond the annotations.

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?

The core purpose is front-loaded in the first sentence, followed by caveats, payload, auth, and paging in a logical order with no filler. The prose is dense and technical but every sentence carries information, so only slight tightening is possible.

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 no output schema, the description compensates by enumerating the row fields returned, and it covers coverage limits, auth, entitlements and paging for a six-parameter history tool. An agent has enough to call it correctly and to interpret the results.

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 earns extra credit: it explains that the financial/estimate/guidance/verdict/transcript-reading domains follow the plan's feature entitlements, and that paging is bounded via cursor/high_watermark, adding meaning beyond the field-level schema text. It still doesn't explain how high_watermark interacts with cursor beyond what the schema implies.

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 gives a specific verb and resource: 'Read EquiReason's forward-observed revision ledger as of an ISO date or offset timestamp.' That clearly describes a point-in-time history read, which is distinct from the sibling tools (get_company, get_trend, list_* etc.). It does not explicitly differentiate itself from those siblings, so it falls just short of a 5.

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?

The description implies when to use the tool ('as of an ISO date') and adds a useful constraint - that values before first capture are unknown and not reconstructed, so pre-ledger data should not be expected. However, it gives no explicit when-to-use or when-not-to-use guidance relative to the sibling tools (e.g. get_company vs get_trend) and no guidance on choosing among domains.

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

All EquiReason 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