Skip to main content
Glama

Show the connected ProofSnap account

whoami
Read-onlyIdempotent

Returns the connected ProofSnap account: plan, environment (test captures carry a TEST watermark and are not billed, live captures are billed) and whether the plan may create captures.

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": "whoami"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
idNoStable opaque account reference
envNo
planNo
emailNoThe account's email address
usageNo
scopesNo
serverNoproduction or development
nicknameNo
connectionNo
credentialNo
account_refNo
organizationNo
api_read_onlyNo
email_verifiedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare it read-only, idempotent, and non-destructive, so the bar is lower. The description still adds real value beyond them: it explains the test-vs-live watermark/billing distinction and that the response signals whether captures can be created, which is non-obvious operational context.

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

Conciseness4/5

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

A single front-loaded sentence with no preamble, and the parenthetical about test vs live earns its space by explaining billing semantics. Slightly dense but nothing is wasted.

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?

With no parameters, full annotation coverage, and an output schema that already defines the return shape, the description only needs to frame what the account object conveys — and it does, including the billing and permission signals. Only the explicit 'use this before X' framing is missing.

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?

The tool takes zero parameters, so the baseline is 4; there is no parameter meaning for the description to supply or omit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Returns') and resource ('the connected ProofSnap account') and enumerates what is returned: plan, environment, and capture-creation eligibility. It is clearly distinct from capture-manipulation siblings, though it doesn't name any sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied — an agent can infer this is a pre-flight/account-status check to run before creating captures, especially given the 'whether the plan may create captures' clause. No explicit when-to-use, when-not, or alternative is stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.