Compose Preview Catalogs

request_access

Ask a human for access to this server. Returns an approveUrl and a userCode: show BOTH to the person you are working with, ask them to open the link and check that the code on the page matches, then call poll_access. When the client supports URL elicitation, call poll_access with urlMode=true instead of pasting the link into chat; clients without it keep this complete text fallback. The link grants nothing by itself — keep the deviceSecret this returns, it is what collects the token. Use this when a call answered 'authorization_required', or when your token stopped working (a server restart drops every grant).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "request_access"
  }
}

Input Schema

Name	Required	Description	Default
`label`	No
`scope`	No
`ttlSeconds`	No
`capabilities`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 30, 2026
- changedOutput schema / (root)
```
Previous value: -nullNew value: +{
+  "type": "object"
+}
```
First observedSep 30, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the returned approveUrl, userCode, and deviceSecret, warns that the link grants nothing by itself and the deviceSecret is what collects the token, and notes that a server restart drops all grants. This is far beyond what the empty annotation set provides.

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

Conciseness4/5

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

The core action and return handling are front-loaded, which is good. It is somewhat long and revisits the 'show the link to the human' idea twice (manual paste vs urlMode), but each clause conveys a distinct operational instruction rather than filler.

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

Completeness4/5

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

For a multi-step OAuth device-flow tool the flow guidance is thorough, and an output schema exists so return values need not be detailed (the description still usefully frames them). The one real gap is the wholly undocumented set of 4 input parameters, which an agent must guess at.

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

Parameters2/5

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

There are 4 parameters (label, scope, ttlSeconds, capabilities) with 0% schema description coverage, and the description mentions none of them. It explains the output flow but leaves the inputs — including the meaning of the preview/live/playground scope enum and the ttl/capabilities semantics — completely undocumented.

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?

States a specific verb and resource ('Ask a human for access to this server') and clearly positions itself relative to its sibling poll_access as the initiating step of a two-call flow. An agent can distinguish it from poll_access and from the many catalog/ui_builder siblings without opening any schema.

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?

Gives explicit triggering conditions: use it 'when a call answered authorization_required', or 'when your token stopped working (a server restart drops every grant)'. It also routes the agent downstream, specifying to call poll_access with urlMode=true when URL elicitation is supported and to use the text fallback otherwise.

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

All Compose Preview Catalogs tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.