Governance · · 7 min read
Configured, available, used: three different facts
A practical way to read MCP and skill status without confusing a catalog entry with working execution.
A tool can appear in a catalog and still be unusable on the computer selected for a Task. It may be requested, approved, installed with a different configuration, missing a credential, or simply not initialized. A trustworthy control screen names these states separately.
GrantTap tracks capability identities, observed host state, and Mesh decisions. It does not yet transfer complete MCP or skill bundles to every host. A requested or approved entry therefore cannot by itself establish readiness on a target computer.
Follow the capability through its lifecycle
The full lifecycle starts with discovery: a host reports a native MCP configuration or skill bundle. A request brings an exact version or digest into review. Approval covers that identity under policy. Each target host would then need to apply it and report initialized state; complete cross-host bundle delivery is still work in progress. Only invocation evidence can show that a Task actually used it.
The same human-friendly MCP name can hide two different server configurations. For a skill, scripts and references matter as much as SKILL.md. An edit to the bundle changes the digest and requires a new readiness decision rather than inheriting an old approval by name.
Policy and environment are separate
Governance answers whether a capability may be used. Environment controls which approved process receives a value or reference. A masked field in Settings prevents casual viewing; it does not stop an agent with shell access to the same process from reading its environment. Use-only credentials require a trusted broker that performs a narrow operation without exposing the key to the model.
Likewise, observing token use is not a spending cap. A strict budget needs an atomic reservation before a controlled external action, accounting for work already in flight and unknown outcomes. These budget and use-only flows are still being built and should not be treated as active protection.
What to check today
Check the exact capability identity, the target computer, its observed configured and initialized states, the chat's allow/ask/deny decision, and the result of a small real invocation. If any state is unknown, keep it unknown. A green catalog card must not stand in for successful use.
For a local MCP connection, also verify the machine helper, transport, provider plugin, and app hooks independently. A relay connection does not prove that an stdio server launched in Cursor or that a Codex session loaded newly trusted hooks.
The name is not the capability
Two MCP servers can advertise the same friendly name while using different endpoints, commands, permissions, or environment. Two skills can share a title while their scripts and references differ. Approval by display name would therefore be ambiguous. The identity that matters includes the concrete configuration or bundle digest. A person should be able to inspect that identity before allowing it for a Task, and a changed identity needs its own decision.
This is why a catalog is only the beginning. Discovery says a host reported something. A request says someone wants it. Approval records a policy decision about a specific identity. Installation and initialization describe what a target host actually did. Invocation is yet another event. Compressing these steps into a single green badge makes a system look simpler while making it harder to trust.
Follow the selected computer
A Task runs on a particular computer through a particular provider execution. It is not enough for an MCP server to work somewhere in the Project. The target computer may have a different operating system, a missing executable, a disabled provider integration, or an absent credential. The UI should name the host whose state it is reporting. If the target changes, the readiness question must be asked again for the new environment.
A host receipt should say what configuration it accepted and what it could initialize. An unavailable host cannot honestly report success. A receipt also has a time and scope: it is not proof that a tool remains usable forever. If the process restarts or its configuration changes, new observation may be needed. This is operational evidence, not a promise that every route is currently covered by durable apply receipts.
Policy is not an invocation log
An allow decision permits an action within its specified scope. It does not show that an agent called the tool. An ask decision means the person may need to decide later; it does not mean the request was answered. A deny decision is meaningful only where the computer enforces it on the relevant path. An action outside the observed provider or host path cannot be counted as blocked merely because a policy row exists.
Usage requires evidence of an actual invocation: which Task, capability identity, computer, execution, time, and observed result. A missing event is unknown when the observation path is incomplete. It should not be plotted as zero use. For the same reason, an accepted approval cannot be used as a usage metric. Keeping policy and observation separate makes both useful: one describes what may happen, the other describes what was seen.
Credentials are an additional boundary
A masked field helps prevent casual viewing in a settings screen, but masking does not make a secret unavailable to a process that receives it. If a coding agent can run shell commands in that process, it may be able to read environment variables. A true use-only secret needs a trusted broker that performs a narrow operation while withholding the raw value from the model and its tools. That capability must be evaluated on its actual execution path.
A spending limit is similarly stronger than a chart of tokens already spent. To prevent an action from exceeding a budget, a controlled route needs an atomic reservation before the external call and a way to reconcile delayed or unknown outcomes. GrantTap does not present observation as a strict cap. The current article distinguishes these future controls from available status, so a reader does not mistake an attractive governance screen for complete financial or credential enforcement.
A useful review before enabling a tool
Begin with the exact MCP configuration or skill bundle, not its short label. Read what process it starts, what files or network destinations it can reach, and which Task and computer need it. Choose the narrowest sensible policy. Then inspect the host's observed configured and initialized states. If the capability was edited or moved to another host, repeat the identity and readiness check. This workflow is less convenient than approving a name forever, but it preserves the meaning of approval.
After approval, make one harmless real call where supported and inspect its result. That call tests a different layer from installation. If it fails, the status should identify whether policy, initialization, transport, provider integration, or execution blocked it. The generated lifecycle image above shows an intentional gap before the final state; the product screenshot below uses demo values. Neither image is proof that a capability on your own computer was used.
How to read an honest status
Treat ‘requested’, ‘approved’, ‘configured’, ‘initialized’, and ‘used’ as separate observations with dates and source hosts. If the interface knows only one of them, it should say only that one. ‘Unknown’ can be the most accurate status when the target is offline or an integration cannot report native state. It invites a specific next check instead of hiding a gap behind a confident color.
The benefit is practical. A person can decide whether to wait, repair a host setup, revoke a changed bundle, or continue a Task with another supported route. An engineer can locate the failed boundary without treating every error as a pairing problem. Governance is strongest when its screen leads to a verified computer action and leaves uncertainty visible. The moment a catalog entry is mistaken for working execution, both security and usability suffer.
