Print and Vector QA

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavior — the report is free/built-in and performs no artwork analysis — but the phrase 'never pays' is ambiguous (no cost to caller vs. no payout) and nothing is said about whether the sample is static fixture data or tied to a real account.

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 tight sentences with the core constraint ('does not analyze your artwork') front-loaded after the resource. The trailing 'never pays' is vague enough that it spends words without fully earning them, but overall there is no 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?

This is a simple single-parameter read-only tool with no output schema, so the bar is low. Still, an agent cannot tell from the description whether the returned sample is identical regardless of account, how it differs from a real prepare_* report, or what the enum values refer to — details that matter for deciding to call it.

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 0% for the single required 'service' parameter, so the description must carry the meaning, yet it only says 'for one service.' It never explains that the value selects which sample report to return or that valid values correspond to the services listed by list_print_qa_services, leaving the enum to speak for itself.

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 identifies the resource as a 'free built-in sample report for one service,' which pairs with the tool name to convey retrieval of a demo report. It lacks an explicit verb ('returns/get') and never states that the report is static/illustrative sample data rather than real analysis output, leaving the core purpose only implied.

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 clause 'Does not analyze your artwork' implicitly tells the agent this is not a substitute for the prepare_* siblings, which is useful when-not guidance. However, it never names those alternatives or states the positive condition for calling it (e.g., 'use to preview report format before running prepare_preflight').

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

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

Annotations already establish readOnlyHint and closed-world, so safety is covered; the description adds two things the annotations cannot: there is no payment/cost barrier, and the returned entries carry prices, input specs, limits and sample URLs. That content disclosure matters because no output schema exists. It does not say whether the catalog is static or how many calls the sample URLs imply, which is minor for a zero-param list.

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 short fragments, front-loaded with the resource and its contents, closed by the single most decision-relevant fact ('No payment'). Nothing is redundant with the name or the schema.

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 zero-parameter, read-only catalog with no output schema, the description covers what the tool is, what comes back, and that it is free. The only omission is the follow-up path—how to go from a listed entry to actually invoking that service via the sibling tools—which would make it fully self-sufficient.

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 no parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. It correctly avoids inventing filtering options the empty schema would reject.

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 the resource precisely: a catalog of seven print and vector QA APIs, and names what each entry contains (prices, inputs, limits, sample URLs). The noun phrase 'Free catalog' plus the explicit 'seven' makes the scope unmistakable and distinguishes it from the prepare_* action siblings. It stops short of a leading verb like 'Lists', so the read is inferred from 'catalog' rather than stated.

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: an agent can infer this is the discovery step before picking one of the QA services, but the description never says 'call this first to choose an API' nor points at get_print_qa_sample for retrieving an actual sample. No when-not-to-use guidance or alternatives are named.

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

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

Beyond the read-only and closed-world annotations, it discloses the price, currency and network, and explicitly states that the tool does not analyze, sign or charge. It also describes the preparation outputs and adds downstream result characteristics—witness points, a conservative bound and a completeness caveat—though the source of those analysis results could be stated more clearly.

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 compact and devotes its sentences to the goal, payment model, execution boundary and outputs without filler. Its structure could be clearer: the opening implies direct measurement, the second “Returns” has an ambiguous subject, and “check completeness” is terse and unexplained.

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 three-input request-preparation tool with no output schema, it covers most of what an agent needs: purpose, cost, non-execution behavior and returned request material. Remaining gaps are the threshold semantics, whether witness points and the bound come from the downstream HTTP service, and what specific completeness field or condition the agent should check.

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 schema already documents a and b as 2–4 millimeter coordinate pairs, while the description adds the useful context that they represent two curves. It does not explain thresholdMm’s role, such as whether it is a pass/fail clearance requirement, a reporting cutoff or a search limit, leaving one required parameter under-specified.

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?

Identifies the specific job—measuring clearance between two curves for engraving or printing—and then clarifies that this tool prepares the paid HTTP request rather than performing the measurement. This distinguishes it from general preflight and vector-health siblings, although the opening “Measure the gap” wording briefly overstates what the MCP tool itself does.

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?

“Before engraving or printing” provides a concrete use context, and the preparation-only disclosure tells the agent not to expect immediate analysis or payment execution. It does not explicitly contrast alternatives such as prepare_small_features or prepare_preflight, nor explain when curve clearance is the appropriate check.

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

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

Annotations cover only readOnlyHint and openWorldHint, and the description adds substantial context beyond them: the 0.05 USDC cost on Base, the fact that it does not analyze, sign, or charge, and what it returns. These are exactly the behavioral facts an agent needs before committing to a paid flow. It stops short of explaining what the returned payment instructions look like.

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?

