automaton

company_facts__fulltext

SEC EDGAR full-text search across every filing since 2001: find companies by what is written INSIDE their filings (e.g. "material weakness", "going concern"). $0.01. Price: $0.01 per call in USDC on Base (eip155:8453), paid with x402 in params._meta["x402/payment"]. HTTP: GET https://api.firstmention.uk/s/company-facts/fulltext

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": {
      "q": "<q>"
    },
    "name": "company_facts__fulltext"
  }
}

Input Schema

Name	Required	Description
`q`	Yes	Full-text query; quote phrases
`enddt`	No
`forms`	No	Comma-separated form types, e.g. 10-K,8-K
`limit`	No
`startdt`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 12, 2026

removedInput schema / properties / enddt / description
```
Removed value: -"End date YYYY-MM-DD"
```
removedInput schema / properties / limit / description
```
Removed value: -"Max results (default 10, max 40)"
```

changedInput schema / properties / q / description

Previous value: -"SEC EDGAR full-text query; quote phrases, e.g. \"going concern\""New value: +"Full-text query; quote phrases"

removedInput schema / properties / startdt / description
```
Removed value: -"Start date YYYY-MM-DD"
```

AddedNov 12, 2026

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral burden, and it does disclose the two things an agent most needs: this is a paid call ($0.01 USDC on Base, eip155:8453) settled via x402 in params._meta['x402/payment'], and the underlying HTTP endpoint. That payment/authorization detail is genuinely valuable. It does not cover rate limits, result page size behavior, or what a response looks like, and it repeats the price twice.

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 core purpose is front-loaded and the examples earn their place, but '$0.01. Price: $0.01 per call in USDC on Base...' is redundant restatement of the same fact in two forms. The HTTP endpoint and payment scheme are useful but tacked onto the same sentence chain as the search semantics, mixing capability description with billing mechanics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There are no annotations and no output schema, so the description is the only source of behavioral context, and it covers purpose, cost, and payment mechanism adequately. For a 5-parameter search tool it leaves notable gaps: no return-shape or pagination hint, and no explanation of the three undocumented parameters. Adequate for a competent agent, but not complete.

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 only 40%, so the description should compensate, and it largely does not. It adds meaning for q by illustrating the phrase-matching style ('material weakness'), and the schema itself documents q and forms. But startdt, enddt, and limit are undocumented in both places, including their format (ISO date? days? max limit?) — a real gap for a date-bounded search.

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 specific verb and resource: full-text search across SEC EDGAR filings since 2001, with the clear distinguishing scope 'by what is written INSIDE their filings' versus metadata-based lookup. The examples ('material weakness', 'going concern') make the retrieval mode concrete. It stops short of naming which sibling (e.g. company_facts__filings or company_facts__lookup) handles the metadata path, so the differentiation is implicit rather than explicit.

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?

Usage is implied by the phrasing 'find companies by what is written INSIDE their filings', which tells an agent this is the content-matching path rather than a ticker or domain lookup. However, there is no explicit when-to-use or when-not statement and no sibling is named as the alternative for structured field lookups. An agent must infer the boundary from the sibling names alone.

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

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