Skip to main content
Glama
tokportal

tokportal-mcp

Official

tokportal_retrieve_account_verification_code

Retrieve the latest verification code for a saved account. Access is governed by the account's creation date policy.

Instructions

Retrieve latest account verification code. Retrieving a verification code is the same irreversible first-access event as revealing credentials. Its policy is determined by this saved account's created_at timestamp against the immutable managed_pricing_new_customer_cutover_at value, never by the workspace action-pricing cohort or August 14 grace deadline. A saved account created before the cutoff permanently keeps the prior API contract: 0 credits, no new versioned acknowledgment body required, no TokPortal detachment, existing task access remains available, and support plus ban coverage end after access. A saved account created at or after the cutoff follows the managed policy: normally 150 credits, or the stored $10 legacy / $15 new per-30-day rate when Account Owning is already admin-approved. Managed access permanently detaches the account, makes it read-only, and ends TokPortal Coverage, task access, analytics updates, support, ban protection, replacement, refunds, compensation and credit restoration. For a new-policy account, missing explicit acceptance fails with 428 and returns the exact account-specific terms, price and policy version. A changed quote returns 409 before any debit or reveal. Reaching the Account Owning eligibility threshold only submits an admin review request; it never activates the agreement automatically. While approval is pending, reveal remains available for 150 credits on a post-cutoff account. Do not send Idempotency-Key: this response contains a verification secret and is never stored in the replay ledger. A request that includes the header is rejected before any ledger claim, reveal, debit, or inbox access with IDEMPOTENCY_KEY_NOT_ALLOWED_FOR_SENSITIVE_RESPONSE (400). After an uncertain transport result, fetch the safe account state before deciding whether to call this endpoint again without the header.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesSaved account ID.
bodyNoJSON request body.
Behavior5/5

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

The description comprehensively discloses behaviors beyond annotations: irreversible first-access event, credit cost implications (0, 150, or other rates), policy-dependent outcomes, detachment and loss of access for managed accounts, and idempotency key rejection. Annotations only hint at non-read-only, but the description adds critical detail about side effects and error paths.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely long (over 400 words) and dense, without front-loading the most critical information. While every sentence adds value, it could be restructured with bullet points or sections to improve readability for an AI agent. The current block of text risks information overload.

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 tool's complexity (policy branching, error codes, irreversible actions), the description covers all necessary outcomes, prerequisites, and error conditions. No output schema exists, but the description explains what returns (verification secret, errors), making it complete for safe invocation.

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 coverage is 100%, so baseline is 3. The description adds meaning by explaining the policy_version must come from a 428 or 409 error's details.policy_version, and that acknowledge_support_forfeit is only required on first access. However, it doesn't describe the 'id' parameter beyond the schema, missing an opportunity to clarify which type of 'saved account' is relevant.

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 starts with a clear verb+resource: 'Retrieve latest account verification code.' It then distinguishes this tool from siblings by detailing the specific policy logic for different account creation dates, which no other sibling tool does. This makes the purpose precise and unique.

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 explicit when-to-use conditions (checking account creation date vs. cutoff), when-not-to-use (do not send Idempotency-Key), and alternatives (mentioning the 'safe account state' for uncertain transport results). It also warns against incorrect usage that could lead to rejection or errors.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tokportal/tokportal-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server