Skip to main content
Glama
Sign In

Widely

by com.widely-mobile
OverviewDiscussionsAdmin

Confirm the app account email

confirm_platform_email
Idempotent

Confirms the email code for a swift_platform account, or sends the code again when resend is true. No sign-in. Omitted confirm returns a preview and does not check the code. The code is not repeated in the result. When the account is on this connection, refresh tools, call get_account without an account to list them, then pass account by name. When it is not, add it from Connected apps, or reconnect and tick it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "email": "<email>"
    },
    "name": "confirm_platform_email"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeNoThe code from the email. Omit when resend is true.
emailYes
resendNo
confirmNoOmitted returns a preview on every client. True checks the code or resends it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is partly covered. The description still adds real behavioral value: no sign-in is required, omitting confirm returns a preview and performs no check, and the code is deliberately not echoed back in the result.

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

Conciseness3/5

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

The first three sentences are dense and front-loaded with the most important information. The final two sentences about connection state and Connected apps are verbose and reference a parameter that does not exist, so they cost more attention than they return.

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 four-parameter mutation tool with no output schema, the description covers the important unknowns: preview-vs-check semantics, resend behavior, no sign-in, and non-echo of the code. It stops short of describing what a preview actually contains or what happens on an invalid code, but the essentials are present.

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 only 50% (only code and confirm carry descriptions), so the description has to compensate, and it does: it explains the resend boolean's effect and clarifies that omitting confirm yields a preview. The email parameter remains undescribed in both places, and the stray 'account by name' reference muddies rather than clarifies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Confirms the email code for a swift_platform account') and immediately names the second mode ('sends the code again when resend is true'). The dual confirm/resend behavior is clear, though it never contrasts itself with any sibling tool by name.

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

Usage Guidelines3/5

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

It does give conditional guidance: use the omitted-confirm preview path versus passing true, and it explains the account-connection prerequisites ('refresh tools, call get_account... then pass account by name'). However, that instruction references an 'account' argument that does not exist in the schema, and the 'Connected apps' / 'reconnect and tick it' sentence is opaque and not clearly actionable.

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

All Widely toolsInspect
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