Annalist Financial Statements

Get the changes since a date

get_changes_since

Read-onlyIdempotent

What the site published since a date, latest first: every snapshot published (a new report of a company, or its figures built again) with its time of publication, every record that the findings ledgers wrote for those snapshots (a finding stated for the first time, confirmed, strengthened, weakened or retired, each a sentence with its rule, period and document ids) and every correction by Annalist. Without company the answer covers the coverage over the last 90 days; with company it reads the whole record of that company. The feeds in Atom, /feed.xml and /company/{id}/feed.xml, carry the same entries for a reader that polls.

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": {
      "since": "<since>"
    },
    "name": "get_changes_since"
  }
}

Input Schema

Name	Required	Description
`kinds`	No	keep these kinds (default every kind)
`limit`	No	maximum changes (default 50)
`since`	Yes	an ISO date (2026-11-01) or time (2026-11-01T06:00:00+00:00), UTC, from which changes count
`module`	No	keep the finding records of one module
`states`	No	keep the finding records of these states
`company`	No	company id from search_companies, to read the whole record of one company

Output Schema

Name	Required	Description	Default
`count`	Yes
`feeds`	Yes
`notes`	Yes
`since`	Yes
`counts`	No
`changes`	Yes
`citation`	No
`companies`	No
`truncated`	Yes
`conventions`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the description is free to spend its words on what actually differs. It does: ordering (latest first), the default 90-day scope versus whole-record scope, and the composition of each change type including the states a finding can move through. Return format and pagination beyond the limit parameter are left to the output schema.

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 clause is well front-loaded, but the body is one sprawling sentence stitched together with nested parentheses that force the reader to parse three sub-definitions mid-thought. The closing note about Atom feeds is useful but sits in the same breath as the core contract rather than being a separate line.

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?

For a six-parameter read tool with an output schema and full annotation coverage, nothing material is left unstated. Defaults, scope switching, ordering and change-type semantics are all covered, and the presence of an output schema means return-value detail need not be repeated.

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 would be 3. The description earns a step above that by explaining what the kinds actually mean in domain terms — a snapshot is a new report or rebuilt figures, a finding is a stated/confirmed/strengthened/weakened/retired sentence carrying rule, period and document ids — and by tying company to whole-record retrieval. It does not clarify the interaction between module and states filters, which remains schema-only.

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 shape: everything published since a date, returned latest first, broken into snapshots, finding records and Annalist corrections. That is far more than a restatement of the name and lets an agent predict the payload. It stops short of 5 because it never distinguishes itself from overlapping siblings such as get_findings, list_snapshots or get_events, which return much of the same material without the delta framing.

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?

It gives real routing context: the default 90-day coverage window when no company is supplied versus the full historical record when one is, and it points polling readers at the Atom feeds instead. What is missing is guidance against the sibling tools — an agent cannot tell from this text when to prefer get_changes_since over get_findings for the same company.

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

All Annalist Financial Statements tools Inspect

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

Need Help?