Skip to main content
Glama

MyOTP.App

by io.github.brntech

Check OTP delivery status

check_otp_status
Read-onlyIdempotent

Check whether a previously sent OTP is still active and (with DLR_ACCESS entitlement on Enterprise plan) get its delivery status. Returns is_active (bool) and expires_at (ISO timestamp) on every plan. On Enterprise plans, also returns DLR (one of 'delivered', 'sent', 'read', 'failed', 'pending'). Useful when an end user reports they didn't receive the code — you can confirm whether MyOTP delivered it before deciding to resend. Does NOT verify a code; use verify_otp for that.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
message_idYesThe UUID returned by `generate_otp` — this identifies which OTP you want a status report on.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
DLRNoDelivery state: carrier status (ATES, DELIVRD, UNDELIV, EXPIRED, REJECTD) or sent/delivered/read/pending/failed.<reason>, a 'Pending: ...' hint, or a 'Not available ...' explanation. Absent when the message_id is unknown.
DLR:NoDeprecated alias of DLR.
messageNoPresent instead of DLR when the message_id is not found.
Message:NoDeprecated alias of message.
is_activeNoWhether the OTP can still be verified (it has not expired).
expires_atNoISO 8601 date-time the OTP expires. Absent when the message_id is unknown.

Schema Changelog

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

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context beyond that: plan-dependent DLR availability, the DLR_ACCESS entitlement requirement, the specific returned fields, and a clarification that it does not verify codes. This meaningfully supplements the annotation-provided safety profile.

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?

The description is front-loaded with the core action and flows efficiently through return values, plan nuances, a real-world use case, and the explicit alternative. Every sentence contributes information; there is no filler or redundancy.

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?

For a single-parameter read-only status tool, the description covers the return shape on all plans, the Enterprise/DLR variation, the required entitlement, and the intended decision-making use case. With annotations and an output schema also present, nothing critical is missing for correct selection and invocation.

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?

The input schema already fully documents the single parameter `message_id` as the UUID returned by `generate_otp`. The description's reference to 'previously sent OTP' aligns with this but doesn't add meaningful parameter semantics beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

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?

The description clearly states the tool checks whether a previously sent OTP is still active and retrieves delivery status where available. It specifies the main resource (OTP status) and explicitly differentiates from `verify_otp`, saying it does NOT verify a code. This makes its role distinct among siblings.

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?

The description provides concrete usage context: use it when a user reports not receiving an OTP, to decide whether to resend. It also explicitly names `verify_otp` as the alternative for code verification, giving a clear when-not-to-use instruction. This is strong practical guidance.

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