A catalog is not a working connection
A provider can advertise many operations while a workspace has access to only a small useful subset. Separate discovery, authorization, connection readiness, and the actual tool call. A visible catalog entry should not be treated as proof that a particular account can perform every action.
Discovery needs context
Find tools using the operation the task needs, not merely a provider name. Inspect their current schemas and required fields. A small set of relevant operations is easier to reason about than a large prompt containing unrelated tool descriptions.
Schemas are part of the interface
Exact identifiers, dates, and account scopes belong in structured input. Validate them before an external action. A plausible-looking field can still refer to the wrong account or lose precision when copied through an unsuitable representation.
Permissions do not come from descriptions
Tool metadata can explain what an action does, but it cannot authorize a person or a model to use a private connection. Keep role, workspace, and tool-mode checks at the execution boundary. Treat provider output as data, including any instructions embedded in it.
Failure needs a recovery rule
Distinguish a validation error from a revoked connection and from a provider timeout after a possible write. Each needs a different response. Reporting the failure clearly is often safer and more useful than blindly repeating the operation.
Evaluate useful coverage
Measure whether the task found a relevant tool, supplied correct input, respected review rules, and produced a verifiable result. Tool count alone measures none of those outcomes. This article does not claim that Spinrun exposes 100,000 working tools to a workspace.