Skip to main content
Glama

set_account_slot

DestructiveIdempotent

Set custom metadata on an account by storing a key-value pair as a string. Use for APR, credit limits, reward rates, or any per-account data.

Instructions

Set a custom metadata slot on an account.

Stores a key-value pair on the account. Values are stored as strings. Use for APR, credit limits, reward rates, or any per-account metadata.

Args: account: Account ref: full path (e.g., "Liabilities:Credit Cards:Capital One"), %short GUID, or full 32-char GUID. key: Slot key (e.g., "apr", "credit_limit"). value: Slot value (always stored as string).

Input Schema

NameRequiredDescriptionDefault
keyYes
valueYes
accountYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.2

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds value by stating 'Values are stored as strings,' which signals type coercion, and clarifies the slot is a custom key-value pair. It does not repeat annotation flags, and there is no contradiction.

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 three short paragraphs: purpose, use cases, and parameter breakdown. Every sentence carries necessary information, and the purpose is front-loaded. No redundant or filler text.

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 3 required params, output schema presence, and annotations (idempotent+destructive), the description is complete. It covers parameter formats, string coercion, and use cases; the only missing detail is explicit overwrite behavior, which idempotentHint/destructiveHint already imply.

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 has 0% description coverage, so the Args block carries full weight. It explains account ref formats (full path, %short GUID, full 32-char GUID), gives key examples, and notes value is always stored as a string. This fully compensates for the bare schema.

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?

Description opens with 'Set a custom metadata slot on an account,' a specific verb and resource. It further clarifies 'Stores a key-value pair on the account,' distinguishing it from sibling get_account_slots and delete_account_slot. No ambiguity about what is modified.

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 says 'Use for APR, credit limits, reward rates, or any per-account metadata,' giving clear when-to-use context. It does not explicitly name sibling alternatives or provide exclusions, so it falls short of a 5 but is well above implied usage.

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