Skip to main content
Glama

elaichi__access_request__create

File a request asking an org admin to grant access to a tool that just refused you — the operation behind a "blocked" result’s can_request_access flag. Only ever call this right after a tool call came back refused for permission or restriction (never for scope — that refusal is between you and your own client and no admin can fix it, so it never carries can_request_access). Pass the exact tool name and reason the refusal named, and the exact permission string too when reason is "permission" — never invent or guess a permission, and never pass one at all when reason is "restriction" (the request record must not become a way to learn which rule blocked you, so a restriction-reason call that names a permission is rejected). Filing twice for the same thing while the first request is still open does not create a second one — it returns the existing request (its own status tells you whether that was a fresh file or a repeat), so it is safe to call again if you are unsure whether one already exists. This only creates a RECORD for a human to review; it does not itself grant anything, and nothing about a tool becomes usable because you filed a request. Returns the request with can_withdraw.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoOptional short context for the admin reviewing this, in the requester’s own words.
toolYesThe exact tool name the refused call used, taken verbatim from the refusal — or, when resource_type is "connector", the connector slug. Never a name you composed yourself.
reasonYesThe refusal’s own reason, verbatim — "permission" or "restriction". Never "scope"; a scope refusal has no admin-side fix, so it never offers this operation in the first place.
permissionNoRequired, and must be a real permission name, when reason is "permission" — the exact string the refusal named. Omit entirely when reason is "restriction"; sending one there is rejected.
resource_typeNoWhat is being asked for. Omit (or "tool") for the ordinary case: a tool call came back refused. Pass "connector" ONLY when the person is asking for a whole connected app they cannot reach at all — then `tool` carries the connector slug instead of a tool name. Never guess between the two: use whichever the refusal itself was about.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations: it discloses the idempotent-like behavior when a request is already open, states that no access is actually granted, explains that passing a permission on a restriction-reason call is rejected, and names a field on the return (`can_withdraw`). This is rich behavioral context for a mutation-like operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but every sentence carries operational weight: triggering condition, exclusion of scope, parameter constraints, retry behavior, and result semantics. It is front-loaded with the core purpose and contains no filler or repetition beyond what is useful for safe invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the absence of an output schema, the description is remarkably complete. It covers when to call, when not to call, how to populate every parameter, edge cases around repeated requests, and what the response signifies. An agent has enough context to invoke it correctly without external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3. The description adds value by emphasizing that tool/permission values must be taken verbatim from the refusal, that invented permissions are forbidden, that omitting permission on restriction calls is mandatory, and that resource_type='connector' has a special meaning. It mostly reinforces the schema's own wording, but the added rationale earns a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'File a request asking an org admin to grant access to a tool that just refused you.' It ties the operation to a concrete, recognizable condition (a refused result's can_request_access flag), which clearly distinguishes it from the access_request get/list/resolve/withdraw siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is explicitly gated: 'Only ever call this right after a tool call came back refused for permission or restriction (never for scope...).' It also explains when retrying is safe, when permission must be omitted, and that the operation only creates a review record rather than granting access. This removes almost all ambiguity about when the tool should be selected.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources