ntriq-agentshop
ntriq AgentShop — Servicios de datos de IA mediante micropagos x402
Endpoints de inteligencia de datos impulsados por IA con precios de pago por uso mediante micropagos x402 (USDC en Base). Sin claves API, sin suscripciones, sin límites de tasa. Los agentes de IA pagan solo por lo que usan. Inferencia 100% local — cero llamadas a API externas.
Servicios (11 tipos × 2 niveles de precios = 22 endpoints)
Servicios de visión (Entrada de imagen)
Servicio | Endpoint | Individual | Lote (máx. 500) |
Texto alternativo |
| $0.01 |
|
Inteligencia documental |
| $0.05 |
|
Extracción de facturas |
| $0.03 |
|
Datos de capturas |
| $0.02 |
|
Planos |
| $0.05 |
|
Servicios de texto / PLN
Servicio | Endpoint | Individual | Lote (máx. 500) |
Detección de PII |
| $0.02 |
|
Sentimiento |
| $0.01 |
|
Generación de contenido |
| $0.02 |
|
Verificación de cumplimiento |
| $0.03 |
|
Revisión de código |
| $0.05 |
|
Radar de phishing |
| $0.03 |
|
Cómo funciona
AI Agent
│
▼ POST /alt-text
x402.ntriq.co.kr
│
├─ 402 Payment Required ($0.01 USDC, Base mainnet)
│
▼ Agent signs EIP-3009 (gasless) → retries with payment
│
├─ Facilitator verifies payment
│
▼ 200 OK + JSON result
│
Mac Mini (local Qwen2.5-VL / Qwen2.5:7b)
└─ 100% local inference, zero external API callsProtocolo de pago: x402 — USDC en Base, autorización sin gas EIP-3009
Detalles del servicio
Texto alternativo — /alt-text ($0.01) · /alt-text-batch ($3.00)
Genera texto alternativo compatible con WCAG (≤125 caracteres) y descripciones detalladas de accesibilidad.
POST /alt-text
{ "image_url": "https://example.com/product.jpg" }
# Response
{ "alt_text": "Red leather handbag with gold clasp", "description": "..." }Lote: { "images": ["url1", "url2", ...], "context": "catálogo de comercio electrónico" }
Inteligencia documental — /document-intel ($0.05) · lote ($15.00)
OCR, clasificación, extracción de tablas y resumen a partir de imágenes de documentos.
POST /document-intel
{ "image_url": "...", "analysis_type": "extract|summarize|classify|table" }Extracción de facturas — /invoice-extract ($0.03) · lote ($9.00)
Extrae campos estructurados de facturas y recibos: proveedor, importes, partidas, fechas.
POST /invoice-extract
{ "image_url": "..." }
# Response
{ "invoice": { "vendor_name": "...", "total": 1250.00, "line_items": [...] } }Datos de capturas de pantalla — /screenshot-data ($0.02) · lote ($6.00)
Extrae texto, elementos de interfaz, diseño y tablas de datos de capturas de pantalla.
POST /screenshot-data
{ "image_url": "...", "extract_type": "full|text|data|layout" }Planos — /blueprint ($0.05) · lote ($15.00)
Analiza planos arquitectónicos y de planta. Extrae habitaciones, dimensiones, materiales.
POST /blueprint
{ "image_url": "...", "analysis_type": "full|rooms|dimensions|materials" }
# Response
{ "rooms": [{"name": "Living Room", "area": "24 m²"}], "total_area": "85 m²" }Detección de PII — /pii-detect ($0.02) · lote ($6.00)
Detecta y opcionalmente enmascara PII: correos electrónicos, teléfonos, SSN, nombres, direcciones, tarjetas de crédito.
POST /pii-detect
{ "text": "Contact John at john@email.com", "mask": true }
# Response
{ "pii_found": [...], "risk_level": "high", "masked_text": "Contact [NAME] at [EMAIL]" }Sentimiento — /sentiment ($0.01) · lote ($3.00)
Analiza el sentimiento, las emociones y la intención con puntuaciones de confianza.
POST /sentiment
{ "text": "This product is amazing!" }
# Response
{ "sentiment": "positive", "confidence": 0.95, "intent": "praise" }Generación de contenido — /content-generate ($0.02) · lote ($6.00)
Genera publicaciones de blog, correos electrónicos, redes sociales, descripciones de productos, informes y textos publicitarios.
POST /content-generate
{ "prompt": "benefits of standing desks", "style": "blog|email|social|product|report|ad", "tone": "professional", "max_words": 500 }Verificación de cumplimiento — /compliance-check ($0.03) · lote ($9.00)
Analiza texto en busca de violaciones de GDPR, HIPAA, SOX o cumplimiento general. Devuelve el nivel de riesgo y recomendaciones de remediación.
POST /compliance-check
{ "text": "We store passwords in plain text.", "framework": "GDPR", "jurisdiction": "EU" }
# Response
{ "compliant": false, "risk_level": "critical", "issues": [...] }Revisión de código — /code-review ($0.05) · lote ($15.00)
Revisión de código impulsada por IA para vulnerabilidades de seguridad, rendimiento y calidad. Cualquier lenguaje.
POST /code-review
{ "code": "SELECT * FROM users WHERE id='" + id + "'", "language": "sql", "focus": "security" }
# Response
{ "overall_score": 2, "issues": [{"severity": "critical", "description": "SQL injection"}] }Radar de phishing — /phish-radar ($0.03) · lote ($9.00)
Detecta URLs y dominios de phishing. Identifica typosquatting, ataques de homoglifos, suplantación de marca.
POST /phish-radar
{ "url": "https://paypa1.com/login" }
# Response
{ "is_suspicious": true, "risk_score": 92, "risk_level": "critical", "legitimate_brand": "PayPal" }Inicio rápido
Catálogo de servicios
curl https://x402.ntriq.co.kr/servicesVerificación de estado
curl https://x402.ntriq.co.kr/healthPrueba (espera una respuesta 402)
curl -X POST https://x402.ntriq.co.kr/sentiment \
-H "Content-Type: application/json" \
-d '{"text": "Hello world"}'
# → 402 Payment RequiredArquitectura
Mac Mini (Apple Silicon)
├── x402 Server (Node.js + tsx) :4021
├── qwen-vision-api (Python) :8100 ← Qwen2.5-VL:7b
├── Ollama :11434 ← Qwen2.5:7b, Gemma4
└── Cloudflare Tunnel → x402.ntriq.co.krPago: USDC en la red principal de Base mediante el protocolo x402
Billetera: 0x124AaFfF8Ef45F2cA953807aF09Aacec2D9F8307
Facilitador: https://facilitator.openx402.ai
Habilidades de ClawHub
Instala a través de ClawHub para habilitar estos servicios en tu agente de IA:
clawhub install ntriq-x402-alt-text
clawhub install ntriq-x402-sentiment
clawhub install ntriq-x402-code-review
# ... and moreCreado por ntriq — inferencia 100% local, margen 100%
Available Tools
6 toolsalt_textA
Generate accessible alt text descriptions for images. Cost: $0.01 USDC per call.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | No | Public URL of image | |
| image_base64 | No | Base64-encoded image | |
| style | No | Alt text style | concise |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important context about the cost ($0.01 USDC per call), which isn't captured in structured fields. However, it doesn't describe other behavioral aspects like rate limits, authentication needs, response format, or error conditions.
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 with only two sentences, both of which earn their place. The first sentence states the core purpose, and the second provides critical cost information. There's zero wasted text or redundancy.
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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the core purpose and cost but lacks information about output format, error handling, or when to use versus alternatives. The absence of an output schema means the description should ideally explain what the tool returns.
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 description coverage is 100%, so all parameters are documented in the input schema. The description adds no additional parameter semantics beyond what's already in the schema (image_url, image_base64, style). The baseline score of 3 is appropriate when the schema does the heavy lifting.
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 with a specific verb ('Generate') and resource ('accessible alt text descriptions for images'), making it immediately understandable. It distinguishes itself from sibling tools like document_intelligence or sentiment_analysis by focusing specifically on image accessibility.
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 provides no guidance on when to use this tool versus alternatives. While it mentions a cost per call, it doesn't specify scenarios where alt text generation is appropriate versus other image-related tools like screenshot_data, nor does it mention prerequisites or constraints beyond the cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
document_intelligenceA
Analyze document images — extract text, summarize, classify, or extract tables. Accepts image URL or base64. Cost: $0.05 USDC per call (x402, Base mainnet).
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | No | Public URL of document image | |
| image_base64 | No | Base64-encoded image data | |
| analysis_type | No | Type of analysis to perform | extract |
| language | No | Output language code (e.g. en, ko, ja) | en |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses the cost ('$0.05 USDC per call') and blockchain details ('x402, Base mainnet'), which are critical for usage decisions. It also implies mutation/processing behavior through 'analyze' and specifies input formats (URL or base64). However, it doesn't mention rate limits, error conditions, or output format details.
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 and front-loaded: the first clause states the core purpose, followed by key input constraints and cost details. Every sentence earns its place with no wasted words. The structure efficiently communicates essential information in minimal space.
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?
Given 4 parameters with full schema coverage but no annotations and no output schema, the description is moderately complete. It covers purpose, input formats, analysis types, and cost, but lacks output format details, error handling, and sibling differentiation. For a tool with significant functionality and cost implications, more behavioral context would be beneficial.
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%, so the schema already documents all parameters thoroughly. The description adds marginal value by mentioning 'image URL or base64' and listing analysis types, but doesn't provide additional syntax, format, or usage details beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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: 'Analyze document images — extract text, summarize, classify, or extract tables.' It specifies the verb ('analyze') and resource ('document images'), and lists the specific analysis types. However, it doesn't explicitly differentiate from sibling tools like 'invoice_extract' or 'screenshot_data' which might have overlapping functionality.
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 provides no guidance on when to use this tool versus alternatives. It mentions cost but doesn't specify scenarios where 'document_intelligence' is preferred over siblings like 'invoice_extract' (for invoices) or 'alt_text' (for accessibility). No prerequisites, exclusions, or comparative context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoice_extractA
Extract structured fields from invoice or receipt images. Returns vendor, line items, totals, dates, and more as JSON. Cost: $0.03 USDC per call.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | No | Public URL of invoice image | |
| image_base64 | No | Base64-encoded invoice image | |
| language | No | Output language code | en |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a paid service ('Cost: $0.03 USDC per call'), returns structured JSON data, and processes images via URL or base64. However, it doesn't mention rate limits, error conditions, or processing time.
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 concise sentences with zero waste: the first explains purpose and output, the second provides critical cost information. Every element earns its place and is front-loaded with essential 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 no annotations and no output schema, the description does well by explaining what data is extracted ('vendor, line items, totals, dates, and more') and the cost implication. However, it could better describe the JSON structure or error scenarios given the absence of output schema.
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%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, meeting the baseline for high schema 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 clearly states the specific action ('Extract structured fields'), the resource ('from invoice or receipt images'), and the output format ('as JSON'). It distinguishes itself from siblings by focusing on invoice/receipt data extraction rather than general document analysis or other tasks.
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 implies usage context through 'invoice or receipt images' and mentions cost, but doesn't explicitly state when to use this tool versus alternatives like 'document_intelligence' or 'screenshot_data'. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pii_detectA
Detect and redact Personally Identifiable Information (PII) in text. Returns detected PII types and redacted text. Cost: $0.02 USDC per call.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to scan for PII | |
| redact | No | Whether to return redacted text |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the core functionality (detect and redact PII) and output (returns detected PII types and redacted text), and adds valuable context with the cost per call. However, it lacks details on rate limits, error handling, or specific PII types covered.
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 front-loaded with the core purpose, followed by output details and cost information in two concise sentences. Every sentence adds value without redundancy, making it efficient and well-structured.
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?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is fairly complete: it covers purpose, output, and cost. However, it could improve by specifying PII types or error scenarios, slightly reducing completeness for a tool with no output schema.
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%, so the schema already documents both parameters ('text' and 'redact') thoroughly. The description does not add any parameter-specific semantics beyond what the schema provides, such as examples or format details, meeting the baseline for high schema 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 clearly states the tool's purpose with specific verbs ('detect and redact') and resource ('PII in text'), and distinguishes it from siblings by focusing on PII detection rather than alternative text analysis tasks like sentiment analysis or document intelligence.
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 implies usage for PII detection scenarios but provides no explicit guidance on when to use this tool versus alternatives (e.g., for general text processing vs. PII-specific tasks) or any prerequisites. It mentions cost, which hints at financial considerations, but lacks clear when/when-not directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screenshot_dataB
Extract structured data from screenshots of dashboards, tables, forms, or UIs. Cost: $0.02 USDC per call.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | No | Public URL of screenshot | |
| image_base64 | No | Base64-encoded screenshot | |
| extraction_hint | No | Hint about what to extract (e.g. 'extract all table data') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by stating the cost ('$0.02 USDC per call'), which is a key behavioral trait not covered by the schema. However, it lacks details on other aspects such as rate limits, error handling, or output format, leaving gaps in transparency for a tool that performs data extraction.
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 highly concise and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and cost. Every sentence earns its place by providing essential information without redundancy or fluff, making it easy for an agent to parse quickly.
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?
Given the tool's complexity (data extraction from images) and the absence of both annotations and an output schema, the description is partially complete. It covers the purpose and cost but lacks details on behavioral traits, output format, and usage guidelines. This leaves significant gaps for an agent to understand how to invoke and interpret results effectively.
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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description does not add any semantic details beyond what the schema provides, such as examples or constraints for 'extraction_hint'. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description neither compensates nor detracts.
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: 'Extract structured data from screenshots of dashboards, tables, forms, or UIs.' It specifies the verb ('extract') and resource ('structured data'), and identifies the source material ('screenshots'). However, it does not explicitly differentiate from sibling tools like 'document_intelligence' or 'invoice_extract', which may also extract data from documents, leaving some ambiguity about when to choose this tool over others.
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 provides no guidance on when to use this tool versus alternatives. It mentions the cost per call, which is a usage consideration, but does not specify contexts, prerequisites, or exclusions. Without explicit when-to-use or when-not-to-use instructions, the agent lacks clear direction for selection among sibling tools like 'alt_text' or 'sentiment_analysis'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sentiment_analysisA
Analyze sentiment of text — returns score, label, and key phrases. Cost: $0.01 USDC per call.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to analyze | |
| language | No | Language of the text | en |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds context by specifying the cost ('$0.01 USDC per call'), which is a key behavioral trait not covered by the schema. However, it doesn't mention other aspects like rate limits, error handling, or response format details.
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 front-loaded with the core purpose and efficiently adds cost information in a single, waste-free sentence. Every part of the description earns its place by providing essential information without redundancy.
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?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is somewhat complete by stating the purpose and cost. However, it lacks details on output structure (e.g., format of 'score, label, and key phrases'), error cases, or usage context, leaving gaps for an AI agent.
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%, so the schema already documents both parameters ('text' and 'language') adequately. The description does not add any meaning beyond what the schema provides for these parameters, maintaining the baseline score of 3.
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 with a specific verb ('Analyze') and resource ('sentiment of text'), and distinguishes it from siblings by specifying what it returns ('score, label, and key phrases'). It goes beyond the name to explain the output, making it highly specific and differentiated.
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 provides no guidance on when to use this tool versus alternatives like 'pii_detect' or 'document_intelligence', nor does it mention any prerequisites or exclusions. It lacks context for tool selection among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
v1.0.0- First observed
alt_text - First observed
document_intelligence - First observed
invoice_extract - First observed
pii_detect - First observed
screenshot_data - First observed
sentiment_analysis
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose with no overlap: alt_text for image descriptions, document_intelligence for document analysis, invoice_extract for invoice processing, pii_detect for PII handling, screenshot_data for screenshot extraction, and sentiment_analysis for text sentiment. The descriptions make it easy to differentiate between them.
The tools use a consistent snake_case naming convention throughout, which is good. However, there is a minor deviation in naming style: most tools use descriptive compound names (e.g., sentiment_analysis, invoice_extract), but 'alt_text' is simpler and less descriptive compared to others, slightly breaking the pattern.
With 6 tools, this server is well-scoped for its apparent domain of document and image processing. Each tool serves a specific, useful function, and the count is neither too sparse nor overwhelming, fitting typical expectations for such a specialized server.
The toolset covers key areas in document and image analysis, including text extraction, sentiment analysis, PII detection, and structured data extraction from various sources. A minor gap is the lack of tools for editing or modifying documents/images, but the provided tools offer comprehensive analysis capabilities for the inferred domain.
Related MCP Connectors
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Pay-per-call MCP tools via x402 (USDC on Base): QR codes, images, text analysis, web fetch.
337 MCP tools with x402 micropayments on Base. $0.001/call. No signup, no API keys.