Tattoo size minimums, body-area comparison, line-spacing check and a pre-booking checklist.
Scored across 5 tools
Each tool has a fairly distinct trigger: a specific idea assessment, a line-spacing arithmetic check, a cross-area comparison, a booking checklist, and a general size chart. There is mild overlap between assess_tattoo_idea and get_tattoo_size_chart, and both assess_tattoo_idea and compare_tattoo_placements return placement estimates (fade, sun, friction, stretch), but the descriptions clearly scope one as specific-design vs. general-comparison.
All five tools follow a clean verb_noun snake_case pattern: assess_tattoo_idea, check_line_spacing, compare_tattoo_placements, get_pre_booking_checklist, get_tattoo_size_chart. The convention is predictable and readable throughout.
Five tools sit comfortably in the well-scoped 3-15 range and each covers a distinct facet of the tattoo sizing/placement domain. No redundant or filler tools are apparent.
The surface covers sizing, placement comparison, line aging, design-kind minimums, and booking readiness, which is solid lifecycle coverage for a guide. Minor gaps exist around aftercare/healing guidance and converting a chosen design into practical next steps, but core workflows are handled.
Use when the user describes a specific tattoo idea and asks whether it will hold up at a given size and body placement. Compares the design with published minimum sizes for its kind of design and returns the placement's fade, sun, friction, stretch and curvature estimates, style notes, things to look at and questions for the artist. Lettering is sized by capital letter height (letter_height_mm); everything else by the longest side (size_cm). It does not generate designs, look at images, or give medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Tattoo style, if the user has one in mind. | |
| size_cm | No | Longest side of the whole design in centimetres. Use for every design_type except block_capitals and script_lettering. | |
| placement | No | Body area, if the user has one in mind. | |
| design_type | Yes | Kind of design: block_capitals (capital letters), script_lettering, eye, bold_symbol_or_short_word (silhouette, simple symbol), fine_botanical (flower or plant with veins/stamens), moderate_detail (two line weights, simple shading), realistic_face, realism_japanese_or_dense_floral. | |
| letter_height_mm | No | Height of a capital letter in millimetres. Use for block_capitals and script_lettering. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| sources | No | |
| touch_ups | No | |
| size_check | No | |
| design_type | No | |
| style_notes | No | |
| placement_profile | No | |
| things_to_look_at | No | |
| questions_for_the_artist | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered without prose. The description adds real value beyond that: it enumerates the returned dimensions (fade, sun, friction, stretch, curvature, style notes, questions for the artist) and discloses the measurement convention, which the agent needs to interpret results. It does not discuss failure modes when size or placement is omitted.
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, no filler: trigger first, then output content, then scope exclusions. The long middle sentence is dense but every clause maps to a distinct returned field or sizing rule, so nothing is padding.
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 an output schema present, the description need not document return values, and the read-only annotations cover the action profile; the remaining ambiguity is behavioral rather than descriptive. It stops short of saying what happens when only the required design_type is supplied and style, size_cm or placement are omitted, which is a realistic call pattern for this tool given four of five parameters are optional.
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%, including per-parameter usage rules for size_cm and letter_height_mm, so the schema already carries the semantics and the baseline is 3. The description restates the lettering-vs-everything-else sizing rule (capital letter height vs longest side), which reinforces rather than extends the schema, adding little new information.
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 ('assess a tattoo idea's size, placement and style') plus the concrete trigger condition (user asks whether a design will hold up at a given size and placement). It also carves out what it is not (design generation, image analysis, medical advice), which separates it from get_tattoo_size_chart and the checklist siblings. An agent can route to it without opening any schema.
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 opening clause is an explicit when-to-use trigger, and the closing sentence gives three clear when-not conditions (does not generate designs, look at images, or give medical advice). It never names a sibling tool as the better alternative for the overlapping 'size chart' case, so the routing versus get_tattoo_size_chart is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user gives a line width and the gap between two lines or letters in millimetres and asks whether the gap will stay open as the tattoo ages. Applies the published rule of thumb that a line widens by about 0.1 mm per decade: returns the line width and gap after the given number of years (default 20), whether the gap meets the guides' 'at least as wide as the line' rule, and what the guide's worked example would do to it. Illustrative arithmetic, not a measurement.
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | Years to project. Defaults to 20. | |
| gap_mm | Yes | Width of the space between the two lines or letters, in millimetres. | |
| line_width_mm | Yes | Width of the line in millimetres, as drawn today (for example 0.3 fine line, 1.5 bold outline). |
| Name | Required | Description |
|---|---|---|
| note | No | |
| after | No | |
| today | No | |
| source | No | |
| status | No | |
| sources | No | |
| assumptions | No | |
| explanation | No | |
| worked_example | No | |
| guide_gap_range_mm | No | |
| years_until_gap_used_up | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the projection model (0.1 mm widening per decade), the default horizon of 20 years, and the important caveat that this is illustrative arithmetic rather than a measurement.
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 paragraph: the usage trigger comes first, then what is computed, then the caveat. Every sentence carries information, though it is on the denser end for what is essentially a three-parameter calculation.
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 annotations covering safety, a full schema, and an output schema, the description only needed to convey purpose, trigger and the model's caveat — all of which it does. Nothing an agent needs to invoke this correctly is missing.
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%, so the baseline is 3; the description goes beyond the schema by explaining the widening rule that gives `years` and the two width parameters their meaning, and by confirming the default of 20 years. It does not add unit or boundary detail beyond what the schema already states.
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 specific computation (projecting line width and gap over time under a stated 0.1 mm/decade rule) and the concrete question it answers. It is unmistakably distinct from siblings like get_tattoo_size_chart or compare_tattoo_placements, which handle different concerns.
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 trigger: use when the user supplies a line width and a gap in millimetres and asks whether the gap will stay open with age. No explicit exclusions or named alternative tools are given, but the sibling set is far enough away that routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks how body areas compare for pain, fading, sun, friction, stretch or curvature, or which areas hold ink longest. Returns the ten common areas (or the ones requested), ordered by fade by default. Estimates are coarse 0-100 comparisons, not measurements.
| Name | Required | Description | Default |
|---|---|---|---|
| sort_by | No | Order, lowest first. Defaults to fade. | |
| placements | No | Areas to compare. Omit for all ten. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| areas | No | |
| source | No | |
| sorted_by | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured context: 'Estimates are coarse 0-100 comparisons, not measurements,' which tells the agent to qualify the output, plus the default ordering behavior. It does not describe the response shape, but the output schema carries that.
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 the usage trigger, then output scope, then the precision caveat. No filler or restated title. Slightly dense in the trigger clause but every sentence earns its place.
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 an output schema present, return-value detail is not the description's job, and annotations cover the safety profile. The description supplies the trigger conditions, default ordering, and the coarse-estimate caveat, which is enough for correct invocation. It is not exhaustive — no note on how many areas may be passed together or how ties are handled — but nothing essential is missing.
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 sort_by and placements, and the baseline is 3. The description reinforces defaults ('ordered by fade by default', 'or the ones requested') but adds no syntax or semantics beyond what the schema states. Minor note: 'stretch or curvature' are offered as comparison topics yet are absent from the sort_by enum, leaving a small ambiguity the description does not resolve.
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 (compare) and resource (body areas/placements), and discloses the output scope: 'Returns the ten common areas (or the ones requested), ordered by fade by default.' No sibling (assess_tattoo_idea, check_line_spacing, get_pre_booking_checklist, get_tattoo_size_chart) covers cross-area comparison, and the description makes that scope legible without opening the schema.
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?
Opens with an explicit trigger list: 'Use when the user asks how body areas compare for pain, fading, sun, friction, stretch or curvature, or which areas hold ink longest.' That maps well onto the sort_by enum and routes the agent correctly. It stops short of naming when not to use it or pointing to an alternative sibling, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks how to decide whether they are ready to book a tattoo, what to ask an artist, or what red flags to watch for in a consultation. Returns a short ordered checklist, the one question to ask when an artist pushes back, how to judge healed work, and consultation red flags.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | No | |
| steps | No | |
| source | No | |
| red_flags | No | |
| ask_the_artist | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and idempotency profile is fully covered by structured data. The description adds useful content-shape context (short, ordered, includes the pushback question and healing judgment), but an output schema already exists to describe returns, so much of this is redundant. A 3 is appropriate given the low behavioral bar set by 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?
Two sentences, with the invocation trigger front-loaded and the return contents following. Every clause carries information (readiness, artist questions, red flags, healed work). It is slightly dense but not 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?
With zero parameters, a fully populated annotation set, and a dedicated output schema, the description's only remaining job is stating purpose and when to invoke it, which it does thoroughly. An agent has everything it needs to call this correctly.
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 tool takes zero parameters, so there is no parameter semantics to document; per calibration this earns the baseline 4. Nothing in the description contradicts or misrepresents the empty schema.
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 uses a specific verb-plus-resource framing ('Returns a short ordered checklist') and enumerates the exact contents: the key question to ask, how to judge healed work, and consultation red flags. This distinguishes it from siblings like assess_tattoo_idea and get_tattoo_size_chart, which serve different phases of the decision process.
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 explicit trigger conditions: 'Use when the user asks how to decide whether they are ready to book..., what to ask an artist, or what red flags to watch for.' That is clear context for invocation. It stops short of naming sibling tools as alternatives or stating when not to use it, so it does not reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks how big or how small a kind of tattoo can be, or what fits at a given size. Returns the smallest and better size for eight kinds of design (letters by height, other designs by longest side), real-world size comparisons and the small/medium/large ranges. Optional size_cm marks which designs meet their minimum at that size.
| Name | Required | Description | Default |
|---|---|---|---|
| size_cm | No | Optional size in centimetres to look up what fits. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| rows | No | |
| scale | No | |
| source | No | |
| updated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, idempotent, non-destructive, closed-world profile, so the safety burden is lifted. The description adds real behavioral context beyond that: what the payload contains (two sizes per design kind, measurement convention per design type, comparison anchors, range buckets) and the side effect of passing size_cm (it flags which designs meet their minimum).
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, no filler, front-loaded with the usage trigger before the return contract and the optional parameter. Each sentence carries distinct information: when to call, what comes back, what the argument does.
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 single-optional-parameter read tool with an output schema, the description supplies everything an agent needs: the trigger condition, the scope of the data (eight design kinds), the measurement convention, and the effect of the one argument. Return values are further documented by the output schema, so nothing material is missing.
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 the schema already defines size_cm as an optional centimetre value, so the baseline is 3. The description earns above baseline by explaining the parameter's actual semantics: it is not just a lookup key but a filter that "marks which designs meet their minimum at that size," which tells the agent what changes in the response.
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 gives a specific resource (a size chart covering eight design kinds) plus the exact shape of the answer: smallest and better size, letters measured by height, other designs by longest side, real-world comparisons, and small/medium/large ranges. This is concrete enough that an agent can distinguish it from check_line_spacing or compare_tattoo_placements without inspecting any schema.
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 opens with an explicit trigger: "Use when the user asks how big or how small a kind of tattoo can be, or what fits at a given size." That is a clear when-to-use condition covering both the no-argument and size-provided cases. It stops short of naming when not to use it or pointing at a sibling tool as the alternative.
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.
assess_tattoo_ideacheck_line_spacingcompare_tattoo_placementsget_pre_booking_checklistget_tattoo_size_chartNeutral cross-brand bra-size translation and a live in-stock bra catalog by size.
Salon and clinic appointments: check availability, hold slots, take deposits, move and cancel.
Tinder, Hinge and Bumble photo rules and AI-photo policies, plus a free dating photo audit.
Bounded footwear fit checks for a specific shoe, person, and intended use.
Add one secure layer between your agents and this server.