Skip to main content
Glama
Sign In

getresearch: the Data Research door

by io.github.allooloo
OverviewDiscussionsAdmin

Get the research page of an issuer

get_research
Read-onlyIdempotent

The page is the record's research on the issuer — no analyst, no rating, no view. get_research is Data Research: one research page per listed company on the record, written from the signed record — identity and listing, the disclosure read (filings in the trailing twelve months, cadence, latency against the issuer's exchange and sector), auditor, events and halts, orderability, coverage, open research, licensed (none loaded), as-of depth and sources — with its as-of date and its receipt. Input: ticker with exchange, or ISIN, or LEI. Output: the page (sections and Markdown), its numbers with the source page and read date of every value, its as-of date, the signature and the RCO receipt. Typed errors: unknown_issuer, ambiguous, no_page, invalid_request. Page: https://getresearch.ai/

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_research"
  }
}

Input Schema

NameRequiredDescriptionDefault
leiNoLEI (20 characters).
isinNoISIN (12 characters).
tickerNoTicker (AAPL), with exchange in the exchange argument or as NASDAQ:AAPL.
exchangeNoExchange for the ticker (NASDAQ, NYSE, LSE, TSX, …).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the safety profile is settled. The description goes further, disclosing that the page is written from a signed record, that it carries an as-of date, a signature and an RCO receipt, and it enumerates typed errors (unknown_issuer, ambiguous, no_page, invalid_request) — real behavioral context an agent cannot get from annotations.

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?

The lead sentence with the negative scope is well front-loaded, but the rest is a single run-on sentence stuffing an exhaustive section inventory (filings, cadence, latency, auditor, halts, orderability, coverage…) that inflates length without changing how the tool is called. It is informative but bloated.

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 a read tool with rich annotations and a fully documented schema, the description covers inputs, the returned structure (sections, Markdown, per-value source page and read date, as-of date, signature, receipt) and the error taxonomy. No output schema exists, yet the return shape is described well enough to plan a call; a short note on volume or pagination is the only visible gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is already 3, but the description adds the disjunctive identifier rule — 'ticker with exchange, or ISIN, or LEI' — which is exactly the semantic the schema cannot express given zero required parameters. It also clarifies that ticker must be paired with exchange or given as NASDAQ:AAPL.

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?

Names a specific verb and resource ('Get the research page of an issuer') and scopes the content negatively ('no analyst, no rating, no view'), which separates it from analyst/rating style siblings. It does not explicitly contrast with get_record or get_signal, so the differentiation from the closest data siblings is left to inference.

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 only implied: 'one research page per listed company on the record' plus the list of sections tells the agent what it retrieves, and 'no analyst, no rating, no view' rules out content kinds. There is no explicit when-to-use-this-vs-alternatives statement (e.g. versus get_record or get_signal) and no stated prerequisites.

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

All getresearch: the Data Research door 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