Recipe Reels

check_agent_connection

Poll for the human's decision on a start_agent_connection request.
Call this roughly every `interval` seconds (from the start call's
own response) using the SAME `device_code`.

Returns `{"status": "pending"}` while waiting, `{"status":
"denied"}` or `{"status": "expired"}` if the human declined or the
code timed out, or `{"status": "approved", "session_token": "...",
"user": {...}}` once approved -- stop polling once you see
"approved", the code is now spent and a second poll reports it as
expired. Hold onto `session_token` for the rest of this
conversation and pass it to every tool below that takes one --
treat it as a secret: never display it to the human or repeat it
back verbatim unless they specifically ask to see it. The resulting
access matches whatever tier (User/Subscriber/Admin) the approving
human's account already has -- this flow grants no special agent-
only access, and the human can revoke this connection at any time
from their own Account Security page.

Input Schema

Name	Required	Description	Default
`device_code`	Yes	The `device_code` start_agent_connection returned.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing all four terminal/pending states, the fact that the device code is single-use and a second poll reports 'expired', the scope of the resulting access (mirrors the human's existing tier, no agent-only privilege), revocation via Account Security, and secret-handling rules for session_token.

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?

Front-loaded with the action and polling cadence, then the return states. It is a single dense paragraph with some parenthetical nesting, but nearly every sentence carries actionable information about state transitions or token handling.

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?

No output schema exists, and the description fully specifies the response shapes (pending/denied/expired/approved with session_token and user), the stopping condition, and the post-success token obligations, so an agent can implement the flow correctly.

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 100% and the schema already documents device_code's origin, so the baseline applies; the description reinforces that it must be the SAME code from the start call, which is the one detail an agent could plausibly get wrong.

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: 'Poll for the human's decision on a start_agent_connection request.' It is immediately distinguishable from its sibling start_agent_connection, which initiates rather than polls.

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?

Explicit operational guidance: call roughly every `interval` seconds using the SAME `device_code`, stop once 'approved' is returned, and do not poll again because the code is spent. It also names the source of the interval (the start call's response), leaving nothing to inference.

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

All Recipe Reels tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?