find-out-what-identity-your-tool-receives

Deploy one tool that reports the caller identity it actually observes, in the host you will really use, before designing an integration around an identity you assumed.

Procedure

  1. start start. Goes next to s1
  2. action Build one tool that reports its caller, RW (reversible-write). Goes on_fail to s9; next to s2
  3. action Register it in the host you will really use, RW (reversible-write). Goes on_fail to s9; next to s3
  4. action Call it as an ordinary user, RO (read-only). Goes on_fail to s9; next to s4
  5. decision What identity actually arrived?. Goes if per_user to s5; if service_only to s6; if differs_by_surface to s7; if default to s9
  6. action Exchange the user token, scoped to them, RO (read-only). Goes on_fail to s9; next to s8
  7. action Decide where consent will live, RO (read-only). Goes on_fail to s9; next to s8
  8. action Pin the scenario to the surface that works, RO (read-only). Goes on_fail to s9; next to s8
  9. check The protocol versions agree. Goes on_fail to s9; next to __end_success
  10. escalate Stop before building on an assumption. Terminal
  11. end success. Terminal

Open the graph on its own page — larger, printable, and an address you can send.

Walk it without running it — you answer what your environment would answer, and the path, the capabilities, the approvals and the distance back to an undo come out of the document. Nothing executes; there is no Run button here and there will not be one.

Trust

T2 · attested 2026-10-11 · runbooks.directory

Nobody has attested this record. That is the ordinary case: T2 is what the catalog can check on its own, and T3 needs somebody to run the procedure and sign for it.

  • Link liveness has not been checked: it needs a network and the catalog builds without one. Run pnpm gates --online where there is one.

Steps

  1. s1 action — Build one tool that reports its caller (reversible-write)
  2. s2 action — Register it in the host you will really use (reversible-write)
  3. s3 action — Call it as an ordinary user (read-only)
  4. s4 decision — What identity actually arrived?
  5. s5 action — Exchange the user token, scoped to them (read-only)
  6. s6 action — Decide where consent will live (read-only)
  7. s7 action — Pin the scenario to the surface that works (read-only)
  8. s8 check — The protocol versions agree
  9. s9 escalate — Stop before building on an assumption

Capabilities

This is a privilege request. Check it against your own allowlist before running.

    Provenance

    Source
    https://github.com/microsoft/ai-agent-runbooks/blob/083f33eec889/02-patterns/MCP-Server-Integration/MCP-Server-Integration-Runbook.md
    Fetched
    2026-09-04
    Source last checked
    not since it was captured on 2026-09-04 — recorded as current
    Licence
    MIT
    How it got here
    Rewritten here from the source above, under its licence. The words and the steps are this catalog's; the procedure it describes is not this catalog's invention, and the source is where to check it.
    Highest risk in this procedure
    reversible-write

    Take it with you

    Run it under supervision

    Runs here, on your machine, under supervision: every step is proposed before it happens, an approval gate stops for you, and a failed expectation goes where the procedure says rather than on to the next step. Nothing is sent anywhere. To supervise an agent that is doing the work instead, runbooks hook sits in its tool-call path.

    npx @runbooks/cli run adapted/find-out-what-identity-your-tool-receives@1.0.0 --as "$(whoami)" \
  --input host=<the surface the integration will actually be used from> \
  --input pilot_account=<an ordinary user account, not a developer or administrator one>