InvokeWorks

Ferramentas MCP pagas para agentes de IA, incluindo auditorias completas de DNS, TLS, HTTP e sites, medidas por LiveAuth

Documentação

InvokeWorks

Dê ao seu agente de IA ferramentas pagas úteis.

InvokeWorks é um servidor MCP de código aberto para ferramentas de agente pagas úteis. Seu principal recurso, site_audit, combina verificações de DNS, TLS, HTTP, redirecionamento e cabeçalhos de segurança em um único resultado estruturado por 5 sats por chamada.

Um agente pode executar uma verificação completa de site externo sem criar uma conta ou assinar uma API. O fluxo de sessão de prova de trabalho não requer etapa de pagamento humano. LiveAuth gerencia a autenticação e medição do MCP; InvokeWorks retorna o resultado e os metadados de cobrança, incluindo o recibo. Orçamentos de sessão e expiração ainda se aplicam.

Ferramentas

FerramentaFinalidadePreço
site_auditAuditoria combinada de DNS, TLS, HTTP e cabeçalhos de segurança5 sats
dns_lookupConsultas A, AAAA, CNAME, MX, TXT, NS e SOA1 sat
http_inspectStatus HTTP, redirecionamentos, cabeçalhos, tamanho, tempo e cabeçalhos de segurança2 sats
tls_inspectProtocolo TLS, cifra, certificado, SANs, validade e cadeia2 sats

Auditoria de Site

Execute uma auditoria combinada de DNS, TLS, HTTP e cabeçalhos de segurança de um site público. O LiveAuth mede site_audit a 5 sats/chamada através do gateway existente.

Exemplo de entrada (nomes de host simples usam HTTPS por padrão):

{ "target": "https://example.com" }

Exemplo de saída abreviada (ilustrativo; resultados reais variam):

{
  "hostname": "example.com",
  "score": 95,
  "issues": [
    {
      "severity": "warning",
      "code": "missing_csp",
      "message": "content-security-policy is absent; consider this recommended protection where appropriate."
    }
  ]
}

A resposta completa também inclui seções de DNS, TLS, HTTP e cabeçalhos de segurança. Consulte Auditoria de Site para cobertura e exemplos.

A pontuação é informativa, não é uma certificação formal de segurança: comece em 100, subtraia 25 por descoberta crítica e 5 por aviso, não subtraia nada por descobertas informativas e limite a 0–100. A presença de cabeçalhos não estabelece correção de política; as recomendações dependem da finalidade do endpoint. CSP frame-ancestors satisfaz a verificação de proteção de frame sem X-Frame-Options. HSTS é avaliado apenas em uma resposta HTTPS final.

DNS retorna registros A, AAAA, CNAME, MX e NS. Registros ausentes são arrays vazios; outras falhas de consulta aparecem em failedRecordTypes. TLS descreve o destino original (na porta da URL HTTPS, ou porta 443 para entradas HTTP), enquanto HTTP descreve a resposta final e a cadeia de redirecionamentos. A verificação TLS permanece ativada: certificados expirados/divergentes produzem descobertas sem retornar detalhes de certificado não verificados. Seções TLS/HTTP com falha são null; cabeçalhos de segurança são null quando HTTP não está disponível. Um destino inicial não público ou não resolvido falha na chamada. Falhas após a cobrança permanecem cobráveis com metadados sanitizados e recibos. Nenhum corpo de resposta é retornado.

Códigos de problema estáveis: dns_lookup_failed, tls_failed, tls_certificate_expired, tls_certificate_expiring (30 dias ou menos), tls_hostname_mismatch, tls_obsolete_protocol, http_failed, http_not_https, http_insecure_hop, http_error_status, missing_hsts, missing_csp, missing_x_content_type_options, missing_frame_protection, missing_referrer_policy, missing_permissions_policy.

Use InvokeWorks a partir de um cliente MCP

Conecte um cliente MCP HTTP Streamable a https://mcp.invokeworks.dev/mcp. Primeiro, obtenha um token de sessão MCP ativo para o projeto InvokeWorks através do fluxo de início/confirmação do LiveAuth. O caminho de prova de trabalho não requer conta de agente, assinatura de API ou etapa de pagamento humano. Forneça o JWT como Authorization: Bearer <liveauth-jwt>; a descoberta é pública, mas chamadas de ferramentas exigem autorização.

Esta configuração JavaScript usa o pacote de cliente MCP suportado pelos testes de integração do repositório. Defina LIVEAUTH_JWT para esse token de sessão e mantenha-o fora do controle de versão.

npm install @modelcontextprotocol/client@^2.0.0
import { Client, StreamableHTTPClientTransport } from '@modelcontextprotocol/client';

const jwt = process.env.LIVEAUTH_JWT;
if (!jwt) throw new Error('Set LIVEAUTH_JWT to an active InvokeWorks MCP session token');

// One ID per logical call. Keep this ID and the arguments unchanged on a retry.
const requestId = crypto.randomUUID();
const client = new Client({ name: 'site-audit-client', version: '1.0.0' });
const transport = new StreamableHTTPClientTransport(new URL('https://mcp.invokeworks.dev/mcp'), {
  requestInit: {
    headers: {
      Authorization: `Bearer ${jwt}`,
      'X-Request-Id': requestId,
    },
  },
});

try {
  await client.connect(transport);
  const result = await client.callTool({
    name: 'site_audit',
    arguments: { target: 'https://example.com' },
  });
  console.log(result); // Audit result plus _meta.liveauth billing metadata / receipt.
} finally {
  await client.close();
}

Exemplo de tarefa de agente: "Audite https://example.com e me diga os problemas mais importantes."

O agente pode invocar site_audit; o LiveAuth mede a execução aceita a 5 sats. X-Request-Id também é a chave de idempotência de cobrança. Mantenha-o e os argumentos inalterados para uma nova tentativa da mesma chamada, e use uma nova chave para uma nova chamada lógica. A cobrança segura para novas tentativas não armazena resultados em cache nem impede a reexecução do manipulador. Falhas de execução após a cobrança permanecem cobráveis. Consulte o guia de conexão.

Arquitetura

Agent / MCP Client
  → InvokeWorks
  → LiveAuth authentication + metering
  → site_audit
  → receipt / result

InvokeWorks usa @liveauth-labs/mcp-server ^1.2.0. A validação de entrada acontece antes do gateway; o LiveAuth valida autorização e cobra antes da execução da ferramenta.

  • apps/server: serviço Hono/Node usando MCP SDK v2 createMcpHandler(), com compatibilidade moderna sem estado 2026-07-28 e compatibilidade da era 2025 suportada pelo SDK.
  • apps/web: site estático Astro.
  • packages/tools: ferramentas independentes de transporte e registro de catálogo compartilhado.
  • packages/liveauth: o único pacote que importa o SDK público @liveauth-labs/mcp-server.
  • packages/shared: utilitários de ambiente e requisição.
  • tests/integration: testes oficiais de cliente MCP → servidor → adaptador LiveAuth → ferramenta.

Não há banco de dados, sistema de conta InvokeWorks, carteira ou implementação de cobrança.

Desenvolvimento local

Requer Node.js 22+ e pnpm 10.

corepack enable
pnpm install
cp .env.example .env
pnpm dev

O servidor escuta em http://localhost:3000/mcp; a saúde está em /health. Execute o site com pnpm dev:web.

Para testes de transporte local sem uma conta LiveAuth, defina NODE_ENV=test e LIVEAUTH_BYPASS_FOR_TESTS=true; apenas o token literal test-token é aceito. Esta configuração é rejeitada em produção.

Configuração

VariávelObrigatóriaDescrição
LIVEAUTH_PUBLIC_KEYProduçãoChave pública do projeto LiveAuth (la_pk_…)
LIVEAUTH_API_URLNãoPadrão para https://api.liveauth.app
HOST / PORTNãoPadrão para 0.0.0.0:3000
LOG_LEVELNãoNível de log estruturado

Nunca envie .env ou tokens. Clientes enviam Authorization: Bearer <LiveAuth JWT>. Forneça um X-Request-Id estável e único em novas tentativas; ele se torna a chave de idempotência do LiveAuth. Recibos assinados são retornados sob o resultado MCP _meta.liveauth.

Adicionando uma ferramenta

  1. Crie um módulo em packages/tools/src.
  2. Chame defineTool() com um esquema Zod v4, nome estável, descrições, preço em sats, exemplos e manipulador.
  3. Injete E/S externa atrás de uma interface estreita.
  4. Adicione-o a tools em packages/tools/src/index.ts.
  5. Adicione testes de manipulador e segurança.

O servidor MCP e o catálogo Astro consomem o registro automaticamente. Manipuladores retornam { data } e não sabem nada sobre MCP ou LiveAuth.

Validação

pnpm lint
pnpm typecheck
pnpm test
pnpm build
pnpm test:integration

Testes de integração usam o cliente oficial MCP Streamable HTTP. Chamadas reais de produção do LiveAuth são separadas e opcionais porque exigem um projeto de cliente e sessão de teste financiada.

Modelo de segurança

http_inspect aceita apenas HTTP(S), rejeita credenciais em URL, resolve cada endereço, rejeita qualquer resposta não pública, fixa um endereço validado na conexão e valida redirecionamentos novamente. Redirecionamentos, bytes de resposta e tempo são limitados; cabeçalhos do chamador nunca são encaminhados. tls_inspect aplica a mesma política de destino e fixação. Corpos MCP são limitados a 64 KiB. Logs omitem dados de autorização.

Implante atrás de TLS com lista de permissões de Host público, limites de concorrência/taxa e timeouts upstream. O LiveAuth permanece autoritativo para orçamentos de sessão e cobrança. Consulte SECURITY.md.

Docker e implantação

docker build -f apps/server/Dockerfile -t invokeworks-mcp .
docker run --rm -p 3000:3000 --env-file .env invokeworks-mcp

Roteie mcp.invokeworks.dev para a porta 3000 e preserve Authorization, MCP-Protocol-Version, Accept e X-Request-Id. Sirva apps/web/dist estaticamente para invokeworks.dev. Nenhum provedor de hospedagem é assumido.

Configuração do portal LiveAuth

Usando apenas funcionalidades comuns voltadas ao cliente:

  1. Crie um projeto LiveAuth e obtenha sua chave pública.
  2. Registre dns_lookup, http_inspect, tls_inspect e site_audit a 1, 2, 2 e 5 sats.
  3. Configure orçamentos/limites de taxa e liquidação Lightning no LiveAuth.
  4. Defina a chave pública no ambiente do servidor e execute um teste real opcional de cobrança/recibo.

O adaptador passa preços explícitos, mas os valores do portal devem corresponder. Consulte docs/liveauth-dogfood.md.

Contribuição e licença

Leia CONTRIBUTING.md. InvokeWorks está disponível sob a Licença MIT.