P0 Agent Economy Index

by dev.workers.x402-bazaar-rank-worker.x402-bazaar-rank

SEC filings

sec_filings

Read-onlyIdempotent

Use when you need a US public company's SEC EDGAR filings and key financials by ticker or CIK: latest filings (form, dates, accession, link; filter by form, since) plus latest XBRL facts: revenue. Returns the exact paid x402 request for your input (GET /sec/filings, $0.003 per call), with the response schema and an example; call that URL with an x402 or MPP client to get the data. Bad input is refused before any charge. For several companies at once use sec_filings_batch. With a P0 access key (header Authorization: Bearer p0k_…, buy one at https://x402-bazaar-rank.x402-bazaar-rank-worker.workers.dev/keys/buy?usd=5) this tool makes the paid call itself and returns the data, deducting the listed price.

Input Schema

Name	Required	Description
`cik`	No	SEC Central Index Key, e.g. 320193 (send this or ticker)
`form`	No	optional comma list of form types to keep, e.g. 10-K,10-Q,8-K
`facts`	No	0 = filings only
`limit`	No	max filings returned
`since`	No	filed on/after YYYY-MM-DD
`ticker`	No	stock ticker, e.g. AAPL or BRK.B (send this or cik)
`periods`	No	also return the last n full fiscal years of every fact, plus ttm (adds history)
`quarters`	No	also return the last n quarters of every fact (quarter-only values, derived ones marked), plus ttm (adds history)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026

addedInput schema / properties / periods

Added value: +{
+  "description": "also return the last n full fiscal years of every fact, plus ttm (adds history)",
+  "maximum": 10,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / quarters

Added value: +{
+  "description": "also return the last n quarters of every fact (quarter-only values, derived ones marked), plus ttm (adds history)",
+  "maximum": 20,
+  "minimum": 1,
+  "type": "integer"
+}

Changed1 schema field changedOct 25, 2026

addedInput schema / properties / facts

Added value: +{
+  "description": "0 = filings only",
+  "type": "string"
+}

Changed1 schema field changedOct 25, 2026

addedInput schema / properties / since

Added value: +{
+  "description": "filed on/after YYYY-MM-DD",
+  "type": "string"
+}

AddedOct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial context beyond them: pricing ($0.003/call), the fact that bad input is refused before any charge, the exact endpoint returned, and the access-key path with its own cost implication. No contradiction with 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?

Front-loaded with the trigger and payload, and the payment mechanics are genuinely necessary given the x402 model. It is dense rather than padded, though the verbatim key-purchase URL and the recap of the exact GET path make it longer than strictly needed.

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 8 params and no output schema, the description does what's needed: it explains what the response contains, that a request payload with response schema and example is returned in the no-key path, and that with a key the data itself comes back. Nothing an agent needs to call it 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?

Schema description coverage is 100%, so every parameter is already documented in the schema; baseline is 3. The description echoes a few of them ('filter by form, since', 'XBRL facts: revenue') but adds no syntax, defaults, or interaction detail beyond what the schema states, and says nothing about limit/periods/quarters.

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 ('a US public company's SEC EDGAR filings and key financials by ticker or CIK'), enumerates the payload (latest filings with form/date/accession/link, plus XBRL revenue facts), and names the sibling sec_filings_batch for the multi-company case. An agent can distinguish it from siblings 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?

Opens with an explicit trigger ('Use when you need...'), routes multi-company queries to sec_filings_batch, and spells out the two invocation paths: no key → receive the paid x402 request and call it yourself; P0 key → the tool executes the paid call and returns data. Clear when to use and which alternative applies.

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

All P0 Agent Economy Index 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?