Skip to main content
Glama

MyOTP.App

by io.github.brntech

Verify OTP

verify_otp

Verify a code submitted by an end user against the OTP MyOTP delivered. Returns {status: 'success'} if the code matches and the OTP hasn't expired — at that point the OTP is consumed and cannot be reused. Returns {status: 'failed', reason: 'invalid' | 'expired' | 'not found'} otherwise. You MUST pass either phone_number or message_id to identify which OTP you're verifying against. Call this after collecting the code from the user (login form, signup screen, etc.).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
otpYesThe OTP code the end user typed in (3-8 numeric digits). This is the code you're trying to verify against what was sent.
message_idNoThe UUID returned by `generate_otp`. Provide either this OR `phone_number`. Prefer this when you have it — it disambiguates if the same number got multiple OTPs.
phone_numberNoPhone number the OTP was originally sent to, in international format without + or leading 0. Provide either this OR `message_id` — `message_id` is more precise.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoWhy verification failed: 'invalid', 'expired' or 'not found'. Absent on success.
statusYes'success' when the code matched and the OTP was consumed, otherwise 'failed' (or 'expired').
messageYesMessage describing the verification result.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description clearly discloses that a successful verification consumes the OTP so it cannot be reused, and that expired codes fail. It also enumerates the exact failure reasons ('invalid' | 'expired' | 'not found'), adding meaningful behavioral detail beyond the readOnlyHint=false annotation.

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?

Every sentence adds necessary information: what it does, success/failure behavior, consumption side effect, required identifier selection, and when to call. It is compact but complete, well-structured, and free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema and the strong input schema, the description covers the essential operational context: the verification flow, required identifier, expiring/consumption behavior, and expected return statuses. An agent has enough information to call this tool correctly without ambiguity.

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 already provides 100% coverage with detailed descriptions for each parameter. The description adds crucial usage semantics not fully captured by the schema: you must pass either phone_number or message_id, and message_id is preferred because it disambiguates multiple OTPs for the same number.

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?

Description states a specific verb ('Verify'), the exact resource ('the OTP MyOTP delivered'), and the intended context (end-user code submission). The stated outcomes—success or failure with reasons—clearly differentiate it from a plain status check like check_otp_status.

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?

It explicitly says when to call: 'Call this after collecting the code from the user (login form, signup screen, etc.)'. It also clarifies the required identifying parameter, prefers message_id over phone_number, and explains why. It does not name alternative tools or explicitly say when not to use them, but the context is clear.

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

All MyOTP.App toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

OTP operations are clearly separated: generate, verify, check status, and extend each have distinct responsibilities, and the descriptions explicitly differentiate check_otp_status from verify_otp. The only real ambiguity is between get_account_info and get_account_status, which both return similar account/balance/plan details with somewhat fuzzy boundaries.

Naming Consistency5/5

All tools use consistent snake_case verb_noun naming, with get_ prefixed for read operations and action-specific verbs like generate, verify, extend, and top_up for state-changing operations. There are no mixed conventions or vague generic names.

Tool Count5/5

Ten tools is well-scoped for an OTP service covering account lifecycle, OTP operations, billing/top-up, and reporting. Each tool maps to a distinct workflow step, and none feel redundant or unnecessary.

Completeness5/5

The OTP lifecycle is fully covered from generation through verification, status checking, and extension, with supporting account, top-up, and usage-reporting tools. There are no obvious dead ends for typical OTP verification and billing workflows.

Resources