Skip to main content
Glama
Sign In
warp-mcp

warp-mcp

by Ringer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get port-out PIN status

num_get_port_out_pin
Read-onlyIdempotent

Check if a phone number has a port-out PIN set and, if verification attempts caused a lockout, when the lock expires. Use it before porting to confirm PIN status without exposing the PIN itself.

Instructions

Check whether a port-out PIN is set on a number you own, and if verification attempts locked it out, when the lock expires (locked_until). The PIN itself is never returned. Set a PIN with num_set_port_out_pin; clear it with num_remove_port_out_pin. Errors: TN_NOT_OWNED.

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": {
      "tn": "<tn>"
    },
    "name": "num_get_port_out_pin"
  }
}

Input Schema

NameRequiredDescriptionDefault
tnYesTelephone number, 10 digits (e.g. "3035551234") or 11 digits with leading 1

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A4.2/5.0
Behavior4/5

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

Annotations indicate idempotent, read-only, and non-destructive behavior. The description adds value by stating the PIN is never returned and mentioning the specific error TN_NOT_OWNED, which helps agents handle failures. This goes beyond what annotations alone provide.

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?

Extremely concise: two sentences for the core description plus one for errors. Every sentence provides essential information without redundancy. The purpose is stated immediately, and additional context is efficiently given.

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 simple read-only check tool with one parameter and no output schema, the description is complete. It explains what is checked (PIN set, lock status, lock expiration) and what is not returned (PIN). No output schema is needed given the simplicity.

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 only parameter 'tn' has 100% schema coverage, including format examples. The description does not add additional semantics beyond the schema, so it receives the baseline score of 3 for well-documented parameters.

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 it checks whether a port-out PIN is set and if locked out, with the locked_until timestamp. It specifically notes the PIN itself is never returned, distinguishing it from get-like tools that might return secrets. References to sibling tools num_set_port_out_pin and num_remove_port_out_pin clarify the broader context.

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?

Explicitly tells when to use this tool (to check PIN status or lockout). Provides clear alternatives for setting and removing the PIN. Does not explicitly state when not to use, but the context is clear considering sibling tools.

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

Deploy Server

Other Tools