How scrollport verifies AI agent tools before publication

A provider being available is not the same as a scrollport catalog tool being ready to call. A provider can have a working API while a specific listing is unpublished, missing accepted evidence or temporarily unhealthy. Dependable agent infrastructure keeps those states separate instead of turning a provider directory into a promise of execution.

Availability is not publication

Provider availability is an input to integration work: credentials, endpoints and the provider’s own service have to exist. Publication is a scrollport decision. A catalog tool becomes public only when its listing version, execution contract, price evidence and accepted worked example are ready for human review and publication.

The distinction matters to terminology. The category and capability describe the job; the provider describes provenance; the catalog tool names the runnable operation. A provider page cannot prove that every tool supplied by that provider is published or healthy. Thelive research catalog is the better place to see what is currently public.

Evidence starts with human verification

Before publication, a human reviews a worked example and the price evidence for the listing version. The accepted example is tied to the execution contract and its exact input. That gives the publication a concrete basis: the reviewed operation ran with the schema, provider connection and wiring that the public tool claims to use.

• The worked example shows what was actually tested, not a fictional success transcript.
• The contract fingerprint ties the evidence to the adapter, connection and input schema.
• The price evidence explains the normalized provider event and published unit.
• A later listing may inherit evidence only when the contract and example still match.

This is why an article can explain the evidence model without claiming that its own examples were run. The current tool page is the source for the live contract and published facts, not a paragraph copied into a marketing article.

Health monitoring watches for drift

Publication and health are separate axes. After publication, a weekly canary checks for later drift in the live path. It is useful monitoring, but it does not prove the original human verification again, does not replace the accepted evidence and does not authorize a changed contract to inherit old proof.

A changed adapter, wiring path, input schema or worked example can make evidence stale. That should degrade the tool until a human verifies the new contract. A provider outage, invalid response or failed canary can also make a published tool unhealthy. In each case, the honest public state is more useful than a green-looking directory entry.

Only healthy published tools stay callable

Public discovery is intentionally narrow: only a published, live and unarchived catalog tool appears as discoverable. A failed or degraded tool must not be presented as reliably callable just because its provider still has an account or endpoint. That boundary protects both the agent’s decision and the human’s wallet.

When a tool is healthy, the public surface still shows its provider provenance, connection requirement, billing unit and current price. Those facts are live catalog data and can change through the normal listing process; this article does not duplicate them.

Inspect the current contract

Users can browse the public tools explorer to move from a category to a capability, provider and exact catalog tool. Agents use theinspect control tool after discover to read the selected tool’s current input contract, examples and teaching errors before calling run. Theplatform docs explain that control-tool path and the wallet behavior without creating a second catalog reference.