Skip to content

Version 1.1.8 · Last updated

Argus documentation

Argus is an agent-readable financial data layer. It returns cited, structured financial facts through CLI + Skill, MCP, and REST. The website explains how to connect; the API and MCP services execute requests.

Structured financial facts for AI agents · CLI + Skill · MCP · REST.

Cited financial facts, structured for AI agents.

Agent data flow from CLI, REST, and MCP through CoreServiceBoundary to a cited DataPackage

The product returns structured facts, labeled source material, evidence, permissions, license status, data quality, point-in-time metadata, handling restrictions, and audit identifiers. Argus itself does not generate investment judgments or execute orders, but it does not restrict a client AI agent from using lawfully accessible data for independent analysis, judgments, or downstream output.

Audience

These documents are for developers, agent tool integrators, platform engineers, and compliance reviewers. They are not written as retail investor guidance or a product marketing page.

Choose where to start

Your goal Start here
Make the first authenticated request Getting Started
Choose a tool and inspect its permissions Agent Tool Registry
Integrate over HTTP REST API
Integrate an MCP-aware agent MCP
Understand every result field Data Package Dictionary
Load or synchronize source data Connectors
Deploy or operate the service Deployment and Observability
Diagnose a failed call Troubleshooting

Required reading

What Argus returns

The ENTITY, DATE, METRIC, and SOURCE registration gate

Successful governed factual calls return a CliToolEnvelope containing the selected tool, an audit_id, permission and license decisions, source evidence, output restrictions, and a nested DataPackage result. Registry and administration operations use their declared contracts instead: for example, agent_tool_registry returns an AgentToolRegistrySnapshot, not a DataPackage. Read output_format.schema_name from each registry tool before decoding a response. The registry's canonical envelope version names the contract kernel; current business invocation responses use the wire envelope above. Use live OpenAPI and MCP schemas plus binding parameter mappings for executable requests.

Treat a returned factual package as a contract, not as presentation-ready prose. Before consuming a fact, check:

  1. success and audit_id on the outer envelope;
  2. data_quality.requires_human_review and any structured issues;
  3. data_license.status, allowed_uses, prohibited_uses, and redistribution;
  4. the fact's evidence_ids against source_evidence;
  5. known_time against the requested as_of time;
  6. output_restrictions before forwarding or transforming the result.

Evidence IDs preserve the relationship between data period, filing time, known time, and the requested as-of boundary

Public service map

Surface Public location Intended caller
Static website https://www.argusfa.com/{locale}/ People reading onboarding and tool reference
MkDocs reference https://www.argusfa.com/docs/ Developers, operators, and compliance reviewers
REST https://api.argusfa.com Machine clients and customer-side CLI
MCP https://mcp.argusfa.com/mcp MCP-aware agents
OpenAPI https://api.argusfa.com/openapi.json REST schema discovery and client generation
Tool registry https://api.argusfa.com/v1/tool-registry Tool discovery, permissions, bindings, and compatibility

The static website never accepts credentials and never executes a tool call.

Product boundary

Every response must remain machine-readable and auditable. A valid result needs source evidence, known-at timing, data quality, license status, output restrictions, and an audit id. A natural language paragraph alone is never a valid argus result.

Prohibited requests are rejected by policy and should be redirected to safe factual tools such as company_fact_snapshot, filing_search, event_timeline, point_in_time_snapshot, data_quality_check, or source_evidence_lookup.