unbrowseA connector logo is an ambitious way to describe a function call.
It can mean “searches this service.” It can mean “reads your profile.” It can mean “handles the operation your business depends on.” Those promises look remarkably similar on an integrations page.
They look different when the customer tries to do the work.
A standard tool interface does not supply operations the integration never implemented. If your coverage strategy consists of wrapping whatever an official API happens to expose, the wrapper inherits the boundary.
Implementing a missing operation increases coverage. Exposing an existing operation to another client increases accessibility. Both can be valuable. Your product should know which improvement it bought.
Test the verb after the logo
Imagine a supplier portal. Its official integration can search products and retrieve orders. Your customer needs to download a compliance document attached to a particular shipment. The website provides that document; the integration does not.
An MCP server can describe the available search and order tools beautifully. The agent can select the right tool, supply valid arguments and receive a successful response. The document still has not arrived.
The missing operation is beneath the interface. Standardizing how the agent calls a tool cannot add a tool nobody built.
“Supports the supplier portal” was therefore too broad a promise. “Retrieves orders” would have told the customer something useful. The engineering decision follows from that narrower description: either obtain the missing operation, use another supported path, or acknowledge that the job is incomplete.
The logo grid conceals that decision until the worst possible moment.
MCP is doing a real job
A fair defense of MCP starts with the work it can remove. A common interface can make tools easier to discover and call across clients. A carefully built server can package awkward service behavior into an operation an agent can use. That server might do much more than wrap a REST endpoint.
The MCP authorization specification defines an optional authorization framework for HTTP transports; MCP does not impose the same OAuth setup on every integration.
These are useful contributions. Replacing them with a collection of improvised clients can create more work, not less.
The mistake is assigning the protocol responsibility for a different problem: obtaining task coverage. Good tool transport and good coverage can reinforce each other. They still need separate evidence.
Find the missing operation
The website can offer another place to investigate. Many applications call their own servers to perform operations that are absent from a public integration. An authorized browser session can reveal a request and the result it produced.
Turning that observation into a tool requires work. The request may contain a temporary value. Its output may depend on the account. A parameter that appears optional may become necessary for another input.
For this task, verification means the document belongs to the requested shipment. An unavailable document and expired access must produce different outcomes; calling both “no result” leaves the customer to diagnose the failure.
Unbrowse investigates supported website operations and exposes verified capabilities through interfaces including MCP. Discovery does the work of finding something callable; MCP gives the agent a common way to call it. The Agentic Web Will Not Wait develops the broader case for looking beyond the existing integration.
The protocol remains useful on either side of that discovery. A team might start with an official API, add a learned read-only operation for a missing document, and expose both through the same server. The customer should not have to care which route supplied the file. The builder must care, because the two routes can have different access requirements and different maintenance owners.
Put maintenance in the comparison
The strongest reason to prefer an official integration is what happens after the first successful call. A documented API can provide a compatibility contract that an internal website request does not. The website may update both ends of its private interface without preserving the version your client learned.
That is a real cost of learned routes. Calling the request “first-party” does not make it permanent.
A useful comparison includes who detects a changed result, who repairs the route and what the customer must do while it is broken. Direct execution can be a poor choice if every change returns an investigation to the user. Equally, a stable integration that cannot retrieve the needed document still cannot finish the job.
Choose based on the actual operation and its operating burden. Protocol allegiance is an expensive substitute for that judgment.
Count completed jobs
Before adding another logo, give the integration a small scorecard: the required operation, the output you will accept, the access it needs, what it cannot do and the person responsible for repair. Test that contract through the interface your customer will use.
A gap written down is useful engineering information. A gap hidden behind “connected” becomes a support ticket after the customer has built a workflow around it. Honest coverage descriptions help builders compose the pieces that work and see where another route is still needed.
Unbrowse owes you the same proof. The documentation is a starting point for testing a capability; it is not a claim that every operation on every site is available.
A healthy tool response is evidence about a call. The correct shipment document is evidence about the customer's job.
Put the latter on the scorecard.