shapeless

Who am I

me

Read-only

Retrieve the authenticated account's email, plan, and credit balance. Requires the read scope to confirm which credential is active.

Instructions

Who this credential belongs to: email, plan, credit balance. Needs the read scope.

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

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`plan`	No
`user`	Yes
`entitled`	Yes
`accountId`	No
`balanceUsd`	Yes
`engineLive`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.4Oct 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds a real behavioral constraint the annotations do not capture: 'Needs the read scope,' i.e., an auth prerequisite. It stops short of saying what happens on a missing scope, but that is a minor gap.

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?

Two short clauses, no filler: the identity/return summary is front-loaded and the auth requirement follows. Every clause carries information.

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?

An output schema exists, so the description needn't enumerate return structure in detail; naming email, plan, and credit balance is sufficient orientation. The auth-scope caveat plus the safety annotations make this complete enough for a zero-parameter identity call, though a note on failure behavior when the scope is absent would close the last gap.

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 per the rubric the baseline is 4. The description correctly avoids inventing parameter detail and instead spends its words on the returned fields, which is the appropriate emphasis for a parameterless call.

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?

Names the exact resource (the credential's identity) and enumerates the concrete return fields: email, plan, credit balance. No sibling tool in the list does identity resolution, so the agent can distinguish it immediately without opening the schema.

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?

The description implies the usage context (inspecting who the current credential is), but never states when to call it versus alternatives or under what conditions — e.g., as a preflight check before other calls. With no real sibling competitor, the absence of exclusions is less costly, but the guidance is only implied.

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

Deploy Server