get_customer_profile

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

With no annotations, the description carries the burden. It discloses that the tool aggregates data from five different API calls and returns a dict with five sections. It also notes that amounts are float in TWD. It does not explicitly state read-only behavior or potential latency from multiple calls, but the 'get' semantics and endpoint listing make it sufficiently transparent.

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?

The description is well-organized with a summary, usage section, API list, and return structure. Each sentence adds value; it is longer than minimal but justified by the tool's aggregation complexity. No wasted words.

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?

Despite having no output schema, the description clearly explains the return structure (dict with five sections) and data types. It names all involved endpoints, which helps the agent anticipate the tool's scope. The differentiation from get_rfm_analysis covers a key sibling relationship. Complete for practical use.

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?

Schema coverage is 100% (customer_id is documented as the internal ID from list_customers). The description adds no additional parameter-specific detail beyond the schema, but it does reinforce that this is a single-customer query. Baseline 3 is appropriate.

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 states it retrieves a single customer's complete profile (basic info, store credit, points, tier history, coupons) with a specific verb ('取得') and resource. It distinguishes itself from the sibling get_rfm_analysis for batch analysis, making its purpose unambiguous.

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?

Provides explicit usage context: suitable for customer service or individual member analysis, and explicitly directs batch analysis to get_rfm_analysis. It also lists the exact underlying Shopline API endpoints, giving the agent clear expectations of scope.

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