[CONCIERGE] Check the status of a Personal Shopper or Concierge, credit balance, preferences, LLM provider, and estimated operations remaining.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | Agent ID. If omitted, looks up by wallet_address. | |
| wallet_address | No | Wallet address to look up. Used if agent_id is not provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose what the tool checks (status, credit balance, preferences, provider, operations remaining) but does not explicitly state that it is a read-only operation, how the two lookup parameters interact, or what the response structure looks like. This is partial disclosure—more than just the name but lacking important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence, front-loaded with a category tag, listing the key data points. No wasted words, all information is relevant, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 optional params, no output schema), but the description lacks an explicit return structure or conditions. It lists the categories of information but doesn't define what 'status' means or how the data is presented. While adequate for a basic getter, it leaves gaps that an agent might need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with descriptions, including the fallback behavior for wallet_address when agent_id is omitted. The description adds no additional parameter meaning, so it does not justify raising above the baseline of 3, which is appropriate because schema coverage is 100% and the schema itself explains the relationship between the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a status checker for a Personal Shopper or Concierge, listing specific data points (credit balance, preferences, LLM provider, operations remaining). This differentiates it from sibling tools focused on agent standing, readiness, or points balance, and the verb 'check' combined with resource 'status of a Personal Shopper or Concierge' makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or alternative tools such as get_my_preferences or get_points_balance, so an agent would need to infer usage from the name and the sibling list, which may lead to ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes with clear category tags. Minor potential confusion between get_current_brief vs list_briefs and get_brand vs get_brand_mcp_endpoint, but descriptions clarify intent.
All tools follow a consistent verb_noun pattern using lowercase with underscores, e.g., check_agent_standing, list_drops, submit_design. No mixing of conventions.
32 tools is on the high side, but the server covers a wide domain including browsing, purchasing, design submission, concierge, and marketing. Each tool serves a specific function, though some consolidation could be possible.
The tool surface covers the full lifecycle of browsing, purchasing, design creation, commissions, and concierge services. Minor gaps like refund handling are absent, but the core workflows are well-supported.