EVIDUCT / INDEPENDENT MCP SERVICE LAYER

Let the agent choose a service. Not the seller's pitch.

Your AI agent needs an external MCP tool. Providers can write convincing descriptions, fake ratings and even instructions aimed at the model. Eviduct separates those claims from what is technically approved and observable.

Start with existing public read-only tools. Selection is not a made-up five-star rank; when evidence is insufficient, Eviduct says so. Paid settlement is not live.

Actual discovery / 01

Browse services that exist. Not bought rankings.

These are real public MCP Registry entries, retrieved live and shown without advertisements, review scores or paid placement. Their names and endpoint addresses are publisher-submitted hints, not proof that the service actually performs the task or is safe.

Searching the official registry…
This is live discovery, not an evidence-based recommendation. The marketplace never treats a provider's own metadata as verified performance. A tenant owner must inspect and explicitly approve the exact MCP operation before an agent can use it.
Why Eviduct exists / 01

A good description is not evidence that a tool is good.

An MCP provider controls its name, descriptions, annotations and often its own reviews. Those fields may persuade the agent to pick a provider or follow instructions that were never approved by the agent owner.

WITHOUT AN INDEPENDENT BOUNDARY

“Pick me. Five stars.”

A service claims to be mandatory and sends hostile instructions in its MCP description. A naive rating-based choice can also be flooded by fake agents.

Untrusted seller-controlled metadata
WITH EVIDUCT POLICY

Choose only from approved contracts and observed facts.

The agent sees a neutral, owner-approved tool. Fake reviews do not enter the decision. If the evidence does not justify a winner, the algorithm abstains.

Checking policy proof…

This reproducible example checks code invariants, not LLM attack rates or arbitrary output correctness.

View technical evidence and cases
What actually happens / 02

Discover, authorize, decide, execute.

One MCP connection can find anonymous potential services in the live official registry, present a neutral contract for owner approval, and execute a single authorized public-data read using real gateway evidence. Neither seller marketing nor agent star ratings determine the decision.

Discover

Registry entries are leads, not trust certificates. Candidate names are hidden from the model until the owner chooses to inspect.

Choose fairly

Only owner-declared equivalent services are compared. With too little evidence Eviduct requests permission to explore or declines to guess.

Call once

The selected route is rechecked for active approval, exact arguments and live schema before a single outbound MCP call. Technical outcomes become private evidence.

Opted-in seller offers / 03

See what is actually listed.

Neutral candidate cards generated from approved, seller-opted-in gateway routes. No featured placements, endorsements, text reviews, or fabricated quality scores.

Loading opt-in offers…
No seller listings yet? You can still connect an existing MCP server through the free trial. Technical uptime is not task correctness. Seller-defined prices are fixed in buyer-specific quotes, not evidence of provider quality. No provider is charged or called from this public page.
What we measure / 03

A measurement is not a review.

Eviduct records the outcome of a controlled MCP call, not what the agent thought of the provider. Shared aggregates require explicit consent and sufficient independent participants; they are not used as a vendor reputation score.

Provider-star votes used0Spam cannot buy rank
Customer results stored0No invoices, generated images or output bodies in technical evidence
Minimum sharing cohort5Opt-in tenant groups, suppress smaller samples
Global quality ratingNoneNo fake claims about semantic results

Private evidence

Successful MCP response, denied policy decision and technical failure are separate facts. They are not accepted as a five-star endorsement.

Independent outcome checks

For some tasks an external oracle can confirm correctness; no universal oracle exists for arbitrary agent work. Unverified outcomes remain unverified.

Real financial control

A paid quote needs a connected seller, hosted buyer authorization and verified processor capture. Without valid payment credentials the purchase is rejected, not simulated as settled.

Independent verification / 04

An external witness. Not an agent's opinion.

When a trusted verifier has checked an external postcondition, it can sign a one-time receipt bound to a buyer's order, approved input contract and execution nonce. An agent's praise, review spam or supplier text cannot produce the signature.

Witness

A separately operated verifier observes the result in an authoritative system, such as an accounting platform confirming that an invoice really exists.

Proof

The verifier signs a structured PASS or FAIL outcome with Ed25519. Only pinned verifier keys are accepted. No invoice contents are recorded.

Conservative release

Signed reports appear publicly only above minimum buyer and observation thresholds. An unconfigured verifier or absent proof is not a passing score.

Checking independent verifier availability…
No signed aggregate available.
Scope today / 05

No invented guarantees.

Today's executable gateway supports approved public-data reads with limited primitive inputs. Arbitrary invoice creation, private company credentials, universal semantic quality scores and crypto wallet signing are not magically supported. External billing remains disabled without verified merchant and processor configuration.

MCP client integration · Attack proof · Data handling