# Introspect

> Four read-only MCP tools that answer questions about the connection itself: which organisation is in scope, what the current user may do, and whether a specific action would be permitted. `check_eligibility` is a dry run that authorises an action without performing it.

Source: https://zop.dev/integrations/mcp-server/tools/introspect
Updated: 2026-08-20

---

## Common questions

### Can an assistant check whether an action is allowed before trying it?

Yes, with check_eligibility. It authorises the action and returns the verdict without performing it, so the assistant asks "I can stop that instance, shall I?" instead of failing halfway on a permission it never checked.

### Does revoking someone's access invalidate their token?

Its reach shrinks immediately. A personal access token carries the minting user's role, resolved live on every call rather than frozen at issue time, so there is no window where an old token keeps permissions its owner has lost.

### Why does the assistant say we have no budgets when we do?

A token is scoped to one organisation, so the honest reading may be "this token cannot see the org that has them". get_organisation and list_organisations exist so an assistant can name the org it is reporting on.

## Why a whole category for four tools

Because an assistant that does not know its own limits produces the worst failure mode
available: confidently attempting something, failing halfway, and leaving a human to work out
what did and did not happen.

- `get_my_permissions`: what the current token's user can actually do
- `check_eligibility`: a **dry run**: would this specific action be allowed, right now?
- `get_organisation` and `list_organisations`: which org is in scope

## check_eligibility is the important one

It authorises an action and returns the verdict **without performing it**. An assistant should
call it before proposing anything mutating, so the answer is "I can stop that instance, shall
I?" rather than an attempt that fails on a permission it never checked.

This is also what makes an assistant honest about tier limits. If your org has MCP at
read-only, `check_eligibility` says so up front instead of the assistant discovering it by
being refused.

## Permissions are re-resolved per call

A personal access token carries the minting user's role, resolved live on every call rather than
frozen at issue time. If someone's access is revoked, their token's reach shrinks immediately. There is no window where an old token retains permissions its owner has lost.

## Scope, not just permission

`get_organisation` and `list_organisations` answer a question that trips up multi-org setups: a
token is scoped to one organisation, so "we have no budgets" may mean "this token cannot see
the org that has them". An assistant that names the org it is reporting on avoids that entire
class of confusion.