Which size to buy in a men's shirt, from shirts he already owns that fit. Real garment measurements.
Scored across 3 tools
Each tool targets a different stage of the flow: raw garment measurements, a size recommendation for one specific shirt, and a multi-shirt buy list. The main risk is confusion between size_me and what_to_buy, since both return a size, but the descriptions distinguish 'one shirt, tell him the size' from 'build the card and return shirts to buy' well enough.
The names mix three conventions: a noun phrase (shirt_measurements), an imperative verb-object (size_me), and a question phrase (what_to_buy). They are readable and thematically consistent, but there is no predictable verb_noun pattern an agent can rely on.
Three tools is on the thin side but matches a narrow consumer flow: look up measurements, get a size, get a buy list. Nothing is redundant and each tool earns its place, though the surface is small enough that a bit more coverage would help.
The core read path is covered, but there is no way to add or edit the shirts he already owns, which what_to_buy depends on, and no way to look up or search for a shirt before calling shirt_measurements. These are notable gaps that could force an agent into a dead end.
The real garment measurements of a shirt (chest all the way around and length, in inches) in each size, from the brand's own chart or other checked sources. Not a body-size chart.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | ||
| size | No | Optional: just this size. | |
| brand | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read-only, closed-world lookup, so the bar is lower. The description still adds real behavioral value: the unit (inches), the meaning of 'chest' as all the way around rather than flat-lay, the fact that all sizes are covered, and data provenance ('brand's own chart or other checked sources'). It says nothing about behavior for unknown brands/items, which keeps it from a 5.
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?
One front-loaded sentence carrying the definition, unit, scope, and provenance, followed by a three-word scope exclusion. No filler and nothing that could be cut without losing information.
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?
With no output schema, the description does the right thing by naming the returned measurements and their unit. But it leaves the two required parameters unexplained and says nothing about what happens when a brand or item is not found, so an agent could still call it with malformed inputs.
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 only 33% — only `size` has a schema description. The description clarifies that results default to every size and that a single size can be targeted, but it provides no guidance on what `brand` and `item` expect as input formats, which are the two required parameters. It does not compensate for the coverage gap.
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 names a precise resource (real garment measurements of a shirt) and defines the exact fields returned (chest circumference and length, in inches) across sizes. The closing 'Not a body-size chart' carves out scope against body-measurement siblings like size_me, though it never names that sibling directly and uses a noun phrase rather than a verb.
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?
There is one useful exclusion ('Not a body-size chart'), which tells the agent when not to use it. However, no alternative tool is named and there is no positive statement of the situation that should select this tool over size_me or what_to_buy, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommends a size in one shirt for this man, from the shirts he already owns that fit. Returns the size, why (in terms of his own shirts), how it will fit, and a confidence. Tell him exactly the size it gives: it already accounts for his shirts, the fabric and the cut, so don't suggest a different size.
| Name | Required | Description | Default |
|---|---|---|---|
| shirt | Yes | The shirt he is thinking of buying. | |
| my_shirts | Yes | Shirts he owns, ideally 3-5 that fit him well. Brand, item and size only. | |
| suit_size | No | His suit jacket size off the label, if he knows it, e.g. "44L" or "42 Regular". Helps with Tall sizes. | |
| fit_preference | No | How he likes shirts to fit, if he said. Default standard. | |
| dress_shirt_size | No | His dress shirt size off the label, if he knows it, e.g. "17 34/35" (neck, sleeve). Helps with long sleeves. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, closed-world operation, and the description adds real behavioral context: what the tool returns (size, reasoning in terms of his own shirts, expected fit, confidence) and a strong constraint on how the agent should relay that output. It doesn't address what happens with sparse or contradictory shirt data, so not a 5.
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?
Three sentences, each doing work: the capability, the return shape, and the critical output-handling rule, with the core purpose front-loaded. Nothing redundant and nothing padded.
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?
For a tool with a nested schema and no output schema, the description covers both the input basis (his own shirts) and the full return shape (size, why, fit, confidence), plus how to communicate the result. An agent has what it needs to call it and act on the answer.
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 description coverage is 100%, so enums and nested fields are already documented; the description only adds the framing that the recommendation is derived from his existing well-fitting shirts and accounts for fabric and cut. That is helpful context but not new per-parameter meaning, so the baseline 3 applies.
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?
States a specific verb and resource (recommends a size, for one shirt) plus the basis for the recommendation (shirts he already owns that fit). That scope alone separates it from sibling tools like shirt_measurements and what_to_buy, which deal in raw measurements and purchase choice rather than a single size verdict.
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?
Gives an explicit instruction for how to use the result: tell him exactly the size it returns, and do not suggest a different size, with the reason spelled out. It does not explicitly compare itself to the sibling tools or state when this is the wrong tool to reach for, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Builds his Fit Card from the shirts he owns and returns the shirts that will fit him, each in the right size, with a buy link. Also returns a link to his full card on fitcard.ai. Give each shirt in exactly the size listed; a "snugger" or "roomier" note describes how that size fits, not a reason to size up or down.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many picks (default 8). | |
| category | No | Optional: only this kind of shirt. | |
| my_shirts | Yes | Shirts he owns, ideally 3-5 that fit him well. Brand, item and size only. | |
| suit_size | No | His suit jacket size off the label, if he knows it, e.g. "44L" or "42 Regular". Helps with Tall sizes. | |
| fit_preference | No | How he likes shirts to fit, if he said. Default standard. | |
| dress_shirt_size | No | His dress shirt size off the label, if he knows it, e.g. "17 34/35" (neck, sleeve). Helps with long sleeves. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, and the description is consistent: it discloses that a Fit Card is built (a persisted artifact) and that a link to the card on fitcard.ai is returned, which is real context beyond the annotations. It stops short of saying whether the card is public, whether it overwrites an existing card, or what happens on failure.
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?
Three sentences, front-loaded with what the tool produces, followed by the link behavior and then the sizing caveat. Nothing is padding, though the third sentence is tightly compressed relative to its importance.
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?
With no output schema, the description carries the return-value burden and does identify the three outputs: sized shirt picks, buy links, and a card link. Combined with 100% schema coverage and clear annotations, an agent has enough to call it correctly, though the shape of the returned picks is still only roughly described.
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 description coverage is 100%, so every parameter (limit, category, my_shirts fields, suit_size, fit_preference, dress_shirt_size) is already documented in the schema; baseline 3 applies. The description adds only the constraint that sizes must be submitted exactly as worn, which reinforces but does not extend the schema's per-field guidance.
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?
States a specific verb and resource: it builds a Fit Card from the shirts he owns and returns recommended shirts in the right size with a buy link. An agent can tell what it produces, though it never names or contrasts itself with the sibling tools shirt_measurements and size_me.
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?
Usage is implied by the input narrative ('ideally 3-5 that fit him well' in the schema, and the sizing caveat), but there is no explicit statement of when to call this versus shirt_measurements or size_me. The one guideline given — don't size up/down for a 'snugger' or 'roomier' note — is useful but concerns interpretation, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
shirt_measurementssize_mewhat_to_buyNeutral cross-brand bra-size translation and a live in-stock bra catalog by size.
Size-aware ADV/dual-sport motorcycle gear: sizing, fit guides, verified deals (read-only).
Independent menswear concierge: what to wear to any occasion, and is this piece worth the price.
Bra sizes from measurements, in each brand's own labels, with the confidence behind each.
Add one secure layer between your agents and this server.