Skip to main content
Glama

my_capabilities

WHO YOU ARE AND WHAT YOU CAN DO with this token: the tool of the PERMISSIONS and of this credential's identity. Do NOT use it for your owner's profile data: that is my_profile. Do NOT use it for balances: that is my_balance (and it is the only one that carries figures). accountType is "delegate", ownerHandle is your owner's @handle, isSeller says whether TODAY you may use the seller scope with THEIR membership (and canSellReason why not), scopes are your permissions, ownerWallet is your owner's wallet (which you cannot use) and agentWallet is YOURS, the one you pay with.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopesYesThe permissions of THIS token, already trimmed by the dispatcher.
isSellerYesIt can use the seller scope TODAY with this token.
accountTypeYesWhat kind of credential is calling.
agentWalletNoWallet of the delegate; only when one calls.
ownerHandleNo@handle of the owner; only when a delegate calls.
ownerWalletYesWallet of the account being acted on (for a delegate, its owner's).
payerWalletYesThe address that signs the deposit, always present; null if that wallet does not exist yet.
canSellReasonNoWhy it cannot sell; absent when it can.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedOutput schema / properties / accountType / description
      Previous value: -"Qué clase de credencial llama."New value: +"What kind of credential is calling."
    • changedOutput schema / properties / agentWallet / description
      Previous value: -"Wallet del delegado; solo cuando llama uno."New value: +"Wallet of the delegate; only when one calls."
    • changedOutput schema / properties / canSellReason / description
      Previous value: -"Por qué no puede vender; ausente cuando sí puede."New value: +"Why it cannot sell; absent when it can."
    • changedOutput schema / properties / isSeller / description
      Previous value: -"Puede usar HOY el ámbito seller con este token."New value: +"It can use the seller scope TODAY with this token."
    • changedOutput schema / properties / ownerHandle / description
      Previous value: -"@handle del dueño; solo cuando llama un delegado."New value: +"@handle of the owner; only when a delegate calls."
    • changedOutput schema / properties / ownerWallet / description
      Previous value: -"Wallet de la cuenta sobre la que se actúa (para un delegado, la de su dueño)."New value: +"Wallet of the account being acted on (for a delegate, its owner's)."
    • changedOutput schema / properties / payerWallet / description
      Previous value: -"La dirección que firma el depósito, siempre presente; null si esa wallet aún no existe."New value: +"The address that signs the deposit, always present; null if that wallet does not exist yet."
    • changedOutput schema / properties / scopes / description
      Previous value: -"Los permisos de ESTE token, ya recortados por el dispatcher."New value: +"The permissions of THIS token, already trimmed by the dispatcher."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full disclosure burden. It adds useful behavioral context: accountType is 'delegate', ownerWallet cannot be used, agentWallet is the one to pay with, and isSeller is time-sensitive ('whether TODAY you may use the seller scope'). It does not explicitly state the tool is read-only, but the identity/permissions framing strongly implies an introspection call.

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?

The description packs a lot of useful field semantics into a dense block. It front-loads purpose and exclusions before diving into field details, and every sentence contributes. The heavy ALLCAPS and run-on field list make it slightly less scannable, but there is no real waste.

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 zero-parameter introspection tool with an output schema, the description is complete: it explains each field's meaning, constrains which wallet can be used, clarifies the seller scope condition, and identifies when to use sibling tools instead. Nothing critical is missing for an agent to call it appropriately.

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 has zero parameters, so the baseline is 4. The description meaningfully explains the fields that will appear in the output (accountType, ownerHandle, isSeller, scopes, ownerWallet, agentWallet), which adds value beyond the output schema. No parameter-specific documentation is needed.

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 explicitly frames the tool as exposing the credential's identity and permissions ('WHO YOU ARE AND WHAT YOU CAN DO') and gives it a clear role as the tool of permissions. It also distinguishes itself from siblings by naming my_profile for owner profile data and my_balance for balances, so an agent can select it over similar my_* tools.

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 gives explicit when-not-to-use instructions with named alternatives: do not use it for owner profile data (that is my_profile) and do not use it for balances (that is my_balance, noted as the only one carrying figures). This directly routes an agent to the correct tool without requiring inference.

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.

Resources