Skip to main content
Glama

company_facts__resolve

Company, sanctions and domain facts in one call: SEC EDGAR identity/filings and full-text filing search, OFAC SDN + EU sanctions screening, RDAP domain facts, DNS. $0.01 per call in USDC on Base. Free previews available. 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/resolve

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": {
      "company": "<company>"
    },
    "name": "company_facts__resolve"
  }
}

Input Schema

NameRequiredDescriptionDefault
companyYesCompany name or ticker, e.g. 'Apple Inc' or 'AAPL'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / company
      Added value: +{
      +  "description": "Company name or ticker, e.g. 'Apple Inc' or 'AAPL'",
      +  "type": "string"
      +}
    • removedInput schema / properties / enddt
      Removed value: -{
      -  "description": "End date YYYY-MM-DD",
      -  "type": "string"
      -}
    • removedInput schema / properties / forms
      Removed value: -{
      -  "description": "Comma-separated form types, e.g. 10-K,8-K",
      -  "type": "string"
      -}
    • removedInput schema / properties / limit
      Removed value: -{
      -  "description": "Max results (default 10, max 40)",
      -  "type": "integer"
      -}
    • removedInput schema / properties / q
      Removed value: -{
      -  "description": "SEC EDGAR full-text query; quote phrases, e.g. \"going concern\"",
      -  "type": "string"
      -}
    • removedInput schema / properties / startdt
      Removed value: -{
      -  "description": "Start date YYYY-MM-DD",
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "q"
      -]New value: +[
      +  "company"
      +]
  2. Added
  3. Removed
  4. Added

TDQS

C2.8/5.0
Behavior3/5

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

With no annotations supplied, the description must carry behavioral disclosure, and it does add real operational context: pricing ($0.01 per call in USDC on Base, eip155:8453), the x402 payment mechanism via params._meta["x402/payment"], and the HTTP endpoint. It omits failure semantics (e.g., what an OFAC hit returns), rate limits, and whether the response merges or sections the sources.

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?

The lead sentence front-loads the value proposition and the data sources, followed by payment details and endpoint. It is dense and mostly waste-free, but the price is restated twice ('$0.01 per call in USDC on Base' appears in consecutive sentences), which is redundant.

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

Completeness2/5

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

For a paid aggregate tool with no output schema and no annotations, the definition says nothing about the return shape, how EDGAR/sanctions/RDAP results are combined, or how partial-source failure surfaces. Payment and endpoint mechanics are well covered, but the agent cannot anticipate the response or error behavior before paying.

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 'company' parameter is documented with examples ('Apple Inc' or 'AAPL'). The description adds no meaning beyond that — it doesn't say whether name or ticker is preferred for sanctions/EDGAR lookups or how ambiguity is resolved, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific scope — SEC EDGAR identity/filings, OFAC SDN + EU sanctions, RDAP domain facts, DNS — so the resource is clear. However, it never distinguishes itself from the many overlapping siblings (company_facts__risk, __dossier, __snapshot, __lookup); the only differentiator offered is that it aggregates sources, not which call to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance: nothing explains why an agent should call this paid aggregator instead of the free/more specific siblings. 'Free previews available' implies a try-before-pay path but never explains how it is accessed or what it returns.

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