Call other services

Your tool or agent needs to call another service: GitHub, Google, Snowflake, a vendor API, an internal backend. Before you pick a guide, answer one question: whose access should the call use?

• The signed-in user’s. A person asked for this, and the result should be what they are allowed to see. The audit log records the user, the agent that acted for them, and the Resource.
• Your Application’s own. No person is in the loop, or the work belongs to the service rather than to any one user. The Application authenticates as itself, and the audit log names it.

Either way your code never holds a long-lived key for the other service. Keycard exchanges the identity you have for a short-lived credential scoped to one Resource, checks it against your Access Policies, and records the exchange.

You want to…	Call as	Start here
Let an MCP tool call GitHub, Google, or any OAuth API with the permissions of the person using it	the user	Act on behalf of users
Write those tools with the Keycard MCP SDK today, following the grant pattern	the user	Call External APIs from MCP
Give an MCP tool the user’s GitHub or Google Workspace access, step by step	the user	GitHub · Google Workspace
Run a scheduled job or queue worker as a specific user who isn’t signed in	the user, absent	Act on Behalf of Absent Users
Give an autonomous agent its own identity and scoped access to an API	your Application	Give an agent its own access
Deploy either kind of server without a static secret, using the host’s workload identity	either	Fly.io · Render

Use this when a person is behind the request and the other service already knows who they are. Your tool receives the user’s Keycard token, exchanges it for a token the other service accepts, and makes the call with that person’s permissions. Revoke the user’s grant and the calls stop.

• Act on behalf of users covers both cases, the user present and the user away, and points to the walkthrough for each.
• Call External APIs from MCP is the SDK walkthrough for MCP tools: register the upstream API, create an Application, and wrap each tool in a grant. GitHub and Google Workspace have step-by-step versions.
• Act on Behalf of Absent Users is for background work: the user consents once, and the agent mints a short-lived token for that user on every run.

Use this when the work is the service’s own: an agent that takes jobs from other agents, a nightly report, a backend that calls a vendor API under a contract that belongs to your team. The Application proves who it is to Keycard and gets a credential in its own name, so the audit log shows the Application, not a borrowed user.

• Give an agent its own access builds a standalone agent that authenticates with its own key pair, gets short-lived tokens for an API, and serves other agents over A2A.
• Autonomous Agent Access does the same for agents that call MCP servers through a Unified Access Gateway.

Workload identity replaces the server’s client secret; it doesn’t change whose access the call uses. Run on Fly.io without secrets and Run on Render without secrets deploy a user-delegated server that proves its own identity with the host’s OIDC token, so nothing is stored or rotated. The same hosts work for a server that calls as your Application.

Ask what should happen when you revoke a person’s access. If the calls that person triggered should stop, call as the user. If the service should keep running regardless of who joins or leaves, call as your Application. For how the two flows differ at the token level, see Credentials.