Verified API tools for AI agents: how Scrollport checks them

A verified API tool for an AI agent needs more than an available provider. A provider can have a working API while a specific Scrollport listing is unpublished, missing accepted evidence or temporarily unhealthy. Dependable agent infrastructure keeps those states separate instead of turning provider membership 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 attributable review and publication.

The distinction matters to terminology. The category and capability describe the job; the literal tool identity names the upstream model, product, actor or operation; the provider names its recognised public owner. An execution supplier’s availability cannot prove that every supplied tool is published or healthy. Thelive web research and extraction catalog is the better place to see what is currently public.

Evidence starts with attributable review

Before publication, an authenticated human or Scrollport’s attributable Ops agent reviews a real run, its worked example and the price evidence for the listing version. The Ops agent may accept clear evidence; ambiguous or borderline evidence is escalated to a human. The accepted run is tied to the execution contract and its exact input, giving the publication a concrete basis in the schema, access state 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.

Publication verification is not a full security assessment. It does not by itself include a penetration test, source-code or dependency audit, threat model, privacy review or a restricted-scope assessment. The MCP server security checklistexplains the additional questions to ask before connecting independently operated servers or granting sensitive authority.

Health monitoring watches for drift

Publication and health are separate axes. After publication, a fortnightly canary checks for later drift in the live path. It is useful monitoring, but it does not prove the original accepted run again, does not replace the publication 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 new post-change run is accepted against 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 shows its literal name, provider, 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 and exact catalog tool. Agents use theinspect_tool control tool after search_tools to read the selected tool’s current input contract, examples and teaching errors before calling run_tool. Theplatform docs explain that control-tool path and the wallet behavior without creating a second catalog reference.