maginary-mcp

Official

Overview Schema Source Related Servers Discussions Admin

check_account_status

Check account verification status, credit balance, and API key count. Poll after account creation to see if the verification link was clicked.

Instructions

Check account verification status, credit balance, and API key count.

Use this after ``create_account`` to poll whether the user has clicked the
verification link. Pass ``email`` + ``password`` (from ``create_account``)
for Basic auth, or omit both to use the configured API key.

Args:
    email: Account email (for Basic auth).
    password: Account password (for Basic auth).

Returns:
    Dict with ``verified`` (bool), ``email``, ``api_key_count``,
    ``credits_remaining``, ``uploads_remaining``.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_account_status"
  }
}

Input Schema

Name	Required	Description	Default
`email`	No
`password`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 5, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations present, the description carries the full burden, and it reveals key behavioral details: it is a read-only status check, accepts optional Basic auth credentials, and returns a structured dict with verified, email, api_key_count, credits_remaining, uploads_remaining. It does not mention potential errors or rate limits, but for this tool the core behavior is well disclosed.

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 compact and front-loaded: purpose sentence, usage context, concise Args, and Returns. There is no filler or repetition of schema information.

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 two-parameter status-check tool with an output schema, the description covers when to invoke it, how to authenticate in both modes, parameters, and return fields. Nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate; it does by defining email and password as Basic auth credentials obtained from create_account, and by stating that omitting both falls back to the configured API key. This adds meaning well beyond the bare schema field names.

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 opens with a specific verb ('Check') and a concrete resource (account verification status, credit balance, API key count). It clearly differentiates this from sibling tools like get_balance or create_account by covering a distinct account-status read.

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 instructs to use after create_account to poll verification-link clicks, and explains the two auth modes (Basic auth with email/password vs omitting both for API key). It does not list when-not-to-use cases or alternatives, but the provided context is sufficient for typical selection.

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

Deploy Server