Skip to main content
Glama

StockPortfolio.pro

Filing changes

get_filing_changes
Read-only

What changed between a company’s newest 10-K/10-Q/20-F/40-F and its previous filing of the same form: guidance and outlook language, risk factors, demand and margin commentary, quoted from both documents and checked against them. The first comparison for a filing pair can take 30–60 seconds; later calls are served from the cache. Needs a signed-in StockPortfolio.pro account. Metered like ask_filings: consumes the account’s allowance.

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>"
    },
    "name": "get_filing_changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
tickerYesUS ticker, e.g. NVDA or AAPL.

Output Schema

NameRequiredDescriptionDefault
noteNo
prevNo
toneNo
latestNo
symbolNo
changesNo
headlineNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnly, openWorld, non-destructive), the description discloses the two things annotations cannot: the first comparison for a filing pair costs 30–60 seconds while later calls hit cache, and it requires a signed-in StockPortfolio.pro account and consumes the metered allowance. That is exactly the operational context an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core comparison is front-loaded in the first clause, then latency, then auth, then cost — each sentence carries distinct, non-redundant information with no filler.

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?

An output schema exists, so return structure need not be explained. The description still covers the scope of comparison, the freshness/latency model, authentication, and billing — everything needed to decide and invoke correctly for a one-parameter open-world read.

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 coverage is 100% and the single ticker parameter is documented in-schema with a US-ticker example, so the baseline is 3. The description adds only indirect meaning — that the ticker selects the newest filing and its same-form predecessor — but nothing about the accepted format or edge cases.

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-plus-resource ('what changed between a company's newest 10-K/10-Q/20-F/40-F and its previous filing of the same form') and enumerates the content types compared (guidance, risk factors, demand/margin commentary) plus the sourcing discipline ('quoted from both documents and checked against them'). An agent can distinguish this from get_filing (raw document) and ask_filings (Q&A) without opening a schema.

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?

The 'previous filing of the same form' constraint makes clear the prerequisite of having a comparable prior filing, and the metering sentence signals this is a heavier, allowance-consuming alternative to plain retrieval. However, it never explicitly says when to prefer ask_filings or get_filing instead, or what happens on a first-ever filer with no prior pair.

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