Skip to main content
Glama

get_company_snapshot

Read-only

Fetch a structured, POINT-IN-TIME company snapshot — no report generation needed.

Returns thesis/bull/bear, financial overview (Piotroski, valuation signal),
price performance + technical indicators, price targets, institutional
ownership, and analyst grades for `symbol`. Synchronous and cheap — prefer
this for a quick CURRENT read instead of generating a full PDF report.

*** POINT-IN-TIME ONLY — THIS IS NOT A TIME SERIES. *** It captures where the
company stands right now, not how it got there. Do NOT use it to answer
temporal / trend / "over time" questions (e.g. "how has X evolved over the
past year", "quarter-over-quarter trend", "activity over the last 12 months",
"since ..."). Each block is an independently-sourced current cut with its own
as-of date (e.g. the institutional-ownership block is the latest 13F holder
snapshot), so the blocks are NOT a comparable historical series — reading a
trend off them, or treating two blocks' as-of dates as the same instant,
produces spurious results. For anything time-series, historical, or
"how did this change", use `explore_data_catalogue` instead.

Scope caveat: the snapshot is a FIXED set of current blocks, not the full
catalogue. Absence of a data domain HERE does NOT mean Flexreport lacks it —
do not infer coverage gaps from this tool. Route "which symbols / values are
available" enumerations to `list_options` (instant), and "do you have data
on <topic>" questions that need actual data to `explore_data_catalogue`.

*** RUN IT WITH `get_company_event_web(symbol)` — THE STANDARD PAIR. *** This
tool gives the WHAT (where the company stands); the event web gives the WHY
(the events that got it there, in order, and how they connect). The snapshot
states that the thesis shifted, the valuation signal changed, or ownership
moved; it does NOT say what caused any of it — every block here is a settled
output with the episode behind it stripped out. So whenever the user asks
about a company generally, or follows a snapshot with "why?" / "what changed?"
/ "what drove that?", call BOTH and read them together: quote the snapshot for
the current position, and the event web for the sequence that explains it.
Presenting a snapshot alone as the whole picture is the failure mode — it
reads as a verdict with no evidence.

Two honest limits when pairing them. (1) The event web defaults to a 7-day
window; a driver older than that needs `window_days` widened (up to 90) before
you can say the snapshot is unexplained. (2) The blocks here carry their own
as-of dates — a 13F ownership block can be a quarter old, so the event that
explains it may sit well outside any window. Absence of a matching event is
NOT proof the snapshot moved for no reason.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolYesCovered ticker, e.g. "AAPL".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
recent_newsNo
price_targetsNoDecommissioned pending a model revamp: values are null and active_coverage is false.
price_overviewNo
company_summaryNoThesis, bull and bear case.
financial_overviewNo
stock_grades_overviewNo
institutional_ownershipNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare only readOnlyHint=true, so the description carries the behavioral burden and does it well: synchronous and cheap, fixed block set, point-in-time semantics, per-block as-of dates (13F can be a quarter old), and the failure mode of misreading blocks as a comparable series. This is context an agent could not get from the structured fields.

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 purpose before the caveats, and the bolded section headers make it scannable. However, the point-in-time constraint is restated several times across the warning and pairing paragraphs, so the piece is longer than a one-parameter read tool strictly requires and carries mild redundancy.

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 an output schema present, return values need not be explained, and the description nonetheless enumerates the returned blocks. Combined with the routing rules, timing caveats, and pairing guidance, nothing an agent needs to call this correctly is missing.

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?

Only one parameter (symbol), schema description coverage is 100%, and the description adds nothing beyond the schema's 'Covered ticker, e.g. AAPL.' Baseline 3 for a fully documented single-param schema is appropriate.

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?

Opens with a specific verb+resource — 'Fetch a structured, POINT-IN-TIME company snapshot' — and immediately enumerates what blocks it returns (thesis/bull/bear, financial overview, price performance, targets, ownership, grades). It is clearly distinguished from near-siblings like generate_report_for_stock, explore_data_catalogue, and list_options, so an agent can pick it without opening any schema.

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?

Explicit when-to-use ('quick CURRENT read', general company questions), explicit when-NOT-to-use (any temporal/trend/'over time' question, coverage enumerations), and names the replacement tool for each case (explore_data_catalogue, list_options). It also instructs the standard pairing with get_company_event_web and states the selection reason (WHAT vs WHY).

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.

Resources