Skip to main content
Glama
robertocirillo

mcp-elicitation-proxy

by robertocirillo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Trigger URL Elicitation Tool

trigger-url-elicitation

Trigger URL elicitation to direct users to a browser flow, using either a request that waits for the response or an error signal for client-side resolution.

Instructions

Trigger a URL elicitation so the client can direct the user to a browser flow. Supports two mechanisms: the request path (elicitation/create, default) which awaits the user's response, and the error path (UrlElicitationRequiredError, -32042) which signals the client to handle URL elicitation via the error response. Set errorPath=true to use the error path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL the user should open
messageNoMessage shown to the user before opening the URLPlease open the link to complete this action.
errorPathNoControls which elicitation mechanism is used. When false (default), sends an elicitation/create request (request path). When true, throws a UrlElicitationRequiredError (MCP error code -32042) so the client handles the URL elicitation via the error path rather than waiting for a response. To clear the error, satisfy the prerequisite and retry this call with the same arguments; the retry ignores errorPath and proceeds, so the client does not loop on the same error.
elicitationIdNoOptional explicit elicitation ID. Defaults to a random UUID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, the description discloses crucial behavior: the request path blocks awaiting the user's response, the error path throws a specific MCP error (-32042), and retrying after satisfying the prerequisite clears the error without looping. This is substantive behavioral context that annotations do not capture.

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?

Three tightly written sentences with no filler. The primary purpose appears first, followed by the mechanism details and the actionable 'Set errorPath=true' instruction.

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 tool with no output schema, the description covers the core workflow well: how elicitation is triggered, which path to use, and how errors are resolved. It does not explicitly state the success return value, but the 'awaits the user's response' phrasing conveys the expected interaction sufficiently.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The tool description adds minimal parameter-level meaning beyond the schema; the errorPath behavior is already fully described in the schema's errorPath documentation.

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 states a specific action ('Trigger a URL elicitation') and a clear purpose ('so the client can direct the user to a browser flow'). It also distinguishes this from generic elicitation siblings by naming the concrete mechanisms: 'elicitation/create' and 'UrlElicitationRequiredError'.

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

Usage Guidelines4/5

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

The description clearly explains the two modes, marks one as the default, and explicitly tells the caller to 'Set errorPath=true to use the error path'. It does not explicitly compare against sibling tools like trigger-elicitation-request, so it stops short of full alternative routing.

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

Deploy Server

Other Tools