Skip to main content
mcp tools

Introspect

tools
4
write tier
read-only (tier 0)

What are the Introspect tools for?

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.

Tools

Introspect MCP tools.
Tool Access Purpose
check_eligibilityreadAsk whether a write would be accepted, WITHOUT performing it
get_my_permissionsreadGet YOUR OWN effective RBAC permissions in this org — call this BEFORE attempting an action, instead of discovering a 403 by trying
get_organisationreadGet organisation settings and metadata
list_organisationsreadList organisations the authenticated user has access to

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.

faq · mcp

Introspect tools: 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.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·