Resolve Grok Bot cloud agent widgets by responding, dismissing, submitting forms or secrets, or approving requests using agent and entry IDs.
Resolve a widget: respond, dismiss, form, secret, or approve.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| value | No | ||
| action | Yes | ||
| values | No | ||
| agent_id | Yes | ||
| approved | No | ||
| entry_id | Yes | ||
| request_id | No | ||
| session_id | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=false, openWorldHint=true, and idempotentHint=false, but the description adds zero behavioral context: no statement of side effects, permission requirements, whether actions are reversible, or what each action does to server state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short and front-loaded, but it is under-specification rather than conciseness — it spends its few words restating the enum instead of conveying the one piece of information an agent actually needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A mutation tool with 9 parameters, 0% schema coverage, nested objects, no output schema, and openWorldHint=true demands far more than 11 words. The description leaves the required-field/action coupling, return behavior, and error handling completely undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 9 parameters, and the description only echoes the enum values already present in the schema. Parameters like value, values, approved, kind, request_id, and session_id are entirely unexplained in both places, leaving the agent no way to know which fields pair with which action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially the tool name stripped of its prefix ('Resolve a widget') plus a verbatim restatement of the schema's action enum. It never defines what a 'widget' is or what resolving one accomplishes, so an agent cannot distinguish its purpose from siblings like grokbot_pending beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisite conditions, and no reference to any alternative tool. Nothing tells the agent when resolving a widget is appropriate versus calling grokbot_pending to discover one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.