Expected outcome
You can distinguish a publicly inspectable tool name from the separate client grant, workspace context, and effect policy required to use it
You can use this public guide without a Tempera account, product credential, or private workspace. Product access begins only after private onboarding.
Before you start
- One agent-client task that needs a tool rather than broad system access
- A named workspace owner who can review the requested grant
Steps
- 01
Read the catalogue before the client connects
Start with the tool’s declared purpose and schema boundary. A visible catalogue entry does not create a client session or authorize an invocation
- 02
Match the tool to one job
Choose the smallest capability that serves the task instead of granting a model a broad proxy to unrelated systems
- 03
Check the grant boundary
A private grant is scoped to the intended organization, project, environment, audience, expiration, and permitted action
- 04
Keep an effect behind its own policy
A tool that could change state remains subject to the confirmation and product policy that own that effect
What success looks like
- The team can explain why one capability belongs in the client’s approved job
- The public page has not established an MCP session or invoked a tool
- A future private grant can be reviewed in terms of scope, workspace, and effect rather than a generic integration label
If something is blocked
- If a tool needs several unrelated permissions, split the client task or keep the access ungranted
- If the tool’s effect cannot be explained, do not use a generic MCP grant as a shortcut around the owning product policy