Loading ToolBench
SEC EDGAR filing search and purchase for AI agents: 10-K, 10-Q, CompanyFacts metrics, evidence_verified causality_events. x402 on-chain delivery on Polygon.
Mixed quality. Tool definitions are present with schemas and descriptions, but several critical issues limit utility: (1) Some parameter descriptions are verbose and contain marketing language rather than functional guidance. (2) Error handling documentation is incomplete, tool descriptions mention 402 Payment Required but don't guide recovery. (3) The purchase_filing and purchase_single_patent tools embed complex multi-step payment workflows in descriptions rather than structured error responses. (4) Parameter relationships (e.g., tx_hash being empty on first call, populated on second) are documented in prose but lack schema-level constraints. (5) Output schemas are not explicitly documented, responses are inferred from descriptions. (6) Tool naming is clear (verb_noun pattern used consistently), but composition raises concerns: search_filings + get_filing_sample + purchase_filing is a 3-step workflow that could benefit from explicit chaining guidance.
FREE lightweight preview — returns structured metadata + first ~5K chars of filing text to triage before purchase. [COST: free xpay call] Returns: document_id, cik, ticker, company_name, form_type, period_end, agent_readiness_score, sample_text (~5K chars), edgar_url, and optional alpha_signals / causality_events preview (if agent_readiness_score >= 80). Use this to shortlist before purchase_filing.
SEC filing purchase and delivery — full JSON (10-K, 10-Q, 8-K text + alpha_signals + causality_events + financial_metrics). [COST: xpay per-call + $5.00 USDC on-chain data price] Delivers full structured JSON after on-chain payment verification. [AGENTIC WORKFLOW (MPP v1.0 402 Payment Flow)]: This is a mandatory 2-step process. Do NOT hallucinate a tx_hash. STEP 1: Call this tool with ONLY 'document_id' and 'network'. Leave 'tx_hash' EMPTY. The server will return a 402 Payment Required response containing a 'transaction_payload'. STEP 2: You MUST securely execute/broadcast the exact 'transaction_payload' on the blockchain using your wallet. This payload contains the required cryptographic HMAC memo to bind your payment to the product. STEP 3: Once the transaction is confirmed on-chain, call this exact tool AGAIN, providing the 'document_id', 'network', and the resulting 66-character 'tx_hash'.
USPTO patent purchase and delivery — prior art / competitive intelligence single-patent dataset. [COST: xpay per-call + $0.50 USDC on-chain data price] Delivers full structured JSON after on-chain payment verification. [AGENTIC WORKFLOW (MPP v1.0 402 Payment Flow)]: This is a mandatory 2-step process. Do NOT hallucinate a tx_hash. STEP 1: Call this tool with ONLY 'patent_id' and 'network'. Leave 'tx_hash' EMPTY. The server will return a 402 Payment Required response containing a 'transaction_payload'. STEP 2: You MUST securely execute/broadcast the exact 'transaction_payload' on the blockchain using your wallet. This payload contains the required cryptographic HMAC memo to bind your payment to the product. STEP 3: Once the transaction is confirmed on-chain, call this exact tool AGAIN, providing the 'patent_id', 'network', and the resulting 66-character 'tx_hash'.
Multi-step payment workflow (402 Payment Required flow) embedded in tool descriptions instead of structured error responses. STEP 1/2/3 instructions are repeated verbatim in purchase_filing and purchase_single_patent descriptions, making them unmaintainable and preventing proper error-driven workflow guidance.
Pricing and cost information (xpay fees, USDC amounts, per-call charges) mixed into tool descriptions. This is metadata/billing concern, not functional description. LLMs may misinterpret pricing as a constraint or workflow requirement. Separate billing details into API documentation or response metadata.
Output schemas not formally documented. Responses are described as prose lists ('Returns: document_id, cik, ticker...') rather than structured JSON Schema definitions. LLMs cannot reliably parse prose lists for field extraction, especially for optional/conditional fields (e.g., 'optional alpha_signals preview if agent_readiness_score >= 80').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
PRIMARY discovery tool — lightweight catalog over 10k+ SEC filings (fi_listings_portfolio). [COST: low xpay per-call fee] Does NOT return alpha_signals, causality_events, or financial_metrics (use get_filing_sample / purchase_filing). Always returns agent_readiness_score (higher = better structured data) and edgar_url. Required: at least one of ticker, form_type, company_name, fiscal_period, cik (avoids full-table scans). Agent workflow after this call: 1. Shortlist by agent_readiness_score and optional agent_one_liner 2. get_filing_sample(document_id) — free preview 3. purchase_filing(document_id) — paid full JSON (x402)
USPTO patent search for competitive intelligence, prior art, IP analytics, and R&D scouting. [COST: low xpay per-call fee; $0.50 USDC on-chain per patent dataset if purchased] Searches 3000+ AI-enriched USPTO patents ($0.50 each to buy full JSON). Daily-updated database. Returns: patent_id, title, importance_p, publication_date, primary_cpc, secondary_cpcs, biz_target_ind. Supports pagination via offset.
Enum constraints documented in prose but not enforced in schema. primary_cpc description says 'Must be one of the exact codes (e.g., G01, G06, H04)' but schema does not define an enum field. Similarly, form_type in search_filings mentions '10-K, 10-Q, 8-K' in description but not in schema enum. LLMs will hallucinate invalid values.
Parameter default behaviors undocumented at schema level. get_filing_sample has a document_id parameter that 'Defaults to a demo sample if not provided', but schema doesn't reflect this as optional+default. purchase_filing and purchase_single_patent have tx_hash behavior ('LEAVE EMPTY first to retrieve payment instructions') that should be schema-enforced or documented in a structured error response.
No error handling guidance for failed payment transactions. If on-chain verification fails, what should the agent do? Retry? Refund? Try a different network? Descriptions mention '402 Payment Required response' but do not structure what that response contains or how the agent should recover.
Tool composition not optimized. The search_filings → get_filing_sample → purchase_filing workflow is a 3-step manual process. No batch tool for bulk purchase or shortlisting guidance. Agents must reason through filtering and selection rather than automatic chaining.