How to build an MCP tool access review

What matters here

• Review tools and callers together. A tool nobody can call is clutter. A caller who never uses a tool is open access for no reason.
• Put real usage on every line. An owner who sees no calls in 90 days can remove access in one click instead of guessing.
• Send each owner only their own servers. A company-wide spreadsheet gets approved without being read.
• Remove anything not confirmed by the date. A review where silence means keep is a review that changes nothing.
• Review AI assistants as well as people. An assistant added for a trial last year can still be calling tools today.

Who this is for

You run IT, security or AI operations. MCP servers are on a managed path with owners and access groups, and now someone has to check, regularly, that the access still makes sense.

How it works in practice

What happens each review cycle, from the list being built to the access that nobody needs being gone.

1. 1

   Every tool and every caller is listed

   Each managed MCP tool with the groups, people and AI assistants that can call it, taken from the platform, not from memory.

2. 2

   Usage is attached to each line

   Calls in the last 90 days per person and per assistant, from the audit records, with the date of the last call.

3. 3

   Each owner gets their own servers

   One message per owner, with the lines worth a decision at the top: no calls, ex-team members, assistants nobody uses.

4. 4

   The owner keeps or removes each line

   Keep, remove, or change to read only, with a reason for anything kept that shows no use.

5. 5

   Anything not decided is removed on the date

   After one reminder. The owner can put it back through a normal access request if it turns out to be needed.

6. 6

   The result is recorded

   What was reviewed, by whom, what was removed and when, so the next audit asks for a report instead of a meeting.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up and list every tool and caller

   The review is only as good as the list it starts from.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Okta, Snowflake, Slack and
   ServiceNow, or whatever we run in those seats. Before you plan
   anything, tell me which of them are already authenticated in the
   workspace, because I do not want a connector stubbed that I have not
   authenticated.
   
   Each quarter, build a list of every managed MCP tool with: its server,
   the server's owner, every group and person that can call it, and every
   AI assistant allowed to connect, such as Claude or Microsoft Copilot.
   
   Build it from the platform and the identity provider each time. Never
   start from last quarter's list, because the point is to catch what
   changed without anyone writing it down.

2. 2

   Attach real usage

   Owners approve everything when they cannot see what is used.

   Headless skills tray-patterns

   Copy

   For every line, add from the audit records in Snowflake: calls in the
   last 90 days, the date of the last call, and which assistants made
   them.
   
   Flag the lines worth a decision: people with no calls, people who have
   left the team the access was granted for, assistants with no calls,
   tools with no calls at all, and tools that change records where every
   caller only ever reads.
   
   Sort each owner's list so flagged lines come first. An owner will read
   the first ten lines carefully and skim the rest.

3. 3

   Send each owner their own servers

   A company-wide spreadsheet gets approved without being read.

   Headless skills build-workflow

   Copy

   Use build-workflow. Send each server owner one Slack message with their
   servers only, the flagged lines at the top, and buttons to keep,
   remove, or change to read only, line by line or for all flagged lines
   at once.
   
   Ask for a short reason for anything kept that shows no use in 90 days.
   Give a deadline two weeks out, and remind once, three working days
   before it.
   
   If a server has no owner, send it to the head of the team that uses it
   most and open a ServiceNow ticket to assign one. A server with no owner
   is a finding in its own right.

4. 4

   Remove what nobody confirmed

   A review where silence means keep changes nothing.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas. On the deadline, apply every decision: remove people
   from the access group or the server, remove assistants from the
   allowed list, and change tools to read only where that was chosen.
   
   Remove every line the owner did not answer, after the reminder. Tell
   each person what they lost and how to ask for it back through the
   normal access request.
   
   Hand any tool that now has no callers to the retirement process, so it
   is switched off and its credentials removed instead of sitting idle.

5. 5

   Record the result and report it

   The next audit should ask for a report, not a meeting.

   Copy

   Write the outcome to Snowflake: every line reviewed, the decision, who
   made it, when, and what was removed.
   
   Report each cycle: lines reviewed, lines removed, owners who did not
   answer, servers with no owner, and how many removed people asked for
   access back. A high number asking back means the usage data was wrong.
   A number near zero means the review is working.

6. 6

   Check it end to end, then hand the cycle to security

   Because the schedule and the thresholds are a policy decision.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Run one cycle on a test server, leave one line
   unanswered, and confirm it is removed on the date and the person is
   told.
   
   Then open the same workflow in Tray Build so security can change the
   review schedule, the 90-day threshold and the deadline in the visual
   canvas. Reviews of access to company apps in general belong to a
   separate user access review. Keep this one to MCP tools, servers and
   assistants, and point to that review for everything else.

What it connects to

The list comes from the platform and the identity provider, usage comes from the audit records, and decisions happen where owners already work.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Further reading

Background on the same subject, for the case rather than the build.

• Flying blind: Why MCP needs its API management moment
• Shadow MCP is the new shadow IT

Related guides