Five short sentences with the risk-finding purpose front-loaded and the payment/behavioral caveats grouped after it. The opening 'Find open contours and self-intersections' reads like analysis and is only negated two sentences later, creating mild internal friction.

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 payment-preparation wrapper with no output schema, the description does explain the return payload and cost, which is the right focus. It leaves the entire input contract unexplained, which is a real gap for a tool with four required, zero-documented parameters.

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 0% for four required parameters (paths, minSegmentMm, nearNodeMm, closeGapMm), and the description never mentions any of them. Only the vague phrase 'supplied input' hints that caller data is echoed back, leaving thresholds and path structure entirely undocumented.

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 specific operations (open contours, self-intersections) and the concrete deliverable (a paid HTTP request, canonical endpoint, payment instructions), so the agent knows what it produces. It never names or contrasts the sibling prepare_* tools, so differentiation is left implicit.

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 phrase 'before cutting' supplies a usage window and 'not CNC certification' sets a boundary on interpretation. There is no explicit when-not guidance or routing to alternatives such as prepare_curve_clearance, so the agent must infer which prepare_* tool applies.

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

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

Beyond the light annotations (readOnlyHint, openWorldHint=false), the description discloses pricing (0.08 USDC on Base), explicitly disclaims performing analysis, signing or charging, describes the return payload (canonical endpoint, supplied input, payment instructions), and notes validation behavior (preserves native curves, rejects unsupported constructs and EPS transforms). This is a rich behavioral profile for a preparation tool.

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?

Four compact sentences front-load purpose, then cost, then non-actions, then behavioral constraints, with no filler. The one weakness is the leading 'Inspect', which is slightly at odds with the later disclaimer that no analysis is performed.

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 appropriately explains what the tool returns and what it does not do, and it covers cost and input validation. The main omission is any explanation of the 'minSegmentMm' parameter, which an agent would need in order to supply it 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?

Schema coverage is only 33%, and the description provides no guidance for the undocumented parameters. The 'format' enum is only obliquely referenced via 'SVG or restricted CorelDRAW EPS', and 'minSegmentMm' is completely unexplained in both schema and description despite being a numeric constraint on analysis granularity.

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 ('Prepare a paid HTTP request') and resource scope ('original SVG or restricted CorelDRAW EPS curve commands'), and it distinguishes itself from the sibling prepare_vector_health by emphasizing native Bezier curves and rejection of EPS transforms. The opening verb 'Inspect' slightly muddies the purpose, since the tool explicitly does not perform inspection or analysis, but the rest of the sentence clarifies it.

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 through input constraints ('original SVG or restricted CorelDRAW EPS', 'rejects unsupported constructs and EPS transforms'), giving an agent a reasonable sense of when this tool applies. However, it never names the alternative sibling prepare_vector_health or states explicitly when to choose one over the other, 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.

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

Beyond readOnlyHint/openWorldHint, the description discloses that no analysis, signing, or charging occurs here, that the price is 0.02 USDC on Base, and that results are heuristic rather than certification. That is meaningful context an agent cannot get from the annotations. The only shortfall is that it does not describe how the payment step is executed after the prepare call.

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?

Purpose is front-loaded in the first sentence, followed by cost, scope disclaimers, and return contents in a compact telegraphic style. Every sentence carries information, though the clustered negation list ('does not perform analysis, sign or charge') reads slightly terse.

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 prepare step with no output schema, the description compensates by naming what is returned (canonical endpoint, supplied input, payment instructions) and by bounding expectations with the heuristic caveat. It is nearly complete; only the handoff mechanics after receiving payment instructions are left implicit.

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?

With a single parameter and 100% schema description coverage, the schema already carries the constraints (UTF-8, 128 KiB cap, no DTD). The description adds only the phrase 'supplied input', which echoes the schema rather than extending it. 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 states a concrete verb and resource — 'Find artwork risks before sending SVG to print' — and names the specific risk categories it flags (raster, live text, RGB, effects, open paths). It does not differentiate itself from closely named siblings such as prepare_printcheck or prepare_vector_health, so an agent must infer the split from the tool name alone.

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 rather than stated: the agent can infer this is the first step of a paid two-phase flow (prepare here, then call the returned endpoint). There is no explicit 'use this when…, use sibling X when…' routing, and no prerequisite guidance beyond the cost note.

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

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

