FinancialMD

Cash dividends with their dates

dividends

Read-onlyIdempotent

Return a company's cash dividends per share as its SEC filings state them, newest first: amount (on the basis of the day declared, not split-adjusted), declaration, record, ex-dividend and payment dates, each null when the filing does not state it, with how each was captured (xbrl date tags, a dividend table or a sentence) and the citation text. ex_date_method says whether the ex-date is stated or derived from the record date by the settlement rule. When EDGAR states no record date (JPMorgan after 2018) or only the month paid (Realty Income), there is no ex-date: say so and do not make one up. Dividends announced only on a company's website are absent. For split-adjusted and total-return prices call stock_prices with adjust. Filing-layer read: served with generous limits on every tier. Use it for dividend history, ex-dividend dates and payment dates. If a dataset, field, company or analysis you need is missing, call request_data.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "limit": 8,
      "company": "MSFT"
    },
    "name": "dividends"
  }
}

Input Schema

Name	Required	Description
`to`	No	Last date, inclusive (YYYY-MM-DD).
`from`	No	First date, inclusive (YYYY-MM-DD).
`as_of`	No	Knowledge date or timestamp (YYYY-MM-DD or RFC 3339). The answer is what FinancialMD knew at that instant: only facts whose known interval contains as_of. Omit for the current view.
`limit`	No	Maximum number of periods or items to return (default 12, at most 500).
`company`	Yes	Company identifier: a FinancialMD id ("fmd_01H..."), an SEC CIK ("cik:320193"), or a ticker ("ticker:AAPL", optionally with the MIC "ticker:AAPL.XNAS"). A bare ticker like "AAPL" is accepted and sent as ticker:AAPL. An issuer on an EU or UK regulated market that does not file with the SEC has no CIK: pass its LEI ("lei:IOG4E947OATN0KJYSD45") or its fmd_ id.

Output Schema

Name	Required	Description
`data`	No	{ items: [{ kind, share_class, amount, declared_date, record_date, ex_date, ex_date_method, ex_date_note, pay_date, pay_month, pay_note, method, citation, document, source_url }], note }
`meta`	No	Request metadata: request_id, as_of, company resolution, coverage, pipeline_version, licence, terms, proof_base.
`error`	No	Present only on isError results: the API error code and message plus remedy hints.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 13, 2026

changedInput schema / properties / company / description

Previous value: -"Company identifier: a FinancialMD id (\"fmd_01H...\"), an SEC CIK (\"cik:320193\"), or a ticker (\"ticker:AAPL\", optionally with the MIC \"ticker:AAPL.XNAS\"). A bare ticker like \"AAPL\" is accepted and sent as ticker:AAPL."New value: +"Company identifier: a FinancialMD id (\"fmd_01H...\"), an SEC CIK (\"cik:320193\"), or a ticker (\"ticker:AAPL\", optionally with the MIC \"ticker:AAPL.XNAS\"). A bare ticker like \"AAPL\" is accepted and sent as ticker:AAPL. An issuer on an EU or UK regulated market that does not file with the SEC has no CIK: pass its LEI (\"lei:IOG4E947OATN0KJYSD45\") or its fmd_ id."

First observedNov 13, 2026

TDQS

A4.4/5.0

Behavior3/5

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

With readOnly/idempotent/non-destructive annotations already covering the safety profile, the description still adds substantive behavior: amounts are on the declared-day basis and not split-adjusted, dates are null when the filing omits them, ex_date_method distinguishes stated from derived ex-dates, and no ex-date is fabricated for JPMorgan post-2018 or Realty Income. It also discloses that website-only announcements are absent and that the endpoint has generous tier limits, which is useful beyond 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?

Dense but front-loaded: the return payload and ordering come first, then data-quality caveats, then routing advice. Could be marginally tighter (e.g., the 'say so and do not make one up' admonition and the generic request_data closing line could be trimmed or structured as a caveat list), but nothing is filler at the level of a single wasted sentence.

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 values need not be explained, and the description instead covers the parts that schema cannot: null conventions, derived ex-dates, known issuer gaps, split-adjustment basis, and the sibling used for adjusted prices. For a 5-parameter read tool with full schema coverage this leaves nothing an agent needs missing.

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 baseline is 3, but the description adds real semantic context: results are newest first and the endpoint permits generous limits, which frames how limit/from/to behave. It does not explain as_of or the from/to boundary semantics, leaving that to the schema.

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 and resource ('Return a company's cash dividends per share as its SEC filings state them'), plus scope, ordering ('newest first') and the exact fields returned. It also distinguishes itself from stock_prices for adjusted/total-return figures, so an agent can route without opening the 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?

Explicitly names the use cases ('dividend history, ex-dividend dates and payment dates'), redirects to stock_prices with adjust for split-adjusted/total-return prices, and points to request_data when a dataset or field is missing. Alternatives and their selecting conditions are stated rather than implied.

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

All FinancialMD 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?