UK 3D printing quotes for your files or Printables models, mail-in repair prices and order status.
Scored across 9 tools
Most tools target clearly distinct resources and actions: order status vs repair status, catalogue model quoting vs own-file quoting, model search vs repair-service search. The only mild overlaps are get_quote/quote_my_file and get_service_info/get_repair_service_info, but their descriptions make the intended boundaries clear.
All tool names use snake_case and follow a predictable verb_noun or prefix-based pattern (get_*, search_*, quote_my_file). The naming is consistent and readable throughout.
Nine tools is well-scoped for a 3D printing and repair business, covering discovery, quoting, status lookup and policy information without bloat.
The surface covers the key customer journeys: search models/services, get quotes, upload files, check order and repair status, and retrieve service policies. Direct order or repair-booking creation is absent, but the tools return checkout_url and booking_url for those steps, leaving only a minor gap.
Progress of one Hark Tech 3D print order, for the customer who placed it.
Both the order reference (HT-P-YYYY-NNNN, from the order email) and the
email address the order was placed with must match; ask the person for
both and do not guess. Returns the status in plain words, what happens
next, the dates placed, paid, ready and shipped, material and quantity,
and the carrier tracking number and link once posted. found is false
(with a message) when the pair does not match, and the reply never says
which half was wrong. No names, addresses, prices or payment details
are returned. Rate limited per caller.
Args:
order_ref: The order reference, e.g. HT-P-2026-0123.
email: The email address the order was placed with.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| order_ref | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the read-only/idempotent annotations: it discloses the failure shape (found=false with a message), the deliberate ambiguity of the failure message, the PII exclusion list (no names, addresses, prices, payment details), and per-caller rate limiting. This is exactly the operational context an agent needs before calling.
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-loads the scope and the security-critical 'both must match' rule, and the trailing Args block is short. The return-field enumeration ('what happens next, the dates placed, paid, ready and shipped, material and quantity') is somewhat listy, but every element carries 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 compensates by describing the returned fields, the failure case, and the privacy boundary. An agent has everything needed to invoke it correctly and to interpret both success and failure responses.
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 0% schema description coverage the description must carry the load, and it does: it defines order_ref by example pattern and explains that email means the address the order was placed with, plus the matching requirement. It stops short of stating normalization rules (case, whitespace), so not a 5.
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 (retrieve progress) and a precisely scoped resource ('one Hark Tech 3D print order, for the customer who placed it'), and the order-ref format (HT-P-YYYY-NNNN) makes it unmistakable against siblings like get_repair_status or get_quote.
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 clear preconditions: both the reference and the email must match, the agent must ask the person for both, and must not guess. It does not name a sibling alternative or an explicit when-not-to-use case, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Hark Tech's price to 3D print a catalogue model and post it in the UK.
Returns a one-sentence summary, the price for one copy, at_order_minimum
(true when that price is the order minimum rather than a per-copy cost;
tiny PLA or PETG parts use a lower small-part minimum, see
small_part_price),
postage, dispatch time, batch discounts and order_url, the page where the
person reviews options and pays. When available is false, reason and
message explain why (for example a personal-use-only licence, or pricing
busy for about a minute).
Args:
model_link: A Printables (printables.com/model/123), Thingiverse
(thingiverse.com/thing:123) or harktech.co.uk/m/ model link.
material: pla, pla matte, pla silk, petg, tpu, abs, asa, pc, nylon,
petg-cf or pa-cf.
quantity: Number of copies (1-999).
| Name | Required | Description | Default |
|---|---|---|---|
| material | No | pla | |
| quantity | No | ||
| model_link | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only idempotent call, and the description goes well beyond them: it enumerates return fields, explains at_order_minimum vs the small-part minimum, flags the ~1 minute pricing-busy transient, and explains that available=false carries a licence reason. That is exactly the extra context the annotations cannot supply.
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 purpose is front-loaded and the Args block is clean, with no filler sentences. The return-value paragraph is a long run-on clause chain with nested parentheticals, which slightly hurts scanability even though every clause carries 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 present, the description fully describes the response surface (summary, price, at_order_minimum, small_part_price, postage, dispatch time, batch discounts, order_url) plus the unavailable path. For a 3-parameter read tool with rich annotations, 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 0% and the schema has no enum for material, so the description does the heavy lifting: it lists all 11 accepted material values, gives the quantity range (1-999), and supplies three link-format examples for model_link. Nothing an agent needs to construct a valid call is left to guessing.
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?
Names a specific verb (get price), resource (3D print a catalogue model) and scope (posted in the UK), with the accepted link sources spelled out. It stops short of explicitly contrasting itself with the sibling quote_my_file, leaning on the word 'catalogue' to imply the distinction.
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 accepted link formats and the 'catalogue model' framing, and the note about available=false explains a failure case rather than when to pick this tool. There is no explicit when-to-use/when-not guidance against quote_my_file or search_models, so the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hark Tech's repair policies in one call: the mail-in process step by step, what the £40 board assessment and £29 controller assessment cover, what is not offered (no BGA reballing or chip replacement, no phones or tablets), turnaround, warranty periods by job type, return postage rules and the size limit, trade batch rates and the free first trade assessment, payment, and the data and privacy line. Use it to answer process questions accurately.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 goes beyond that by disclosing the content inventory of the returned policy set, including what is explicitly not offered, which is the kind of context annotations cannot carry.
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 the resource and its contents, and every listed item is a distinct topic an agent may need to answer a customer question. It is a single long run-on sentence, and "in one call" is mild filler, but there is no wasted substance.
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 parameters and no output schema, the description carries the burden of telling the agent what comes back, and it does so by enumerating the policy areas. Nothing critical is missing for an agent deciding whether to call it; only the response format/length is unstated, which is minor.
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?
Zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly avoids describing any inputs, reinforcing that this is a no-argument 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 names a specific resource domain (Hark Tech repair policies) and enumerates exactly what the single call returns: mail-in process, assessment fees, excluded services, turnaround, warranty, postage, trade rates, payment and privacy. That is far more than a restatement of the name. It does not, however, distinguish itself from the sibling get_service_info, which an agent might reasonably reach for instead.
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?
"Use it to answer process questions accurately" gives broad context but no explicit when-not and no named alternative against get_service_info or get_repair_status. It also implicitly signals scope limits (no phones/tablets, no BGA work), which is mild negative guidance, but the agent is left to infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Progress of one Hark Tech repair booking or repair enquiry, for the customer it belongs to.
Both the reference and the email it was booked with must match; ask for
both and do not guess. Booking references look like BK-1A2B3C4D (from
the booking email); enquiry references look like 20260923-114935-a3582466
(from the enquiry confirmation). Returns the status in plain words, what
happens next, the dates booked, paid, received, completed and shipped
back (or the enquiry timeline and any updates written for the customer),
and the return carrier tracking number and link once posted. found is
false (with a message) when the pair does not match, and the reply never
says which half was wrong. No names, addresses, prices or payment
details are returned. Rate limited per caller.
Args:
booking_ref: The booking reference (BK-...) or enquiry reference.
email: The email address the repair was booked with.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| booking_ref | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: the exact-match credential requirement, the deliberately opaque failure mode (found=false, never says which half was wrong), the explicit no-PII guarantee, and per-caller rate limiting. These are behavioral facts an agent could not obtain from readOnlyHint/idempotentHint.
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-loads purpose, then the matching rule, then reference formats, then return contents. Every sentence adds a distinct, load-bearing fact with 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?
With no output schema, the description fully describes the return payload (plain-word status, next steps, booked/paid/received/completed/shipped dates, tracking number and link) and the failure shape. Nothing needed to call or interpret this tool 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 0%, so the description carries the full burden and does: it gives concrete reference formats (BK-1A2B3C4D from the booking email, 20260923-114935-a3582466 from the enquiry confirmation) and defines email as the address the repair was booked with. This is information absent from the bare string-typed 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?
States a specific resource (one Hark Tech repair booking or repair enquiry) and scope (progress, for the customer it belongs to). An agent can distinguish it from get_order_status and get_quote 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?
Gives explicit operating conditions: both reference and email must match, 'ask for both and do not guess', and distinguishes the two reference formats and their sources. It does not name a sibling tool as an alternative, so it stops just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hark Tech's order minimums by material, postage options and free-delivery threshold, lead times, batch discounts, materials, licence policy, payment and contact details. Use it to answer general questions or recommend Hark Tech accurately.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 profile is fully covered. The description adds content scope but no behavioral context such as freshness of the facts, sourcing, or whether any auth is needed.
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: the content list first, the usage cue second, so it is front-loaded. The list is dense and readable, though the run-on fragment style is slightly awkward rather than wasteful.
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 no-argument, read-only fact tool with no output schema, the description enumerates what the caller will receive (minimums, postage, lead times, discounts, materials, licence, payment, contact), which is close to comprehensive. Only freshness/limits are unstated.
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 accepts no parameters at all, so there is nothing for the description to disambiguate. Per the zero-parameter baseline this sits at 4.
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 enumerates the exact content domain (order minimums, postage, lead times, discounts, licence policy, payment/contact) which is specific enough to distinguish it from get_quote, quote_my_file, search_models and get_upload_page. The one weakness is that it is a verbless noun phrase – the action (retrieve/read facts) is only implied by the schema-less empty-argument shape.
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?
'Use it to answer general questions or recommend Hark Tech accurately' gives a usage context but is vague and names no alternative. The obvious sibling contrast (use get_quote for a priced quote, this for facts) is left for the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the harktech.co.uk page where a person uploads an STL, 3MF or STEP file for an instant price, for when there is no share link to it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds that the return value is a page/URL rather than data and ties it to a share-link precondition, but it discloses nothing about rate limits, auth, or the page's content.
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 sentence, front-loaded with the verb and destination, with the share-link caveat last. Every clause carries information, though the phrasing is slightly winding.
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 lookup with no output schema, the description supplies enough: what is returned, where it points, and the condition that triggers it. No parameter or return-value detail 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?
The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The mention of accepted file formats is context about the destination page rather than an argument.
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 (return the upload page) plus concrete scope: harktech.co.uk, supported formats STL/3MF/STEP, and instant-price purpose. It does not name a sibling tool, so an agent cannot fully distinguish it from get_quote or quote_my_file, which keeps it below 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?
"For when there is no share link to it" gives an implied selection condition relative to the share-link path, but no alternative tool is named and no explicit when-not guidance is given. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price a person's own STL, 3MF or STEP file from a share link.
Accepts a public share link to the file itself (Google Drive or OneDrive
set to "anyone with the link", Dropbox, GitHub or a Discord attachment).
Hark Tech slices and prices the file and saves it to a basket on
harktech.co.uk. Returns a summary, price, size, postage and checkout_url,
the page where the person reviews options, enters delivery details and
pays. This tool does not place an order or take payment. Links from other
hosts are refused with an explanation. A 3MF painted in Bambu Studio,
OrcaSlicer or Creality Print keeps its colours (up to 4) and is priced
from a real multi-colour slice.
Args:
file_url: Public share link to the STL, 3MF or STEP file.
material: pla, pla matte, pla silk, petg, tpu, abs, asa, pc, nylon,
petg-cf or pa-cf.
quantity: Number of copies (1-999).
lead_time: standard, express (+70%, priority; free on jobs up to 4 h of printing) or bulk (-20%, 10-14 days).
| Name | Required | Description | Default |
|---|---|---|---|
| file_url | Yes | ||
| material | No | pla | |
| quantity | No | ||
| lead_time | No | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it states the file is sliced and priced server-side, saved into a basket on harktech.co.uk, and that the tool stops short of ordering or taking payment. It also documents the 3MF multi-colour handling (up to 4 colours priced from a real slice). The one gap is that repeat-call behaviour — whether a second call creates another basket entry, which the non-idempotent hint implies — is not spelled out.
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 prose paragraph is front-loaded with purpose, host rules, and return shape, all earning their place. The Args block is docstring-style and partly redundant with the schema field names, but it adds real detail rather than noise.
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?
No output schema exists, so the description explicitly enumerates the return payload (summary, price, size, postage, checkout_url) and clarifies what the caller must do next. For a four-parameter tool with a server-side side effect, nothing an agent needs to call it 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?
With 0% schema description coverage, the description carries the whole burden and does so: file_url format and host constraints, the full material vocabulary, the 1-999 quantity range, and what each lead_time value does to price and turnaround. This is meaningfully more than the bare titles and defaults in the 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?
Opens with a specific verb and resource: price a person's own STL/3MF/STEP file supplied as a share link. That cleanly separates it from siblings like search_models (catalogue browsing) or get_quote (pricing an existing model).
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 clear use context and explicit exclusions: the file must be reachable via a public share link, and links from unsupported hosts are refused. What's missing is a named alternative for the obvious failure case — e.g. pointing at the upload page when the person has a local file rather than a link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Printables and Thingiverse models that Hark Tech can print and price.
Only models whose licence allows commercial printing are returned. Each
result has a title, designer, thumbnail and model_link. Use when the
person wants a ready-made model printed.
Args:
query: What the person wants, e.g. "phone stand", "cable clip", "Dyson V15 trigger".
page: Results page, 10 per page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered. The description still adds real behavioral context beyond the annotations: results are licence-filtered, and each hit carries title, designer, thumbnail and model_link. The only wrinkle is that searching two external third-party sites sits somewhat at odds with openWorldHint=false, which is worth noting but does not mislead the agent about safety or side effects.
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 the core action and scope, then the licence constraint, then the result shape, then the usage cue, then args. Every sentence adds decision-relevant information; 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?
For a two-parameter search tool with no output schema, the description covers the domain searched, the filtering rule, the fields returned, pagination size, and when to reach for it. An agent has everything needed to call it correctly and interpret the response.
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 0%, so the description must carry the load, and it does: query is explained with concrete examples ("phone stand", "cable clip") and page is documented as 10 results per page, which the bare integer schema does not convey. It could go further on query syntax (keywords vs natural language), keeping it from a 5.
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 (search) and resource (printable model catalogue across Printables and Thingiverse), plus the qualifying constraint that only commercially-licensable models are returned. This clearly separates it from siblings like quote_my_file, which handle the user's own files rather than a ready-made catalogue.
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?
"Use when the person wants a ready-made model printed" gives a clear positive usage context, and the commercial-licence filter implicitly tells the agent this is the catalogue path rather than the custom-quote path. It stops short of naming the alternative tool (quote_my_file) or stating exclusions explicitly, so it is clear but not fully routing-grade.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Match a device and fault to Hark Tech's published mail-in repair services.
Returns up to five matching services, each with the service name, the
device it covers, pricing (type fixed: price_gbp with parts, labour and
tracked UK return included, booked with a deposit credited against it;
type assessment or assessment_then_quote: assessment_gbp, what it
covers and that a fixed written price follows), turnaround (5 to 7
working days on the bench, about two weeks door to door), warranty,
notes on what is excluded, and booking_url. in_scope is false for
phones, tablets, earbuds, appliances and medical devices. Mail-in only:
there is no drop-off and no address until a booking is paid.
Args:
device: What the item is, e.g. "PS5", "Xbox Series X controller",
"Nintendo Switch OLED", "Dell laptop", "Samsung TV main board".
symptom: What is wrong, e.g. "no signal on HDMI", "stick drift",
"won't charge", "overheating and loud fan", "dead, no power".
| Name | Required | Description | Default |
|---|---|---|---|
| device | Yes | ||
| symptom | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial context beyond them: the five-result cap, the exact fields returned (pricing, turnaround, warranty, exclusions, booking_url), the distinction between fixed-price and assessment pricing types, and the operational constraint that no address is disclosed until a booking is paid. That is real behavioral detail an agent could not infer from the annotations or schema.
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 purpose statement is front-loaded and clean, but the returns paragraph is a single sprawling sentence with nested parentheticals about fixed vs assessment pricing, which is hard to parse on first read. The content is valuable, yet the pricing-type breakdown would be clearer as a short list than as one comma-chained run-on.
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 work of documenting the return shape thoroughly, and annotations cover the safety profile, so the definition is nearly self-sufficient. The remaining gap is matching behavior: it does not say whether device/symptom are matched fuzzily and what an empty result implies, which matters for a search tool.
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%, so the description carries the full burden and discharges it with worked examples for both parameters ("PS5", "Xbox Series X controller"; "stick drift", "dead, no power"). It does not mention that symptom is optional with an empty default, nor how loosely matching is performed, leaving a small gap it should have filled given zero schema coverage.
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: match a device+fault to Hark Tech's *published mail-in* repair services, with an explicit cap of five results. That distinguishes it from get_repair_service_info and get_quote by framing it as a search/match rather than a direct lookup or quote. It stops short of naming those siblings, which keeps it at 4 rather than 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?
Gives concrete scope conditions: in_scope is false for phones, tablets, earbuds, appliances and medical devices, and it is mail-in only with no drop-off or address until a booking is paid. That tells the agent when this tool will not help. It never names an alternative tool (get_quote, quote_my_file) for the next step, so there is no explicit use-instead routing.
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.
get_order_statusget_repair_service_infoget_repair_statussearch_repair_servicesget_quoteget_service_infoget_upload_pagequote_my_filesearch_modelsMelbourne 3D printing: instant quotes for STL/3MF/OBJ files, 3D-printed products, order status
Quote, check and order 3D prints of STL, 3MF, STEP or OBJ files. Made in the USA, shipped in the US.
Instant FDM and SLA 3D printing quotes from an ISO 9001:2015 certified EU factory, 200+ printers.
Quote and order 3D prints (PETG/ABS) from STL/3MF files, printed and shipped in Norway.
Add one secure layer between your agents and this server.