Annotations only declare readOnlyHint=true and openWorldHint=false; the description goes further by disclosing a paid call (0.05 USDC on Base), that it does not sign or charge, and that it returns the canonical endpoint plus payment instructions. That is meaningful context an agent cannot get from annotations and is consistent with readOnlyHint. It stops short of describing failure modes or what happens if payment is declined.

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 short and front-loads the core action, but the sentences are choppy and out of order: 'Measures sampled ink geometry' arrives after the return-value sentence and reads as an afterthought. The 'does not perform analysis, sign or charge' clause is efficient, but the opening 'Check whether...' followed by 'does not perform analysis' costs a re-read.

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 usefully states what is returned (canonical endpoint, supplied input, payment instructions), which is a real strength. But for a 5-parameter tool with a nested object and zero schema coverage, the input side is severely under-explained, and there is no mention of what the downstream endpoint expects. Complete on the output/payment side, incomplete on the input side.

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 0% across 5 parameters, including a nested 'conditions' object, so the description carries the full burden and does not meet it. 'Measures sampled ink geometry' loosely hints that rows are sample points, but nothing explains the format of 'rows', the units or bounds rationale for widthMm/heightMm, the accepted 'method' values, or the structure of 'conditions'. An agent would have to guess at the input contract.

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 verb and resource (prepare a paid HTTP request for a print-check geometry evaluation) and scopes it with 'Not a PDF/CDR importer', which separates it from importer-type tools. It also clarifies it 'does not perform analysis', resolving the tension with the opening 'Check whether sampled details are too fine'. It does not explicitly distinguish itself from the many prepare_* siblings (prepare_preflight, prepare_small_features), which keeps it below a 5.

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 negative guidance ('Not a PDF/CDR importer') and the note that it prepares rather than analyzes imply the usage context. However, there is no explicit statement of when to choose this over prepare_small_features or prepare_preflight, which are the closest siblings given the 'too fine' phrasing. Usage is inferable but not stated.

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

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

Strong disclosure beyond the annotations: the exact cost (0.03 USDC on Base), the explicit statement that this tool does not analyze, sign, or charge, and an enumeration of what is returned (endpoint, echoed input, payment instructions). This is exactly the kind of side-effect clarification readOnlyHint/openWorldHint cannot convey. It stops short of describing failure modes or what the caller must do with the returned endpoint.

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?

Purpose is front-loaded in the first sentence, with cost and non-execution caveats following in a logical order. Sentences are short and mostly earn their place, though the 'does not perform analysis, sign or charge' clause overlaps with the 'Returns the canonical endpoint' sentence.

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 three-parameter, no-output-schema prep tool, the description covers the payment model, the non-execution guarantee, and the return payload well. It is incomplete on the input contract — the shape/hole geometry and threshold semantics — which is the main thing an agent needs to call it 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?

Schema description coverage is 0% for three required parameters, and the description only gestures at them with 'Checks object and hole dimensions' and 'no SVG or curve import.' It never explains the shapes array structure, point format, units, or how minWidthMm/minHeightMm are compared against geometry, so it fails to compensate for the schema 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 states a specific verb and object ('Find tiny polygon objects and holes') and scopes it to pre-production checks, plus it draws a boundary ('no SVG or curve import') that helps separate it from prepare_curve_clearance and prepare_vector_health. It does not name those siblings explicitly, so classification still requires a small 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?

'before production' gives a timing cue, and the exclusion of SVG/curve input implies which sibling to pick instead. However, no alternative tool is named and no prerequisite or when-not condition is spelled out beyond that one negative clause.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent with them ('does not perform analysis, sign or charge'). Beyond the annotations it adds substantive context: cost (0.05 USDC on Base), the fact that no signing or charging occurs, and the exact return contents (canonical endpoint, supplied input, payment instructions). It does not say anything about request expiry or how to actually settle payment, which keeps it below 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?

Four short sentences, front-loaded with the analysis purpose followed by payment and scope constraints, with no filler. Each sentence carries distinct information (capability, cost, non-action, subtype restriction). Slightly more compact phrasing could fold the payment and 'does not sign or charge' statements together.

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, and the description usefully enumerates what is returned, so the return side is adequately covered. The main gap is the four undocumented numeric parameters, which are central to this tool's correctness. For a prepare-only tool with safety annotations, the flow explanation is good, but parameter meaning remains incomplete.

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 0% for the four required parameters, so the description must carry the burden, and it largely does not. The phrases 'duplicate nodes' and 'short edges' loosely hint at nearNodeMm and minSegmentMm, and the 'Mm' suffix implies millimetre units, but closeGapMm is never explained and no threshold semantics or valid ranges are given. An agent still has to guess what each numeric threshold controls.

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+resource ('Find duplicate nodes and short edges in prepared vector paths') and adds a scoping clause ('Checks explicit polylines, not unconverted curved artwork') that implicitly separates it from the sibling prepare_native_vector_health. It also makes clear the tool only prepares a request rather than running the analysis, so an agent can tell what it does. It never names the native sibling outright, so the differentiation is inferential rather than explicit.

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 makes the two-step flow clear: this tool does not perform analysis, sign or charge, but returns the canonical endpoint and payment instructions, which tells the agent this is a preparatory step in a paid HTTP workflow. The 'explicit polylines, not unconverted curved artwork' clause gives a negative condition for when not to use it. It stops short of explicitly naming sibling alternatives for those excluded cases.

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