Retrieves a customer's full profile, lifetime value, order status breakdown, and order history by customer ID, so agents can answer account and purchase questions.
Retrieve complete customer profile, lifetime value, breakdown of orders by status, and order history
| Name | Required | Description | Default |
|---|---|---|---|
| customerId | Yes | Unique numeric ID of the customer |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the returned data (lifetime value, order history, status breakdown), which is useful, but it doesn't state whether the operation is read-only, whether it requires permissions, or what happens for a nonexistent customer. For a read operation with one ID, this is adequate but not rich.
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, front-loaded sentence that lists the key returned data with no filler. Every phrase earns its place by naming a distinct component of the profile.
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?
Given one simple parameter, full schema coverage, and no output schema, the description adequately conveys what the tool returns and when to call it. It could be stronger if it noted authentication or error behavior, but for this complexity level it is nearly complete.
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% and there is a single required parameter documented with type and constraints. The description adds nothing about the parameter, but with complete schema documentation the baseline is 3; a 4 is warranted because the parameter is simple and fully specified in the schema, and the description correctly implies a single-customer lookup.
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 states a specific verb (Retrieve) and resource (customer profile) and enumerates the data returned: lifetime value, order status breakdown, order history. It is clear what the tool does, though it doesn't explicitly differentiate from sibling 'list_customers', which is a minor gap for a read tool with only one required ID parameter.
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 implies you use this to get a single customer's full profile (given the required customerId), but it does not state when to use this versus list_customers or get_order_details, nor does it mention authorization or exclusions. Usage is inferable from the name and parameter, but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.