Blender Bridge

Complete pending sign-in

poll_auth_status

Destructive

Check an existing account sign-in flow started by start_auth and report its current state. When the browser confirmation is complete, polling can exchange the flow and save the resulting account credentials; it is not merely a read-only status lookup. Does not start another browser sign-in. Desktop-managed connections instead report the current receiving Desktop account's readiness and do not exchange a separate MCP flow. Use for pending sign-in completion, get_connection for account/computer state, or get_setup_status for runtime readiness.

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": "poll_auth_status"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior4/5

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

It supplies the missing 'why' behind the destructiveHint=true and readOnlyHint=false annotations: polling can exchange the flow and save credentials, so it is 'not merely a read-only status lookup'. That is genuine added value. It stops short of saying what happens to pre-existing credentials or session state when the save occurs, and says nothing about polling cadence or terminal states.

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 its non-read-only nature are front-loaded in the first two sentences, and the alternatives come last. The third sentence about desktop-managed connections is jargon-dense ('the current receiving Desktop account's readiness') and slightly tangled, costing it a point.

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?

With no output schema and no parameters, the description carries the full burden, and it does cover both the MCP-flow and desktop-managed branches plus the sibling routing. The remaining gap is what 'current state' actually returns — enumerable states such as pending, complete, or failed — which an agent polling this tool would benefit from.

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 tool takes zero parameters, so the baseline of 4 applies. The description correctly adds that behavior varies by connection type (desktop-managed versus MCP flow) without inventing parameter-like inputs.

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 — check an existing sign-in flow started by start_auth and report its state — and explicitly clarifies the non-obvious nuance that completing the exchange and saving credentials can occur. It distinguishes itself from start_auth, get_connection, and get_setup_status by name, so an agent can pick it without opening a 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 routing: use this for pending sign-in completion, get_connection for account/computer state, get_setup_status for runtime readiness, and start_auth to begin a flow. It also includes a negative rule — 'Does not start another browser sign-in' — covering the most likely misuse.

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

All Blender Bridge 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?