Skip to main content
Glama

Revdoku Signup

revdoku_signup

Create a Revdoku account with the human owner's authorization. Sends an email verification code; no account, mailbox or key is created until revdoku_signup_verify succeeds. Supply the human's own email. Keep signup_token, verification codes and keys in the application's private credential flow, never ordinary chat or logs. Existing users must sign in through OAuth. Do not automatically retry an uncertain signup.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailYesEmail supplied by the human owner; never substitute an agent mailbox.
accept_terms_and_policyYesAgree to the Terms (https://revdoku.com/terms) and Acceptable Use Policy (https://revdoku.com/acceptable-use), and acknowledge the Privacy Policy (https://revdoku.com/privacy).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / properties / accept_terms_and_policy / description
      Previous value: -"The human agrees to the Terms (https://revdoku.com/terms) and AUP (https://revdoku.com/acceptable-use), and acknowledges the privacy notice (https://revdoku.com/privacy). Read all three documents without website access at https://api.revdoku.com/v1/agent_auth/policies. Reading does not grant authorization. This is not consent to optional processing."New value: +"Agree to the Terms (https://revdoku.com/terms) and Acceptable Use Policy (https://revdoku.com/acceptable-use), and acknowledge the Privacy Policy (https://revdoku.com/privacy)."
    • addedInput schema / properties / email
      Added value: +{
      +  "description": "Email supplied by the human owner; never substitute an agent mailbox.",
      +  "maxLength": 254,
      +  "type": "string"
      +}
    • removedInput schema / properties / human_operator_email
      Removed value: -{
      -  "description": "Email supplied by the human owner; never substitute an agent mailbox.",
      -  "maxLength": 254,
      -  "type": "string"
      -}
    • removedInput schema / properties / label
      Removed value: -{
      -  "description": "Name for the new connection.",
      -  "maxLength": 100,
      -  "type": "string"
      -}
    • removedInput schema / properties / permission_scope
      Removed value: -{
      -  "description": "Connection permissions authorized by the human; defaults to mailbox_admin.",
      -  "enum": [
      -    "mailbox_read",
      -    "mailbox_write",
      -    "mailbox_admin"
      -  ],
      -  "type": "string"
      -}
    • removedInput schema / properties / username
      Removed value: -{
      -  "description": "Optional prefix for the first Free mailbox. A 12-character random suffix is added; omit to generate a name.",
      -  "maxLength": 64,
      -  "minLength": 1,
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "human_operator_email",
      -  "accept_terms_and_policy"
      -]New value: +[
      +  "email",
      +  "accept_terms_and_policy"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / accept_terms_and_policy / description
      Previous value: -"The human agrees to the Terms (https://revdoku.com/terms) and AUP (https://revdoku.com/acceptable-use), and acknowledges the privacy notice (https://revdoku.com/privacy). This is not consent to optional processing."New value: +"The human agrees to the Terms (https://revdoku.com/terms) and AUP (https://revdoku.com/acceptable-use), and acknowledges the privacy notice (https://revdoku.com/privacy). Read all three documents without website access at https://api.revdoku.com/v1/agent_auth/policies. Reading does not grant authorization. This is not consent to optional processing."
  3. Changed1 schema field changed
    • changedInput schema / properties / username / description
      Previous value: -"Optional exact username for the first mailbox; omit to generate one."New value: +"Optional prefix for the first Free mailbox. A 12-character random suffix is added; omit to generate a name."
  4. Changed2 schema fields changed
    • changedInput schema / properties / permission_scope / description
      Previous value: -"Connection permissions authorized by the human; defaults to bucket_admin."New value: +"Connection permissions authorized by the human; defaults to mailbox_admin."
    • changedInput schema / properties / permission_scope / enum
      Previous value: -[
      -  "bucket_read",
      -  "bucket_write",
      -  "bucket_admin"
      -]New value: +[
      +  "mailbox_read",
      +  "mailbox_write",
      +  "mailbox_admin"
      +]
  5. Added

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that an email verification code is sent, that nothing is provisioned until verify succeeds, that tokens/codes/keys must stay in a private credential flow and out of chat or logs, and that retrying an uncertain signup is unsafe. The idempotentHint=false is corroborated with actionable 'do not retry' guidance.

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?

Front-loaded with purpose, then constraints and security guidance, in five tight sentences with no filler. Slightly long, and the 'human's own email' instruction partly repeats the schema description, but each sentence carries operational value.

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?

No output schema exists, yet the description implies a signup_token is returned and describes the two-step signup/verify lifecycle well enough to call the tool correctly. It stops short of describing the exact response payload, which is a minor gap rather than a blocker.

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 100% and both parameters are already documented in the schema, including the 'human owner's email, never an agent mailbox' constraint. The description reinforces the same point ('Supply the human's own email') but adds no new syntax, format, or edge-case detail. Baseline 3 for a fully documented schema.

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 ('Create a Revdoku account') and immediately bounds the effect ('no account, mailbox or key is created until revdoku_signup_verify succeeds'). This distinguishes it cleanly from siblings revdoku_signup_verify and revdoku_signup_resend.

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?

Provides explicit routing: use this to sign up, existing users must instead sign in through OAuth, and do not automatically retry an uncertain signup. The prerequisite (human owner's authorization and own email) and the follow-up step (verify) are both named.

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.