Skip to main content
Glama

Verify the account email

verify_account

Prove the address with the 6-digit code emailed by sign_up. Without a key on the connection, pass the email too: on success this returns the API key (shown once). Turns on email notifications.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYes
agentNo
emailNoRequired when not yet connected with a key
presetNoNamed scope bundle: full (everything), wiring (forms only, no submission access), readonly, triage
scopesNoExplicit scopes, instead of a preset. Ignored where it would exceed the calling key's own scopes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose two non-obvious behaviors: a one-time API key is returned on success, and email notifications get turned on as a side effect. That is genuinely useful disclosure beyond the schema, though it omits retry limits, code expiry, and the scope implications of the request.

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 short sentences, each carrying distinct information (action + code source, conditional email + return value, side effect), with the essential mechanics front-loaded and no filler.

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?

There is no output schema, so the description's disclosure that an API key is returned once is exactly the missing piece an agent needs. Combined with the conditional-email rule and the notification side effect, it is largely complete, with only the 'agent' parameter and error/expiry behavior unexplained.

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 coverage is 60%, so the baseline is 3. The description reinforces the conditional email requirement and explains the notable return value, but the 'agent' parameter is documented nowhere and preset/scopes semantics are left entirely to the schema descriptions.

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?

States a specific action (prove/verify the account email) with the exact mechanism (6-digit code emailed by sign_up), which anchors it among the many account tools. It doesn't explicitly differentiate itself from resend_verification_code, but the code-generation source is named, so an agent can place it correctly.

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?

Implies the usage window by referencing sign_up as the code source and gives one concrete conditional (pass email when not connected with a key). It never states what to do with an expired/rejected code or routes to resend_verification_code as the alternative, so guidance is implied rather than explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources