Canli Fundamentals

Measure history

history

Read-onlyIdempotent

Get a measure (or several, with concepts) over time, newest first: latest (default), first reported, or as known on a filing date, with its filing, other version and yearly change.

Input Schema

Name	Required	Description
`unit`	No	Default: the unit with most periods.
`as_of`	No	A filing date, not a period end: only filings made by then count.
`basis`	No	latest (default), first_reported, or as_of (default with as_of).
`limit`	No	Default 20, newest first.
`company`	Yes	Ticker (AAPL), CIK or company name.
`concept`	No	Plain name (revenue, eps_diluted, assets; follows tag changes) or XBRL tag (Revenues).
`periods`	No	annual (default), quarterly, or all (adds year-to-date).
`concepts`	No	Instead of concept: 2-6 measures.

Output Schema

Name	Required	Description	Default
`rows`	No
`basis`	No
`total`	No
`limits`	No
`series`	No
`columns`	No
`company`	No
`concept`	No
`meaning`	No
`snapshot`	No
`truncated`	No
`next_offset`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 31, 2026

changedInput schema / properties / as_of / description

Previous value: -"Only filings made on or before this date count, for every basis."New value: +"A filing date, not a period end: only filings made by then count."

changedInput schema / properties / basis / description

Previous value: -"first_reported (default), latest, or as_of (default when as_of is set)."New value: +"latest (default), first_reported, or as_of (default with as_of)."

addedInput schema / properties / concepts

Added value: +{
+  "description": "Instead of concept: 2-6 measures.",
+  "items": {
+    "maxLength": 200,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 6,
+  "minItems": 2,
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "company",
-  "concept"
-]New value: +[
+  "company"
+]

addedOutput schema / properties / series

Added value: +{
+  "items": {
+    "additionalProperties": {},
+    "properties": {},
+    "type": "object"
+  },
+  "type": "array"
+}

First observedOct 6, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds ordering ('newest first') and basis-selection semantics, but says nothing about pagination, truncation at the limit, or what 'other version' and 'yearly change' actually mean in the result.

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?

A single dense sentence that front-loads the core action and then enumerates the basis variants. It is efficient, though the clause 'with its filing, other version and yearly change' is a compressed output description that reads awkwardly.

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?

With 8 params at full schema coverage, an output schema, and rich annotations, the description supplies enough to call it correctly. Minor gaps: no mention that concept and concepts are mutually exclusive, and no note on the limit default interacting with 'newest first'.

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 is 3. The description goes further by explaining the concept/concepts relationship ('or several, with concepts') and framing as_of as 'as known on a filing date' with 'first reported' as the alternative view, adding semantic glue the schema fields only state individually.

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?

States a specific verb and resource (get a measure over time) plus scope details: newest-first ordering, basis variants, and multi-measure via concepts. It does not name or differentiate against overlapping siblings like known_as_of, restatements, or vintages, so an agent must infer which tool handles the as-of/restatement case.

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?

It notes the default basis (latest) and that as_of implies basis=as_of, which is useful implied guidance. But it never says when to prefer this over known_as_of, restatements, or vintages, which is exactly the ambiguity an agent faces with six sibling tools.

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

All Canli Fundamentals 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.