Tells an AI assistant how a watch fits a given wrist, with a to-scale drawing. Free, no sign-in.
Scored across 4 tools
Each tool has a distinct role: fit_watch checks specific named watches on a wrist, suggest_sizes gives general size ranges, and start_try_on/get_try_on_result form a clear create/retrieve pair. The boundary between fit_watch and suggest_sizes is clear from descriptions: one is per-watch fit, the other is generic sizing guidance.
All names use snake_case and lead with a verb (fit_watch, get_try_on_result, start_try_on, suggest_sizes). The try-on tools form a recognizable start/get pair, and no mixed conventions appear.
Four tools are well-scoped for a focused watch-fit server: direct fit checking, generic size guidance, try-on link creation, and try-on result retrieval. Each tool has a clear standalone purpose and no filler tools are present.
The set covers the main fit workflow: suggest sizes, check specific watches, launch a phone try-on, and retrieve the result. A minor gap is that there is no explicit catalogue search/browse tool, so agents must already know watch names for fit_watch.
How one to three watches fit a wrist of a given size, checked against WORN's catalogue of 46,000 watches (case, thickness, lug width): how far each watch's lugs stop from the edges of the wrist, whether it wears bigger or smaller than its case, and how it sits under a shirt cuff. Returns the verdicts in words, a link to the watches drawn to scale on the wrist, and the drawing as a card where cards are shown. Names are matched as people say them; case_mm and lug_to_lug_mm, when known, make the answer exact.
| Name | Required | Description | Default |
|---|---|---|---|
| watches | Yes | ||
| wrist_mm | Yes | Wrist circumference in mm, measured where a watch sits (17 cm is 170) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint=false already declared, the description adds real context: it reads a 46,000-watch catalogue, names fuzzy name matching, and discloses that lug-to-lug is estimated at 1.2× case when absent and flagged as estimated in the answer. That estimation caveat is exactly the kind of hidden behaviour an agent should know. It stops short of saying what happens when a name matches nothing in the catalogue.
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?
Front-loaded with what the tool computes and what it returns, then the matching and precision caveats. The middle clause sweeping three verdicts into one sentence is dense but each phrase carries distinct information. No filler, though the single long sentence is harder to scan than a short list would be.
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?
There is no output schema, so the description correctly takes on the return values — verdicts in words, a scale-drawing link, and a card — which is the critical piece. Combined with the estimation rule and name-matching note, an agent can call this correctly. The remaining gap is failure behaviour for unmatched watch names.
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 50% at top level but the nested watch properties are well documented; the description reinforces it by explaining that case_mm disambiguates between sizes of the same model and that lug_to_lug_mm is the one value the catalogue lacks. It does not mention note or thickness_mm, and adds no semantics the schema is missing. Slightly above baseline because it explains the *consequence* of supplying the numbers, not just their type.
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: fitting one to three watches to a wrist of a given size, checked against a 46,000-watch catalogue, and enumerates the outputs (lug clearance, relative wear, cuff behaviour). An agent can tell this is a fit-calculation tool rather than a general search. However, it never names the siblings (start_try_on, get_try_on_result, suggest_sizes), so the boundary between 'fit math' and 'generate a try-on image' is left to inference.
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 only implied: you call it when someone asks how a watch wears. The one piece of genuine guidance is about optional inputs — supplying case_mm and lug_to_lug_mm 'makes the answer exact' — but that is parameter advice, not tool-selection advice. No when-not-to-use, no mention of when to prefer start_try_on or get_try_on_result instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The wrist size the person measured with their phone through a try-on link (start_try_on), the watch they liked best, and how each watch fits that wrist. Says when they have not sent it yet, or when the link has expired.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code start_try_on returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only annotation already signals a safe read operation, and the description adds valuable context about pending and expired link states. It does not detail return shape or error handling beyond those states, but with annotations present the bar is lower.
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 two compact sentences that front-load the tool’s output and then note edge cases. Every clause contributes relevant information without redundancy.
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 simple retrieval tool with one fully documented parameter and no output schema, the description adequately explains what is returned and when results may be unavailable. It could be slightly richer about the per-watch fit structure, but it is largely 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?
The single parameter 'code' is fully documented in the schema as 'The code start_try_on returned', so the description adds no additional meaning beyond the schema and its reference to start_try_on.
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 exactly what the tool returns: the measured wrist size from a try-on link, the preferred watch, and fit details for each watch. It explicitly ties the tool to the sibling start_try_on, making its role distinct from creation or suggestion tools.
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?
It implies usage after start_try_on by referencing the try-on link and the code returned by that tool. It also notes two unavailable states (not sent yet, link expired), but does not explicitly compare alternatives like fit_watch or suggest_sizes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a person who does not know their wrist size, or wants to see watches on their own wrist. Makes a link, with a QR code for a computer, that opens on their phone: the back camera measures the wrist in a few seconds with no tape or coin, then draws each watch on a photo of their own wrist at true size, to switch between. Nothing of the picture leaves the phone; tapping Send shares only the size and the watch they liked, which get_try_on_result returns with the code. Up to three watches; the link works for an hour. A picture of each watch can come as a link in image_url (a cutout with a transparent background, or the maker's or a shop's product photo on a plain white or grey background, which WORN cuts out) or as an uploaded file in photos; WORN shows it on the wrist at true size in place of its drawing.
| Name | Required | Description | Default |
|---|---|---|---|
| photos | No | Pictures of the watches the person uploaded, straight on, to draw on their wrist in place of the drawing: a cutout, or the watch on a plain background, which WORN cuts out | |
| watches | Yes | The watches to try on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it is not read-only, not open-world, non-idempotent, and non-destructive, but the description adds substantial context: the phone-camera measurement, on-device privacy, one-hour link lifetime, three-watch limit, and what Send shares. Nothing contradicts the annotations.
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 dense but front-loads the user need and then explains the flow, privacy, limits, and image handling. It is somewhat verbose and repeats schema-covered details, but every sentence contributes operational context.
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 complex start-session tool with no output schema, the description covers the lifecycle, phone handoff, privacy, expiry, watch limit, image inputs, and result retrieval through get_try_on_result. An agent has enough context to call it correctly and set expectations.
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 the schema already documents watches, photos, image_url, and sizing fields in detail. The description reinforces the image_url versus photos distinction and the three-watch limit, but adds little syntax or semantics beyond the rich schema, so 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 states a specific action: it creates a QR link that opens on the phone, measures the wrist, and lets the person try on watches at true size. It references get_try_on_result for the result, but does not explicitly differentiate from siblings like fit_watch or suggest_sizes, so sibling differentiation is partial.
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?
It gives a clear use case: for someone who does not know their wrist size or wants to see watches on their own wrist. It implies the flow into get_try_on_result, but does not state when to choose this over fit_watch or suggest_sizes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The case diameters and lug-to-lug spans that fit a wrist of a given circumference, and why lug to lug matters more than the case.
| Name | Required | Description | Default |
|---|---|---|---|
| wrist_mm | Yes | Wrist circumference in mm, measured where a watch sits (17 cm is 170) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one useful behavioral hint — that the answer explains why lug-to-lug matters more than case diameter, implying reasoned output rather than a bare list — but says nothing about output shape, units, or bounds handling.
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 compact sentence that front-loads the returned values before the rationale clause. The trailing 'why lug to lug matters' phrase carries real information rather than filler, though the sentence is slightly dense as a single clause.
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 one-parameter, read-only tool with no output schema, the description adequately conveys what comes back: size ranges plus a lug-to-lug rationale. Only the ambiguity against fit_watch keeps it from being fully 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 description coverage is 100% and the single parameter is fully documented there, including the 17cm=170 convention and min/max bounds. The description restates the concept of wrist circumference without adding format or edge-case guidance, 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?
The description names the concrete outputs (case diameters and lug-to-lug spans) and the input condition (a wrist circumference), so an agent knows this is a sizing-recommendation lookup. It does not differentiate itself from the sibling fit_watch, which plausibly overlaps in purpose.
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 only implied: the agent can infer it applies when it has a wrist circumference and wants size ranges. There is no statement of when to prefer this over fit_watch or the try-on tools, and no exclusions are given.
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.
fit_watchget_try_on_resultstart_try_onsuggest_sizesFree AI calorie & macro tracker: tell your AI what you ate and it logs it to your private food diary
Time tracking you talk to: log, check and fix your work hours from your AI assistant.
Track anything by telling your AI: calories, habits, mood, spending and tasks on one dashboard.
Log workouts and meals by telling your AI. 873 exercises, muscle diagrams, food lookup.
Add one secure layer between your agents and this server.
