Skip to main content
Glama

elaichi__access_request__list

Read-onlyIdempotent

Access requests members have filed — the ADMIN QUEUE by default, or the CALLER’S OWN requests with mine: true. The default needs member:manage (the same permission that gates inviting people and changing roles, because acting on a request always ends in one of those) and is refused without it; mine: true needs nothing beyond org membership, the same nothing that filing a request needed, and is how the person who filed one finds it again. Use mine: true whenever the question is about the user’s own asks ("did my request go through", "what have I asked for") — the default answers a different question and will refuse most people. status defaults to "pending" (the open queue) when omitted; pass "all" to see the full history including withdrawn ones. q matches the requested TOOL name or the requester’s own note (not the requester’s name — resolve that from the requester field on each row instead, and not tool_label, which is resolved outside the searchable store). Admin-queue rows carry requester and, once resolved, resolved_by — both { id, name, email } — plus can_resolve, which is false on the caller’s OWN row: nobody decides their own request, so offer access_request.withdraw there instead of a decision — that row’s can_withdraw is true, because a queue row carries both capabilities. mine: true rows are the requester’s own narrower shape instead — can_withdraw, and a bare resolved_by_user_id rather than a resolved name, because resolving an id into a name and email is a member-directory lookup this view does not hand a plain member for free. Returns { result: [...], nextCursor, prevCursor } — camelCase here, unlike the REST API’s next_cursor. Page by sending nextCursor back as cursor until it is null. Sensitive read: returns records an operator treats as confidential (audit history, credential metadata, offboarding detail). Read-only, but not harmless — do not echo the contents further than needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoCase-insensitive substring of the requested tool name or the requester’s note, matched before paging.
mineNoTrue to list only the requests THIS user filed, which needs no permission. Scoped to the signed-in user server-side — there is no field here that could name somebody else, and asking for another person’s requests is not something this operation can do. Omit (or false) for the org-wide admin queue, which needs member:manage.
limitNoRows per page, 1–200 (default 50). Larger values are clamped, not rejected.
cursorNoOpaque cursor taken verbatim from a previous call’s `nextCursor`. Omit for the first page.
statusNoDefaults to "pending". Pass "all" for the full history.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Despite annotations indicating readOnlyHint, idempotentHint, and non-destructive nature, the description goes far beyond these basics. It discloses the sensitive nature of the data, the security implications of the read, and the nuanced behavior of can_resolve and can_withdraw fields. It also explains the rationale behind 'nobody decides their own request' and the difference in data shapes between admin and mine views. This is exemplary behavioral transparency that significantly aids correct usage.

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

Conciseness3/5

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

The description is long and dense, packing a lot of information into a single paragraph. While every sentence adds value, the structure could be improved with headings or bullet points to improve scannability. The first sentence does front-load the core purpose, but the description is not concise in the sense of quick readability. It is information-dense but not easily digestible.

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 (two modes, permission requirements, pagination, field semantics, sensitivity), the description covers everything an agent needs to call it correctly: defaults, when to switch to mine:true, pagination handling, status filtering, and caveats like camelCase and field resolution. There is no output schema, so the description adequately explains the return format. The description is complete for even a complex tool.

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?

The schema already has 100% coverage with detailed descriptions for each parameter. The description adds extra context on top, such as the semantics of q (matching tool name or note, but not requester name or tool_label) and the default behavior of status. However, the schema descriptions are already comprehensive, so the description is a complement rather than a necessity. Still, it provides additional nuance that improves the agent's understanding, so a 4 is appropriate.

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 clearly states the tool lists access requests, with a clear distinction between the admin queue (default) and the caller's own requests (mine: true). It also explicitly names the alternative tool for the user's own requests, differentiating it from other list tools. The verb 'list' and the resource 'access requests' are specific, and the description distinguishes it from sibling tools like access_request__get and access_request__resolve.

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?

The description gives explicit guidance on when to use mine: true versus the default admin queue, including concrete examples of the questions each answers. It also mentions the permission requirements (member:manage vs. none), and what status values to use. This is excellent routing guidance that goes beyond generic usage.

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