Why expose enrichment over MCP instead of an API?

Best move: ship the enrichment as an MCP tool, because the thing consuming it is an agent, and agents call tools, not endpoints.

Why it works: an MCP host discovers the tool, reads its schema, and calls it inside the model’s reasoning loop. A REST API makes a developer write the client, wire the auth, and hand-craft the tool definition before any of that can happen.

Key takeaways

• MCP is the native calling convention for agent hosts (Claude, Cursor, ChatGPT). A REST API is not, so it needs a hand-written client and a tool definition first.
• An MCP tool ships its own input and output schema, so the agent learns how to call it without a documentation-to-glue-code step.
• Keyless works over MCP because the server owns the crawl and rate-limits. The paid tier upgrades to OAuth, which MCP already defines.
• Enrichment over MCP runs inside one reasoning turn, so the agent acts on the dossier mid-task instead of round-tripping through your backend.
• REST still wins for bulk export and non-agent ETL. The two are not rivals, and the consumer picks the surface that fits.

What does an agent skip when it calls MCP instead of REST?

Everything between “here is an endpoint” and “the model can use it.” With a REST API, a developer picks or writes a client library, handles the auth handshake, parses the JSON response, maps the error codes, and then translates the whole thing into a tool definition the model understands. That definition drifts every time the API changes.

MCP collapses that work. The host owns the transport (streamable HTTP), the discovery (a tools/list call returns the tool and its schema), and the invocation (a tools/call with typed arguments). You add one endpoint URL, mcp.bassethound.ai/mcp, once. The agent reads the schema for sniff_domain(domain, profile) and knows the two arguments, the profile options, and the shape of the dossier it gets back.

The payoff is not saved keystrokes. It is that the tool description lives with the tool, so it stays correct. When the output grows a field, the schema the agent reads grows with it, and no client on your side gets regenerated. You maintain a crawl, not a fleet of SDKs.

How does auth work when there is no API key?

Two tiers, one protocol. The free tier is keyless. You point a host at the endpoint and call it, and the server rate-limits. That works because Bassethound owns the crawl. No upstream vendor key passes through, so you provision nothing and rotate nothing. Keyless is structural here, not a promotion.

The paid tier upgrades to OAuth. The MCP authorization spec defines that flow on the OAuth framework, so the host runs the token exchange, the server checks the token, and it grants higher depth and volume. You never paste a secret into a config file.

Compare the REST path. You register, generate a key, store it in an environment variable or a secrets manager, attach it to every request, and rotate it on a schedule. Each of those is a place a key leaks or expires. The MCP model pushes the credential lifecycle onto the host and the OAuth flow, where it belongs, and keeps the free path free of credentials entirely.

When should you still ship a REST API?

Be honest about the fit. MCP is built for interactive, agent-driven work, one investigation at a time. It is not the right shape for every consumer.

Ship REST when the caller is a batch job. Enriching a million domains from a nightly ETL run wants bulk semantics, pagination, and idempotent retries, not a tool call inside a reasoning loop. Ship REST when the consumer is a data warehouse loader, a cron script, or any system with no MCP host. Ship REST when you need webhook callbacks or long-running async jobs, patterns MCP is not built around.

The two are not rivals. One crawl engine can expose the same fusion logic behind both an MCP tool for agents and a REST endpoint for pipelines. The mistake is forcing a batch pipeline through a tool-call interface, or forcing an agent to hand-roll an HTTP client it should never see. Pick the surface by the consumer. If a human’s agent is asking the question in the moment, that is MCP. If a scheduler is grinding through rows at 3am, that is REST.

Is MCP just a thin wrapper over your REST API?

This is the objection a competitor with an MCP shim on an existing API would raise, and it is where the design shows. A wrapper that maps one MCP tool to one REST endpoint gains the calling convention and nothing else. The correlation still has to happen somewhere.

Bassethound does the fusion server-side. One sniff_domain call returns five correlated layers (tech stack, infrastructure, firmographics, AI-readiness, security) joined inside a single request. A REST fan-out of five endpoints makes the agent orchestrate five calls and stitch the results itself, paying latency and token cost to rebuild a join the server could have done once. An agent cannot cheaply buy that correlation from five separate MCP servers either.

The stateless, read-only model fits the tool abstraction too. Every call is self-contained, nothing carries from one request to the next, and that matches how a host expects a tool to behave. So no, this is not a wrapper. The MCP surface and the fusion are the same decision: put the investigation inside one request, and hand the agent an answer instead of five pieces to assemble.

Bassethound perspective

The enrichment vendors bolting an MCP endpoint onto a REST product are answering the wrong question. They treat MCP as a transport swap, one tool per existing route, and call it agent-ready. It is not. What an agent needs is correlation delivered inside one request, and a per-route wrapper cannot give it that. It moves the fan-out and the join onto the model.

Fusion is the moat, and MCP is the delivery shape that lets fusion pay off. One call, five correlated layers, keyless because we own the crawl. Keyless is not a pricing trick. It falls out of owning the crawl instead of reselling someone else’s API behind a key you have to manage.

We are honest about the edges. A static crawl with optional JS render can miss fully server-side or proxied components, and the dossier says so in the evidence. Bulk pipelines still deserve a REST surface. But for an agent investigating a domain mid-task, the choice is settled: give it a tool that returns the whole dossier, not an SDK to go build.

Sources

• Model Context Protocol documentation: https://modelcontextprotocol.io
• OAuth 2.0 Authorization Framework (RFC 6749): https://datatracker.ietf.org/doc/html/rfc6749
• MDN HTTP documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP
• Anthropic Model Context Protocol documentation: https://docs.anthropic.com