Keyless x402 compliance on Base: $0.001 OFAC wallet screen, $0.05 pack, $0.95 company file.
Scored across 8 tools
Tools are largely distinct: enrich provides basic firmographics, research adds web intel, compliance bundle combines sanctions with domain data, wallet screen checks addresses, multi-sanctions covers broader lists. Some overlap exists between research/enrich/verified_file and between sanctions tools, but descriptions explicitly cross-reference when to use each. declare_need serves as a router to reduce ambiguity.
All tools follow a consistent 'lion_' prefix with snake_case. Names are descriptive nouns or noun phrases (company_enrich, compliance_bundle, wallet_screen) rather than a strict verb_noun pattern, but the naming is uniformly structured and predictable. Minor deviation: lion_declare_need uses a verb, but the prefix and formatting remain consistent across the entire set.
With 8 tools, the count falls well within the ideal 3-15 range. Each tool serves a distinct paid or free purpose in the company/compliance workflow, from lightweight enrichment to full attested dossiers and sanctions screening. No redundancy or missing essential function that would require adding or removing tools.
The tool surface covers the full lifecycle of company and compliance data needs: free teaser (quick_intel), basic enrichment, detailed research, sanctions screening (single and multi-list), a comprehensive compliance bundle, and a fully attested KYB dossier. The free router (declare_need) also helps agents navigate to the correct paid path, closing the gap of 'which tool do I start with'. No obvious missing operations for a read-only data provider.
Firmographics only (name, employees, country, industry, website). Not a web-research pack — use lion_company_research for that. $0.04 Base USDC. [x402 paid: GET /api/x402/company-enrich]
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| fields | No | Comma-separated fields | |
| format | No | apollo_org for drop-in shape | |
| identifier | Yes | Company name or domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It earns credit for revealing the paid model and endpoint ('$0.04 Base USDC. [x402 paid: GET /api/x402/company-enrich]'), which is useful cost context. However, it doesn't disclose failure behavior, permission/auth requirements beyond payment, or output shape — meaningful gaps given zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short clauses with zero filler, purpose front-loaded first, routing second, and cost/endpoint last. Every sentence earns its place, and the pricing line is information an agent needs before committing to a paid call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the burden falls on the description. It adequately covers selection and cost, but omits invocation specifics (the identifier-vs-domain usage question) and gives no hint of the return contract. Adequate for routing, incomplete for a first-time caller executing the call without further digging.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (fields and format have descriptions; domain has none), so the schema does most of the work on documented params. But the description adds nothing about parameters and fails to resolve the inherent identifier-vs-domain ambiguity: identifier accepts 'name or domain' per schema, yet domain is a separate field — the description never clarifies when to use which, leaving a real invocation risk for the one required param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with a concrete output scope: 'Firmographics only (name, employees, country, industry, website).' This precisely delimits what the tool returns and names the sibling it is not ('use lion_company_research for that'), leaving no ambiguity about the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly excludes the web-research alternative ('Not a web-research pack — use lion_company_research for that') and implies the selection condition through 'Firmographics only.' It doesn't fully enumerate when-not-to-use scenarios against the other six siblings, but the primary routing decision is crisply handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Default company call: one-shot web + firmographics + domain trust by name or domain. Use lion_company_enrich if you only need name/employees/country. Use lion_verified_company_file for KYB source trail. $0.03 Base USDC. [x402 paid: GET /api/x402/company-research]
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Company name or domain e.g. stripe.com | |
| domain | No | Optional domain override |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions that this is a 'one-shot' call, returns web/firmographics/domain trust, and costs $0.03 (implying a paid operation). However, it does not disclose whether the call has side effects, requires authentication, or has rate limits, and the output format is not described. This leaves gaps but is not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (three sentences) and front-loaded with the core purpose, followed by routing guidance and pricing. The inclusion of pricing is a small but useful addition. The structure is logical and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description should clarify what data is returned. It provides a high-level summary ('web + firmographics + domain trust') but not the exact fields or response structure. It does include pricing and alternative routing, which are helpful. Given the low parameter complexity, this is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented. The description adds 'by name or domain' and mentions the domain override, but these are already implicit in the schema. The description adds no new semantic detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Default company call' and specifies the resource (company research) and the scope ('one-shot web + firmographics + domain trust'). It clearly differentiates this from siblings by name, so an agent immediately understands it is the standard, all-purpose company lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use alternatives: 'Use lion_company_enrich if you only need name/employees/country' and 'Use lion_verified_company_file for KYB source trail.' This leaves no ambiguity about tool selection based on the data needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full counterparty pack: OFAC + entity sanctions + domain + firmographics + signed receipt. Use instead of stacking wallet_screen + research. Needs an address. $0.05 Base USDC. [x402 paid: GET /api/x402/compliance-bundle-json]
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional legal entity name for screening context | |
| token | No | Optional ERC-20 token address for risk indicators | |
| domain | No | Optional company domain for trust + firmographics | |
| address | Yes | EVM wallet address to OFAC SDN / sanctions screen | |
| receipt | No | Set to 1 for portable signed compliance receipt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cost ($0.05 Base USDC), the access method (x402 paid endpoint), and mentions a 'signed receipt' as a deliverable. It does not explicitly state read-only nature or side effects, but given the tool is a data bundle, this is reasonable. The cost and endpoint disclosure adds significant behavioral context beyond a generic description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. It front-loads the tool's essence ('Full counterparty pack') and includes all critical information (components, usage guidance, cost, endpoint) without any irrelevant fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a bundle that combines multiple checks, and the description lists all components, clarifies the use case, and gives cost and access details. It does not describe the response structure or potential error handling, but given there is no output schema and the description already mentions a 'signed receipt' as an output, it covers what agents need to know to decide and invoke it correctly. A minor gap is not spelling out what happens on failure, but this is acceptable for a paid data endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters, so the baseline is 3. The description does not add any new parameter semantics beyond what the schema already provides, except reinforcing the address requirement ('Needs an address') and implicitly connecting the 'domain' parameter to the bundle's 'domain' component. It adds no format or validation details, making it adequate but not enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a 'Full counterparty pack' with specific components (OFAC, entity sanctions, domain, firmographics, signed receipt). It also explicitly differentiates from siblings by saying 'Use instead of stacking wallet_screen + research,' which names the alternative and the resource bundle being provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'Use instead of stacking wallet_screen + research' indicates a superior alternative to combining other tools. It also states the prerequisite 'Needs an address,' which is a clear condition for use. This leaves no ambiguity about when an agent should invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE router. Tell LION what you need in plain language. Returns the one paid path to call next (wallet screen $0.001, company research $0.03, enrich $0.04, compliance $0.05, VCF $0.95). Call this first when unsure which tool to use.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What you need in plain language |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is FREE, that it returns a path rather than executing the action, and lists the costs of the paid alternatives. It does not mention error handling or fallback behavior, but for a routing tool this is sufficient and transparent about its non-mutating nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero fluff. The 'FREE router' label is front-loaded for immediate identification, and the pricing list is concise yet informative. Every sentence earns its place, and the structure aids quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple dispatch tool with one parameter and no output schema, the description is complete: it explains what the tool does, what it returns, the available paid paths, and when to use it. The agent has everything needed to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the sole parameter 'need' as 'What you need in plain language' (100% coverage). The description adds no new semantic detail beyond restating the plain-language instruction, so it offers marginal value over the schema and meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Tell LION what you need'), a specific resource (the router), and its output (the paid path to call next). It distinguishes itself from siblings by being the FREE entry point and explicitly listing the paid alternatives, so an agent knows this is the dispatch tool rather than a direct data action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use it: 'Call this first when unsure which tool to use.' It also provides a mapping of needs to the paid tools with costs, which guides the agent's routing decision and effectively contrasts it with the sibling tools that actually perform the work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you have an address AND/OR entity name/domain and need a signed multi-list receipt. Prefer over lion_wallet_screen when you need more than OFAC SDN. $0.02 Base USDC. [x402 paid: GET /api/x402/multi-sanctions-bundle-json]
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Entity/company name for multi-list screen | |
| domain | No | Optional domain trust check | |
| address | No | Crypto wallet for OFAC SDN address screen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses that the operation is paid ($0.02 USDC) and indicates the output is a signed receipt. However, it does not explicitly state whether the tool is read-only, what side effects exist, or how the signed receipt is produced. The cost and payment method provide some transparency, but more detail about data handling and limitations would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary use case. It packs essential information (when to use, alternative tool, pricing, payment endpoint) into a few sentences without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must clarify return value. It mentions a 'signed multi-list receipt' but does not specify which sanctions lists are covered (beyond implying multiple) or the structure of the receipt. It also lacks information on error handling, authentication requirements beyond payment, and any prerequisites. This is a moderate gap given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since each parameter has a description. The description adds context by stating that the inputs are alternative combinations (address AND/OR entity), which aligns with the schema's optionality. However, it does not significantly deepen understanding beyond the schema's own descriptions, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: obtaining a signed multi-list sanctions receipt given an address and/or entity name/domain. It uses a specific verb and resource and distinguishes itself from lion_wallet_screen by noting it goes beyond OFAC SDN.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides usage context ('Use when you have an address AND/OR entity name/domain'), names a sibling alternative (lion_wallet_screen), and states the condition for preferring this tool ('when you need more than OFAC SDN'). It also gives pricing and payment details, which are practical usage considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE teaser for a company/domain. Does not return a full dossier. Upgrade: lion_company_research ($0.03) or lion_verified_company_file ($0.95).
| Name | Required | Description | Default |
|---|---|---|---|
| entity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It only discloses that the tool is free and returns a teaser (not a full dossier), which is output scope rather than behavioral traits like request handling, potential failures, or response structure. No mention of network calls, authentication, or limitations beyond the 'free' label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The core message is front-loaded ('FREE teaser for a company/domain') and the upgrade info is precise. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and an undocumented parameter, the description is insufficient. It doesn't specify what the teaser contains, how the entity should be formatted, or what the response looks like. The upgrade path gives some context but leaves essential operational details missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'entity' has zero schema description and zero coverage. The description mentions 'company/domain' but doesn't clarify the expected format (e.g., domain name, company name, URL) or give examples. This is minimal compensation for a completely undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'FREE teaser for a company/domain' and explicitly says it does not return a full dossier, distinguishing it from lion_company_research and lion_verified_company_file. The purpose is specific and separates it from siblings, though it doesn't define what a 'teaser' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It directly names the upgrade tools (lion_company_research, $0.03; lion_verified_company_file, $0.95) and implies these are for when full data is needed. This tells the agent when to use this free teaser versus the paid alternatives, though it doesn't mention any exclusions or conditions like rate limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full attested KYB dossier by domain ($0.95). Use after lion_company_research/enrich when you need per-field source trail. Not a first call. $0.95 Base USDC. [x402 paid: GET /api/x402/verified-company-file-json]
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company website domain e.g. stripe.com (not a full URL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cost ($0.95 Base USDC), the paid endpoint, and that it is not a first call. However, it does not describe the output format (JSON, file), error behaviors, or data freshness. It also implies a read operation via the GET endpoint but does not explicitly state it. These gaps limit its transparency in a context where annotations are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. It includes usage guidance and cost in a few short sentences. Minor redundancy exists with the cost mentioned twice ('$0.95' in the first sentence and again as '$0.95 Base USDC'), which slightly detracts but does not undermine readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema and no annotations, the description covers the essential context: purpose, usage order, cost, and endpoint. However, it omits what the returned 'dossier' looks like (e.g., JSON structure, fields) and does not address potential failure modes. Given the tool is part of a pipeline (not a first call), the missing output details may mislead the agent about the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already clearly explains the domain parameter ('Company website domain e.g. stripe.com (not a full URL)'). The description only repeats 'by domain' without adding extra constraints or conversion details, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states precisely what the tool does: it returns a 'Full attested KYB dossier by domain', which is a specific resource. It also differentiates itself from siblings by noting it provides a 'per-field source trail' and is meant 'after lion_company_research/enrich', making its role clear relative to the other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use: 'Use after lion_company_research/enrich when you need per-field source trail' and when not to: 'Not a first call'. This leaves no ambiguity about the intended chain of tool usage and the decision condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you have a 0x address and need PASS/WARN/BLOCK before paying anyone. Not for company names — use lion_multi_sanctions_bundle or lion_compliance_bundle. $0.001 Base USDC. [x402 paid: GET /api/x402/wallet-screen-json]
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Crypto wallet address to OFAC SDN screen (EVM 0x…) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the tool returns PASS/WARN/BLOCK and notes a $0.001 Base USDC cost, indicating a paid operation. However, it does not explicitly state whether the operation is read-only, nor does it mention rate limits, authentication, or any side effects beyond cost. This is reasonable for a simple screening tool but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three short sentences: usage condition, exclusion with alternatives, and cost/endpoint. Every sentence earns its place, and the most critical usage information is front-loaded. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description covers all essential aspects: when to use, what it returns (PASS/WARN/BLOCK), cost, and endpoint. It distinguishes from siblings and specifies the address type. There is no missing information an agent would need to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'address' parameter, which is clearly described as 'EVM 0x…'. The tool description adds context that this is for payments but does not provide additional syntax or constraints beyond the schema. With high schema coverage, the baseline of 3 is appropriate; the description adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: screening a 0x wallet address to obtain a PASS/WARN/BLOCK verdict before payments. It explicitly disambiguates from sibling tools by noting it is not for company names, directing to lion_multi_sanctions_bundle or lion_compliance_bundle instead. This clearly identifies the verb (screen/check), resource (wallet address), and expected output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (when holding a 0x address and needing a compliance decision before paying) and when-not-to-use (for company names) with named alternative tools. Also mentions the cost and the specific API endpoint, which gives practical usage context beyond basic conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
lion_adaptive_querylion_company_dossierlion_composite_bundlelion_cpg_product_intellion_deep_researchlion_domain_enrichlion_domain_intellion_enrich_v1lion_enrichment_tx_bundlelion_entity_sanctions_screenlion_keyless_base_rpclion_lei_lookuplion_location_solar_enrichmentlion_org_enrichlion_poi_business_searchlion_sanctions_screenlion_scrapelion_sec_financialslion_social_signal_intellion_token_risk_indicatorslion_tx_receipt_decodedlion_vat_validationlion_web_enrichment_bundlelion_web_searchlion_wikidata_firmographicslion_entity_sanctions_screenlion_lei_lookuplion_multi_sanctions_bundlelion_domain_enrichlion_company_dossierlion_company_enrichlion_company_researchlion_org_enrichlion_wallet_screenlion_compliance_bundle5 fields changedInput schema / properties / address / descriptionPrevious value: -"Crypto address to screen"New value: +"EVM wallet address to OFAC SDN / sanctions screen"Input schema / properties / domain / descriptionPrevious value: -"Optional domain"New value: +"Optional company domain for trust + firmographics"Input schema / properties / name / descriptionPrevious value: -"Optional entity name"New value: +"Optional legal entity name for screening context"Input schema / properties / receipt / descriptionPrevious value: -"Set 1 for signed receipt"New value: +"Set to 1 for portable signed compliance receipt"Input schema / properties / token / descriptionPrevious value: -"Optional token address"New value: +"Optional ERC-20 token address for risk indicators"lion_deep_research1 field changedInput schema / properties / q / descriptionPrevious value: -"Research query"New value: +"Company name or domain to research e.g. stripe.com"lion_sanctions_screen1 field changedInput schema / properties / address / descriptionPrevious value: -"Crypto address"New value: +"EVM address to OFAC SDN / sanctions screen"lion_verified_company_file1 field changedInput schema / properties / domain / descriptionPrevious value: -"Company domain e.g. stripe.com"New value: +"Company website domain e.g. stripe.com (not a full URL)"lion_adaptive_query10 fields changedInput schema / properties / addressRemoved value: -{
- "description": "Base address (0x...) for source=base_rpc_read or source=wallet_profile.",
- "type": "string"
-}Input schema / properties / chainRemoved value: -{
- "description": "Which chain: base (default) or ethereum. Data is multi-chain; payment stays USDC on Base.",
- "enum": [
- "base",
- "ethereum"
- ],
- "type": "string"
-}Input schema / properties / domainAdded value: +{
+ "type": "string"
+}Input schema / properties / methodAdded value: +{
+ "type": "string"
+}Input schema / properties / modeAdded value: +{
+ "description": "auto|rpc|domain|social",
+ "type": "string"
+}Input schema / properties / qAdded value: +{
+ "type": "string"
+}Input schema / properties / sourceRemoved value: -{
- "description": "Which live onchain source to query.",
- "enum": [
- "base_dex",
- "token_risk",
- "defi_yields",
- "base_rpc_read",
- "wallet_profile",
- "token_holders"
- ],
- "type": "string"
-}Input schema / properties / tokenRemoved value: -{
- "description": "Base token address (0x...) for source=token_risk or source=token_holders.",
- "type": "string"
-}Input schema / properties / txRemoved value: -{
- "description": "Base transaction hash (0x...) for source=base_rpc_read.",
- "type": "string"
-}Input schema / requiredAdded value: +[]lion_compliance_audit_receiptlion_compliance_bundle7 fields changedInput schema / properties / address / descriptionPrevious value: -"EVM address (0x...) to screen: OFAC SDN + wallet/contract risk."New value: +"Crypto address to screen"Input schema / properties / domain / descriptionPrevious value: -"Domain to screen for trust/infrastructure signals, e.g. \"example.com\"."New value: +"Optional domain"Input schema / properties / name / descriptionPrevious value: -"Entity / person / organization name for OFAC SDN name screening."New value: +"Optional entity name"Input schema / properties / receipt / descriptionPrevious value: -"Set to 1 to return a portable, offline-verifiable LION_SIGNED_COMPLIANCE_RECEIPT_V1."New value: +"Set 1 for signed receipt"Input schema / properties / token / descriptionPrevious value: -"Token contract address (0x...) for multi-chain pre-trade token risk."New value: +"Optional token address"Input schema / requiredAdded value: +[
+ "address"
+]Output schema / (root)Previous value: -{
- "properties": {
- "attestation": {
- "description": "Ed25519 attestation over the response body; verify offline against /.well-known/lion-compliance-key.json.",
- "type": "object"
- },
- "checks_run": {
- "description": "Which sub-checks ran, e.g. ofac_sdn, domain_trust, token_risk, firmographics.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "flags": {
- "description": "Specific risk/compliance flags raised (empty array when CLEAR).",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "receipt": {
- "description": "Present when ?receipt=1: the portable LION_SIGNED_COMPLIANCE_RECEIPT_V1 (content-addressed, Ed25519-signed, offline-reverifiable).",
- "type": "object"
- },
- "subject": {
- "description": "The screened counterparty (address / domain / token / name).",
- "type": "string"
- },
- "verdict": {
- "description": "Overall counterparty verdict across the checks you supplied.",
- "enum": [
- "CLEAR",
- "REVIEW"
- ],
- "type": "string"
- }
- },
- "required": [
- "verdict",
- "flags",
- "checks_run",
- "attestation"
- ],
- "type": "object"
-}New value: +nulllion_composite_bundle7 fields changedInput schema / properties / addressRemoved value: -{
- "description": "0x... address -> eth_getBalance + eth_getCode (native balance + contract flag), per chain.",
- "type": "string"
-}Input schema / properties / chain / descriptionRemoved value: -"Which chain(s) to read: base (default), ethereum (eip155:1), or both. Payment is always USDC on Base."Input schema / properties / chain / enumRemoved value: -[
- "base",
- "ethereum",
- "both"
-]Input schema / properties / fieldsRemoved value: -{
- "description": "Enrich field names to return, e.g. [\"country\",\"revenue_usd\"]. Omit when using format=apollo_org.",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Input schema / properties / formatRemoved value: -{
- "description": "Apollo-organization-shaped enrich half (pass identifier/domain).",
- "enum": [
- "apollo_org"
- ],
- "type": "string"
-}Input schema / properties / identifier / descriptionRemoved value: -"Company/org NAME, DOMAIN (e.g. \"coinbase.com\"), or US TICKER for verifiable firmographics + financials."Input schema / properties / txRemoved value: -{
- "description": "0x... tx hash -> eth_getTransactionReceipt (status, block, from, to), per chain.",
- "type": "string"
-}lion_cpg_product_intel4 fields changedInput schema / properties / barcode / descriptionPrevious value: -"GTIN/EAN/UPC barcode, e.g. \"5449000000996\". Primary."New value: +"EAN/UPC barcode"Input schema / properties / domainRemoved value: -{
- "description": "food|beauty|products|petfood (default auto with fallback).",
- "type": "string"
-}Input schema / properties / name / descriptionPrevious value: -"Product name fallback for search (e.g. \"coca cola\")."New value: +"Product name search"Input schema / requiredAdded value: +[]lion_credits_purchaselion_declare_need4 fields changedInput schema / properties / categoryRemoved value: -{
- "description": "Optional category hint, e.g. enrichment, location, token_risk, market_data.",
- "type": "string"
-}Input schema / properties / max_price_usdcRemoved value: -{
- "description": "Optional max price per call you would pay in USDC.",
- "type": "number"
-}Input schema / properties / need / descriptionPrevious value: -"Plain-language description of what you need, e.g. \"company enrichment for a domain\", \"solar potential for an address\", \"is this Base token a honeypot\"."New value: +"What you need in plain language"Output schema / (root)Previous value: -{
- "properties": {
- "declared_need": {
- "type": "string"
- },
- "free_sample": {
- "properties": {
- "call_example": {
- "type": "string"
- },
- "description": {
- "type": "string"
- },
- "endpoint": {
- "type": "string"
- },
- "free_tool": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "matched_capability": {
- "type": "string"
- },
- "note": {
- "type": "string"
- },
- "ref": {
- "type": "string"
- },
- "upgrade_to_paid": {
- "properties": {
- "curl_example": {
- "type": "string"
- },
- "endpoint": {
- "type": "string"
- },
- "how_to_pay": {
- "type": "object"
- },
- "paid_tool": {
- "type": "string"
- },
- "payment": {
- "type": "string"
- },
- "price_usdc": {
- "type": "string"
- },
- "recommendation": {
- "type": "string"
- },
- "value_comparison": {
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "declared_need",
- "free_sample",
- "upgrade_to_paid"
- ],
- "type": "object"
-}New value: +nulllion_deep_research4 fields changedInput schema / properties / domainRemoved value: -{
- "description": "Optional domain override for firmographics + domain trust, e.g. \"stripe.com\".",
- "type": "string"
-}Input schema / properties / numRemoved value: -{
- "description": "Search results to cover (default 5, max 10).",
- "type": "number"
-}Input schema / properties / q / descriptionPrevious value: -"Company name, domain, or research topic, e.g. \"stripe.com\" or \"Anthropic\"."New value: +"Research query"Input schema / properties / receiptRemoved value: -{
- "description": "Pass \"1\" to embed a portable research receipt.",
- "type": "string"
-}lion_domain_intel1 field changedInput schema / properties / domain / descriptionRemoved value: -"Domain or hostname to score, e.g. \"stripe.com\" or \"api.example.com\". Scheme/path stripped."lion_enrich_v19 fields changedInput schema / properties / domainRemoved value: -{
- "description": "Company domain (e.g. \"coinbase.com\") - Apollo org-enrich style input. Use with format=apollo_org for a drop-in replacement of Apollo Org Enrich.",
- "type": "string"
-}Input schema / properties / fields / descriptionPrevious value: -"Field names to return, e.g. [\"inception_year\",\"country\",\"revenue_usd\"]. Query string: fields=inception_year,country,revenue_usd. Omit when using format=apollo_org."New value: +"Comma-separated field names"Input schema / properties / fields / itemsRemoved value: -{
- "type": "string"
-}Input schema / properties / fields / typePrevious value: -"array"New value: +"string"Input schema / properties / format / descriptionPrevious value: -"Set to \"apollo_org\" for a keyless drop-in replacement of Apollo Org Enrich: pass domain (or identifier) and receive an Apollo-shaped organization{} object (name, website_url, primary_domain, founded_year, estimated_num_employees, industry, country, publicly_traded_symbol/exchange, annual_revenue) at ~$0.018 vs Apollo org-enrich $0.0495. No PII."New value: +"optional apollo_org"Input schema / properties / format / enumRemoved value: -[
- "apollo_org"
-]Input schema / properties / identifier / descriptionRemoved value: -"Company/org NAME (e.g. \"Coinbase\"), a DOMAIN (e.g. \"coinbase.com\"), or US TICKER (e.g. \"AAPL\"). Provide this OR domain."Input schema / properties / typeRemoved value: -{
- "description": "Optional entity type hint. Default \"company\".",
- "type": "string"
-}Input schema / requiredAdded value: +[
+ "identifier"
+]lion_enrichment_tx_bundle4 fields changedInput schema / properties / entityRemoved value: -{
- "description": "Topic/brand/company/domain for enrichment (optional if tx only).",
- "type": "string"
-}Input schema / properties / identifierAdded value: +{
+ "description": "Company or org name",
+ "type": "string"
+}Input schema / properties / tx / descriptionPrevious value: -"Base tx hash 0x... for receipt + calldata decode (optional if entity only)."New value: +"Optional Base tx hash"Input schema / requiredAdded value: +[
+ "identifier"
+]lion_keyless_base_rpc7 fields changedInput schema / properties / chainAdded value: +{
+ "description": "base|ethereum",
+ "type": "string"
+}Input schema / properties / idRemoved value: -{
- "description": "JSON-RPC request id.",
- "type": "integer"
-}Input schema / properties / jsonrpcRemoved value: -{
- "description": "JSON-RPC version, \"2.0\". POST the standard JSON-RPC body (object, or array for a batch up to 10).",
- "type": "string"
-}Input schema / properties / method / descriptionPrevious value: -"Read-only Base RPC method, e.g. eth_call, eth_getBalance, eth_getLogs, eth_blockNumber."New value: +"JSON-RPC method e.g. eth_blockNumber"Input schema / properties / params / descriptionPrevious value: -"JSON-RPC params for the method."New value: +"JSON array string of params"Input schema / properties / params / typePrevious value: -"array"New value: +"string"Input schema / requiredPrevious value: -[
- "jsonrpc",
- "method"
-]New value: +[
+ "method"
+]lion_location_solar_enrichment4 fields changedInput schema / properties / address / descriptionRemoved value: -"Free-form place/property address to geocode. Provide this OR lat+lon."Input schema / properties / lat / descriptionRemoved value: -"Latitude (-90..90). Use with lon to skip geocoding."Input schema / properties / lon / descriptionRemoved value: -"Longitude (-180..180). Use with lat."Input schema / requiredAdded value: +[]lion_ofac_sanctions_screenlion_poi_business_search9 fields changedInput schema / properties / areaRemoved value: -{
- "description": "Place name to search within, geocoded to a bounding box, e.g. \"Soho, New York\". Provide this OR bbox.",
- "type": "string"
-}Input schema / properties / bboxRemoved value: -{
- "description": "Explicit bounding box \"south,west,north,east\" in decimal degrees. Provide this OR area.",
- "type": "string"
-}Input schema / properties / categoryRemoved value: -{
- "description": "Preset category: food, restaurant, cafe, bar, retail, grocery, hotel, health, pharmacy, finance, bank, fuel, automotive, education, gym. Provide this OR tag.",
- "type": "string"
-}Input schema / properties / latAdded value: +{
+ "type": "number"
+}Input schema / properties / limitRemoved value: -{
- "description": "Max results (default 25, max 50).",
- "type": "number"
-}Input schema / properties / lonAdded value: +{
+ "type": "number"
+}Input schema / properties / qAdded value: +{
+ "type": "string"
+}Input schema / properties / tagRemoved value: -{
- "description": "Raw OSM tag filter \"key=value\" (key in amenity|shop|tourism|leisure|office|craft|healthcare), e.g. \"shop=bakery\". Provide this OR category.",
- "type": "string"
-}Input schema / requiredAdded value: +[
+ "q"
+]lion_quick_intel2 fields changedInput schema / properties / entity / descriptionRemoved value: -"Topic/brand/company/domain to score (e.g. \"Stripe\", \"coinbase.com\")."Output schema / (root)Previous value: -{
- "properties": {
- "as_of": {
- "format": "date-time",
- "type": "string"
- },
- "asset_id": {
- "type": "string"
- },
- "attention_score": {
- "type": "number"
- },
- "entity": {
- "type": "string"
- },
- "free_tier_note": {
- "type": "string"
- },
- "momentum": {
- "type": "number"
- },
- "ref": {
- "type": [
- "string",
- "null"
- ]
- },
- "signals": {
- "properties": {
- "hiring_momentum": {
- "type": "string"
- },
- "recent_funding": {
- "type": "boolean"
- },
- "web_presence": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "summary": {
- "type": "string"
- },
- "upgrade": {
- "properties": {
- "curl_example": {
- "type": "string"
- },
- "direct_action": {
- "type": "string"
- },
- "how_to_pay": {
- "type": "object"
- },
- "paid_endpoint": {
- "type": "string"
- },
- "payment_method": {
- "type": "string"
- },
- "price_usdc": {
- "type": "string"
- },
- "recommendation": {
- "type": "string"
- },
- "value_comparison": {
- "type": "object"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "asset_id",
- "entity",
- "attention_score",
- "upgrade"
- ],
- "type": "object"
-}New value: +nulllion_sanctions_screenlion_scrape1 field changedInput schema / properties / url / descriptionPrevious value: -"Absolute http(s) URL to scrape, e.g. \"https://stripe.com\"."New value: +"Absolute http(s) URL"lion_sec_financials3 fields changedInput schema / properties / cik / descriptionRemoved value: -"SEC CIK (digits), e.g. \"0000320193\" or \"320193\"."Input schema / properties / ticker / descriptionRemoved value: -"US exchange ticker, e.g. \"AAPL\". Provide this OR cik."Input schema / requiredAdded value: +[]lion_social_signal_intel4 fields changedInput schema / properties / entityAdded value: +{
+ "type": "string"
+}Input schema / properties / qAdded value: +{
+ "type": "string"
+}Input schema / properties / topic / descriptionRemoved value: -"Search query, e.g. \"ai agents\" or \"base crypto\"."Input schema / requiredAdded value: +[]lion_token_risk_indicators3 fields changedInput schema / properties / chain / descriptionPrevious value: -"Optional, default base. Payment is always USDC on Base."New value: +"base|ethereum|solana"Input schema / properties / chain / enumRemoved value: -[
- "base",
- "ethereum",
- "solana"
-]Input schema / properties / token / descriptionPrevious value: -"Token address. Base/Ethereum: 0x + 40 hex. Solana: base58 mint."New value: +"Token contract or mint"lion_tx_receipt_decoded1 field changedInput schema / properties / tx / descriptionPrevious value: -"Base tx hash 0x... to fetch receipt and decode calldata."New value: +"Base tx hash 0x..."lion_vat_validation4 fields changedInput schema / properties / country / descriptionRemoved value: -"EU country code, e.g. \"IE\", \"DE\", \"FR\" (EL=Greece, XI=Northern Ireland)."Input schema / properties / number / descriptionRemoved value: -"VAT number without the country prefix. Use with country."Input schema / properties / vat / descriptionPrevious value: -"Full EU VAT number incl. country prefix, e.g. \"IE6388047V\". Provide this OR country+number."New value: +"Full EU VAT e.g. IE6388047V"Input schema / requiredAdded value: +[]lion_verified_company_file3 fields changedInput schema / properties / domain / descriptionAdded value: +"Company domain e.g. stripe.com"Input schema / properties / sampleRemoved value: -{
- "type": "string"
-}Input schema / properties / vatRemoved value: -{
- "type": "string"
-}lion_web_enrichment_bundle4 fields changedInput schema / properties / domainAdded value: +{
+ "type": "string"
+}Input schema / properties / entityRemoved value: -{
- "description": "Topic/brand/company/domain to score, e.g. \"Coinbase\", \"base.org\", \"stablecoins\". Echoed back; never used to fetch or return personal data.",
- "type": "string"
-}Input schema / properties / identifierAdded value: +{
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "entity"
-]New value: +[]lion_web_search2 fields changedInput schema / properties / numRemoved value: -{
- "description": "Max results to return (default 8, max 20).",
- "type": "number"
-}Input schema / properties / q / descriptionPrevious value: -"Search query, e.g. \"base layer 2 ecosystem\"."New value: +"Search query"lion_wikidata_firmographics4 fields changedInput schema / properties / entity / descriptionRemoved value: -"Company/organization name to resolve, e.g. \"Coinbase\". Provide this OR qid."Input schema / properties / qAdded value: +{
+ "type": "string"
+}Input schema / properties / qid / descriptionRemoved value: -"Wikidata QID, e.g. \"Q5463952\"."Input schema / requiredAdded value: +[]lion_x402_intellionSafetyDailyPassquery_x402_economy_intelultraFastBatchRiskultraFastFullStackBundleultraFastIsHoneypotultraFastLiquidityCheckultraFastPreSpendGateultraFastRugVectorultraFastSafetyStackultraFastSmartMoneyFlagquery_x402_economy_intellionSafetyDailyPasssafetyStackultraFastFullStackBundleultraFastPreSpendGateultraFastRugVectorultraFastSafetyStackultraFastSmartMoneyFlagsafetyStackultraFastBatchRiskultraFastIsHoneypotultraFastLiquidityChecklion_x402_intellion_verified_company_filelion_deep_researchlion_scrapePaid KYC, AML, and regulatory risk assessment over MCP via x402 USDC micropayments on Base.
High-frequency OFAC wallet screening and recurring signed x402 checks for autonomous agents.
Accountless public-source, SEC Form D and OFAC tools with x402 USDC payment on Base.
Pay-per-call compliance via x402: wallet sanctions, OFAC name, UK + US company verification.
Add one secure layer between your agents and this server.
