Packaging dielines (FEFCO/ECMA), 3D box and bag mockups, and your Drint projects in the chat.
Scored across 10 tools
Most tools target clearly different objects (dielines, mockups, projects, inbox, account). The only real overlap is get_dieline vs make_dieline, which both draw a dieline at a size and return a link, but the descriptions explicitly split them by output format (PDF/AI/SVG vs DXF/CF2) and each cross-references the other. open_mockup vs open_my_project are also close but clearly scoped to library models vs the user's own projects.
Strong verb_noun pattern throughout: get_dieline, list_dielines, list_my_projects, make_dieline, open_mockup, open_my_project, search_mockups, send_to_3d_studio. Deviations are minor: 'my_drint' is a bare noun and 'review_inbox' reads as a noun phrase rather than a verb+object. Still predictable and readable overall.
Ten tools is well within the sweet spot for this surface. Each tool maps to a distinct capability (list/get/make dieline, list/open project, search/open mockup, account state, review inbox, 3D Studio handoff) and none feels redundant or padded.
Coverage is good for the stated purpose: dieline discovery, generation in both print and production formats, mockup search/preview, project listing/preview, plan/account info and inbox review. Gaps exist that agents cannot work around in-tool: no project creation or editing, no artwork upload, and no way to accept review results (deferred to Drint by design). These are minor for a companion app that links users back into the studio.
Draw a print-ready dieline at an exact size in the signed-in person's Drint space and return a download link (valid one hour): PDF / AI (cut and crease as spot colours with dimensions, opens in Illustrator) or SVG (CUT / CREASE layers). Give a standard code (FEFCO "0201", "0427"; ECMA "A20.20.03.01", "A60.20.00.01") or a Drint type id from list_dielines. Length, width, height are the inside size in mm. The Free plan has 3 of these a month, Pro unlimited. For the die-maker's DXF or CF2 files use make_dieline.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | A FEFCO or ECMA code, e.g. "0201", "FEFCO 0427", "A20.20.03.01". Give this or type. | |
| lang | No | The user's language (vi, en, th, zh…). Default en. | |
| name | No | A short file name, e.g. the product. Optional. | |
| type | No | A Drint type id from list_dielines, e.g. "rte", "bag", "pillow". Give this or code. | |
| format | No | Default pdf. | |
| width_mm | No | ||
| height_mm | No | ||
| length_mm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is not read-only, not idempotent, and not destructive. The description adds valuable behavior beyond that: it creates output in the signed-in Drint space, returns a one-hour download link, explains PDF/AI spot-colour and SVG layer handling, and states plan limits.
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 paragraph is front-loaded with the action and return value, then adds formats, code/type selection, dimensions, quota, and the make_dieline alternative. It is dense but every sentence carries useful 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?
For an 8-parameter tool with no output schema, the description covers the return value, format details, dimensions, and the most important sibling alternative. It still leaves requiredness ambiguous because no parameters are marked required, and it does not explain name or lang.
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 description adds meaning for key parameters: code examples (FEFCO/ECMA), type ids from list_dielines, and that length, width, and height are inside dimensions in mm. However, schema coverage is only 63%, name and lang are not addressed, and the description mentions AI output while the format enum only allows pdf or svg.
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 resource: draw a print-ready dieline at an exact size and return a download link. It distinguishes the tool from make_dieline by pointing die-maker DXF/CF2 requests there, and from list_dielines by using that sibling only for type ids.
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 explicitly says to give a standard FEFCO/ECMA code or a Drint type id from list_dielines, and it routes die-maker DXF/CF2 work to make_dieline. It also clarifies the Free plan quota versus Pro unlimited usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the packaging structures Drint draws as print-ready dielines (tuck end boxes, auto-lock bottoms, mailers, FEFCO cartons, paper bags, rigid boxes, drawers, pillow boxes, sleeves, pouches, cups, labels…), with each one's type id and default size in mm, and find standard die codes: about 180 FEFCO (corrugated, e.g. 0201, 0427) and ECMA (folding cartons, e.g. A20.20.03.01) codes. Optional query: a code or a few words ("0201", "reverse tuck", "crash lock", "hộp nắp gài", "bag"). Each comes with a link that starts a Drint design on that die.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | The user's language (vi, en, th, zh…). Default en. | |
| query | No | A few words, English or Vietnamese. Empty: all of them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the description is not obliged to restate safety. It does add real value beyond them: the result payload (type id, default size in mm), the scale of the die-code catalog (~180 FEFCO plus ECMA), and the actionable link that starts a Drint design on that die.
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 core statement is front-loaded, but the first sentence is overstuffed with a fourteen-item parenthetical catalog list that pads length. It earns partial credit because those keywords help match user vocabulary, yet the sentence sprawls well past what an agent needs to select the tool.
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-optional-parameter read-only list tool with no output schema, the description covers the essential unknowns: what is returned (ids, sizes in mm), what the catalog contains (FEFCO/ECMA codes), and that results carry a design-start link. Only the absence of any mention of result limits or truncation on a ~180+ item catalog keeps it from a 5.
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 giving concrete query strings agents and users actually type ('0201', 'reverse tuck', 'crash lock', 'hộp nắp gài', 'bag'), which clarifies that code lookup and natural-language structure search are the same field.
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 resource — listing the packaging structures Drint produces as print-ready dielines — and enumerates the catalog domain (FEFCO, ECMA, boxes, bags, pouches, labels). It is clearly a catalog list/search rather than a fetch-one or create operation, though it never names siblings like get_dieline or make_dieline to sharpen 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 rather than stated: 'Optional query: a code or a few words' tells the agent the tool doubles as a search, and the empty-query behavior (return everything) is implied by the schema. There is no explicit guidance on when to use this versus get_dieline for a single lookup or make_dieline to actually create one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the signed-in person's own Drint projects (in the space they allowed this app to use): name, products, last change, and their thumbnails in a grid they can click to open in 3D. Optional query: words of the name.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | The user's language (vi, en, th, zh…). Default en. | |
| limit | No | Default 12. | |
| query | No | Words of the project name. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful context about the visibility scope ('the space they allowed this app to use') and the returned grid of names, products, last change and clickable thumbnails, but says nothing about pagination behavior, the default/max page size, or what an empty result looks 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?
One dense sentence with the ownership scope front-loaded and the return contents trailing; every clause carries information. It is slightly run-on when it describes the clickable 3D grid, but nothing is wasted.
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 enumerates the returned fields and the click-through behavior, and it states the access scope. What it lacks is paging/limit guidance for a tool that defaults to 12 and caps at 40, which an agent needs to retrieve all projects.
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 lang, limit and query are already documented with defaults and bounds. The description's 'Optional query: words of the name' merely restates the schema and omits the default limit of 12 and the maximum of 40.
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 verb and resource ('List the signed-in person's own Drint projects') and scopes it to the app-permitted space, which separates it from list_dielines and search_mockups. It stops short of naming a sibling directly, so an agent must infer the boundary rather than read 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 only implied: 'the signed-in person's own projects' signals the use case, and 'Optional query: words of the name' hints at the filtering path. There is no explicit when-to-use/when-not or pointer to a sibling for broader project searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a production dieline in the signed-in person's Drint space at an exact size and return a download link (valid one hour): DXF (for CAD and cutting tables) or CF2 (for die-makers, ArtiosCAD). Give a FEFCO / ECMA code or a type from list_dielines. Length, width, height are the inside size in mm. It counts as one die download on the space's plan, as in the Drint studio (Free has none: then it says so; the PDF / SVG die is get_dieline).
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | A FEFCO or ECMA code, e.g. "0201", "A20.20.03.01". Give this or type. | |
| lang | No | The user's language (vi, en, th, zh…). Default en. | |
| name | No | A short file name, e.g. the product. Optional. | |
| type | No | The structure's type id from list_dielines, e.g. "rte", "rsc", "bag". Give this or code. | |
| format | No | Default dxf. (pdf: counted as get_dieline's.) | |
| width_mm | No | ||
| height_mm | No | ||
| length_mm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic profile (not read-only, not idempotent, not destructive), but the description adds real behavior: the returned link expires in one hour, the call consumes one die download against the space's plan quota, and Free plans error out. Only the non-idempotent/one-download-per-call cost is hinted at rather than stated plainly, but the quota and expiry disclosure is exactly the value 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?
Purpose and deliverables are front-loaded in the first sentence; nothing is filler. The final parenthesis chains three separate caveats (quota, Free plan, PDF/SVG routing) into one run-on clause, which costs some readability.
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 eight optional parameters and no output schema, the description correctly covers the return value (hour-limited download link) and the code-or-type requirement. It does not say what happens if no dimensions are supplied, despite all three size params being optional — the one remaining ambiguity for a zero-required-parameter 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 coverage is 63%, and the description fills the biggest gaps: length/width/height are the *inside* size in mm (the schema has bare numeric bounds with no description), and it explains what DXF vs CF2 mean ('for CAD and cutting tables' vs 'for die-makers, ArtiosCAD'). It also clarifies that format 'pdf' is really counted as get_dieline's call, which the enum alone does not convey.
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 ('Draw a production dieline ... at an exact size') plus the concrete outputs (DXF/CF2 download link). It explicitly separates itself from get_dieline, which handles the PDF/SVG die, so an agent can pick the right tool without opening a 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 the input prerequisites (a FEFCO/ECMA code or a type id from list_dielines) and names the alternative tool for the PDF/SVG case. It also flags the plan gate — Free spaces have no downloads, 'then it says so' — which tells the agent when the call will fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who is signed in to Drint, which space this app works in, its plan, and how many PDF / SVG dies and DXF / CF2 die downloads are left this month. Useful when a Drint tool reports a plan limit.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | The user's language (vi, en, th, zh…). Default en. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds valuable behavioral context by enumerating the account and quota information returned and linking it to plan-limit errors, though it does not discuss auth requirements or the exact response shape.
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 tight sentences: the first front-loads all returned information, and the second gives the primary use case. 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?
For a simple read-only tool with one optional parameter and no output schema, the description is largely complete because it enumerates the returned account, space, plan, and quota fields. It could be slightly richer about the response format or exact quota units, but no critical gap would prevent correct invocation.
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 optional lang parameter is fully documented in the schema. The description adds no parameter-specific meaning beyond that baseline, which is acceptable given the schema already does the work.
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 precisely what the tool returns: signed-in identity, workspace/space, plan, and remaining monthly die/download quotas. This is a specific resource with clear fields, and it is obviously distinct from the sibling tools for dielines, mockups, projects, and inboxes.
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 concrete usage trigger: when another Drint tool reports a plan limit. That is clear context for when to call it, though it does not explicitly mention alternatives or when not to use it (for example, for general account lookup outside a quota error).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show one Drint mockup in an interactive 3D viewer the user can rotate, zoom, recolour and resize. Take the id from search_mockups. Optional: colour (a colour or material name, or its number from 0), and a custom size in millimetres (length, width, height).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The model id from search_mockups, e.g. "gift-ceramic-30". | |
| lang | No | The user's language (vi, en, th, zh…). Default en. | |
| colour | No | A colour / material name the model offers, or its number (0 = first). | |
| width_mm | No | ||
| height_mm | No | ||
| length_mm | 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 profile is covered. The description adds that the viewer is interactive and supports rotate/zoom/recolour/resize, but it does not clarify whether recolour/resize changes persist or describe the return behavior.
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 sentences, front-loaded with the action and resource, followed by id-source and optional-input details. Every sentence earns its place and there is no filler.
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 and only 50% parameter description coverage, the definition needs to carry more explanatory weight. It describes the viewer and optional colour/size inputs, but never mentions lang and leaves persistence/return behavior ambiguous.
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%: id, lang and colour have schema descriptions, while width_mm, height_mm and length_mm do not. The description adds millimetre units and groups the size fields, and restates the colour format, but it omits the lang parameter entirely.
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?
It states a specific verb and resource: 'Show one Drint mockup in an interactive 3D viewer,' and lists the viewer interactions. It points to search_mockups for the id but does not explicitly distinguish this tool from the close sibling send_to_3d_studio.
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 concrete prerequisite by saying 'Take the id from search_mockups,' which tells the agent where the required value comes from. However, it does not say when to use this tool versus alternatives such as send_to_3d_studio, and there are no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show one of the signed-in person's Drint projects in 3D with its own design printed on it, in a viewer they can rotate and open in Drint. Take the id from list_my_projects. A project with several products (a set) can name one with product (its number from 0). On the Free plan the product wears Drint's watermark grid, as in the studio.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The project id from list_my_projects. | |
| lang | No | The user's language (vi, en, th, zh…). Default en. | |
| product | No | Which product of a set (0 = first). Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful detail beyond annotations: the viewer supports rotation and opening in Drint, product selection for sets, and a Free-plan watermark. It does not mention return format or pagination, but those are less crucial for a viewer open action.
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 three tight sentences with the main action front-loaded. Every sentence adds useful context: id source, product handling, and plan-specific watermark behavior.
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 explains what the user sees and how the project is opened. It covers the critical calling context — id source, product variant, and Free-plan watermark — though it does not describe return values or error behavior.
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 id, lang, and product. The description reinforces id sourcing and product indexing but adds little beyond what the schema already provides; lang is not mentioned in the description.
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 resource: showing one of the signed-in person's Drint projects in 3D with its design. It is clear what the tool does, but it does not explicitly distinguish itself from similar siblings such as open_mockup or send_to_3d_studio.
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 prerequisite — take the id from list_my_projects — and explains product selection for sets. However, it does not say when to use this tool instead of alternatives like open_mockup, so alternatives and exclusions are left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hộp duyệt, the signed-in person's review inbox in Drint: the work their space handed on to Drint 3D Studio (scenes, renders) or Drint AI (design edits, pictures, films), and the results that came back and wait to be accepted into the project. Each job has its project, status and, once done, its result pictures (links valid ten minutes). Accepting happens in Drint: each job has a link that opens its project with Hộp duyệt up. Optional: project (an id from list_my_projects), waiting_only.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | The user's language (vi, en, th, zh…). Default en. | |
| limit | No | Default 10. | |
| project | No | Only the jobs of this project (id from list_my_projects). Optional. | |
| waiting_only | No | Only the jobs whose results wait to be accepted. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioural context beyond that: result picture links expire after ten minutes, jobs carry status, and acceptance is an external action opened through a per-job link.
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 resource definition is front-loaded in the first clause, followed by what jobs contain and the caveat about accepting. It is a bit dense in one long sentence, but every sentence carries information an agent needs.
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 compensates by explaining that each job has a project, status, and result pictures with time-limited links. Combined with annotations and a fully documented schema, an agent has what it needs to call it, though pagination and ordering of results 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?
Schema coverage is 100%, so the baseline applies. The description restates project and waiting_only exactly as the schema documents them and adds no syntax, defaults, or edge-case detail (limit, lang) that isn't already structured.
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 and scope: the signed-in person's review inbox, covering jobs handed to Drint 3D Studio or Drint AI plus results awaiting acceptance. It also names the local product term 'Hộp duyệt' and points to list_my_projects for project ids, so an agent can tell it apart from sibling listing 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 states that accepting does not happen through this tool but in Drint via each job's link, which is a genuine when-not guideline. It also documents the optional filters, though it never explicitly contrasts with list_my_projects or my_drint beyond the id reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Drint's library of ready 3D packaging and print mockups (about a thousand models: paper boxes, rigid gift boxes, paper bags, shipping cartons, bottles, jars, cans, cups, labels, flexible pouches, mugs, apparel, signage, posters, books, calendars). Use a few plain words for the product, e.g. "kraft paper bag", "tuck end box", "hộp quà Tết", "chai mỹ phẩm". Returns models with id, name, size in mm and a picture; shows them as a grid the user can click to open in 3D.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | The user's language (vi, en, th, zh…). Default en. | |
| limit | No | How many models (default 8). | |
| query | Yes | What to look for, a few words, English or Vietnamese. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive and closed-world, so the description does not need to re-litigate safety. It adds real behavioral context the annotations don't: the catalog is pre-made models (not user projects), results render as a clickable grid that opens in 3D, and plain-word fuzzy matching is expected. It does not state what happens on zero matches or how ranking works.
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 purpose and corpus scope, then query guidance, then return shape — a sensible order. The 18-item category parenthetical is long and borders on list-dumping, but each item contributes to helping an agent decide whether the model it wants exists here.
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?
Search tools live or die on query formulation and result shape, and the description covers both (return fields id/name/size/picture plus the grid UI). Nothing critical is missing for a simple 3-param read tool; only edge-case behavior (no results, ranking, why `limit` defaults to 8) is left to the schema.
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 and the schema handles field-level meaning. The description still earns credit by showing what a good `query` looks like ("kraft paper bag", "tuck end box", "hộp quà Tết"), which conveys the multilingual, multi-word-but-short query style better than the schema's one-liner.
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 ("search Drint's library of ready 3D packaging and print mockups") and bounds the corpus (~1000 models, enumerated categories). An agent can distinguish this from open_mockup, list_dielines, or get_dieline purely from the text.
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 usage guidance for the query ("a few plain words for the product") with four worked examples, which is the main thing an agent needs to call this correctly. It never names the alternative for the obvious next step (open_mockup to open a found model), so routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare one of the signed-in person's Drint projects for Drint 3D Studio, where its whole product set is staged and rendered as photo-real scenes that come back to the project's Hộp duyệt. Returns a link: it opens the project in Drint with the hand-on menu up, and the person clicks "Dựng cảnh ở 3D Studio" — the products and their artwork are built in their browser, so this tool cannot send them by itself. Take the id from list_my_projects.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The project id from list_my_projects. | |
| lang | No | The user's language (vi, en, th, zh…). Default en. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false), and the description adds the genuinely non-obvious fact that the tool does not itself send anything — it returns a link the human must click, with rendering done in the user's browser. It also states where results land (the project's approval inbox), which an agent could not derive from structured fields.
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 dense sentence carries the whole purpose, but the most decision-relevant caveat ('this tool cannot send them by itself') is buried mid-sentence behind an aside about the in-product menu label rather than being front-loaded. The mixed-language UI strings also add reading cost without adding callable 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 only two fully-documented parameters and no output schema, the description covers the essentials: what is prepared, what is returned (a link), who completes the action, and where output surfaces. Missing only explicit sibling routing and any note on failure modes or repeat invocations.
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 both parameters are already documented, including that id comes from list_my_projects. The description repeats that provenance but says nothing about the lang parameter or its default, so it adds little beyond the schema — baseline 3.
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 concrete verb and resource ('Prepare ... a Drint project for Drint 3D Studio') and explains the outcome: products staged and rendered as photo-real scenes returned to the project's approval inbox. It is distinguishably about 3D staging rather than the sibling open_my_project/open_mockup, though it never explicitly contrasts with them and the 'send' framing is a bit at odds with the actual prepare-and-link behavior.
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 predecessor hint ('Take the id from list_my_projects') and implies the use case (wanting products rendered as photo-real scenes), but offers no when-not guidance or comparison against the other project-opening siblings, so the agent must infer selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
open_mockup1 field changedInput schema / properties / lang / enumPrevious value: -[
- "vi",
- "en",
- "th",
- "zh",
- "id",
- "es",
- "pt",
- "ms",
- "fil",
- "fr",
- "ja",
- "ko",
- "hi"
-]New value: +[
+ "zh-Hant",
+ "fil",
+ "tet",
+ "vi",
+ "en",
+ "zh",
+ "ja",
+ "ko",
+ "mn",
+ "th",
+ "km",
+ "lo",
+ "my",
+ "id",
+ "ms",
+ "hi",
+ "ur",
+ "bn",
+ "ne",
+ "si",
+ "ta",
+ "dz",
+ "dv",
+ "kk",
+ "uz",
+ "ky",
+ "tg",
+ "tk",
+ "fa",
+ "ps",
+ "ar",
+ "he",
+ "tr",
+ "az",
+ "hy",
+ "ka",
+ "el",
+ "es",
+ "pt",
+ "fr"
+]search_mockups1 field changedInput schema / properties / lang / enumPrevious value: -[
- "vi",
- "en",
- "th",
- "zh",
- "id",
- "es",
- "pt",
- "ms",
- "fil",
- "fr",
- "ja",
- "ko",
- "hi"
-]New value: +[
+ "zh-Hant",
+ "fil",
+ "tet",
+ "vi",
+ "en",
+ "zh",
+ "ja",
+ "ko",
+ "mn",
+ "th",
+ "km",
+ "lo",
+ "my",
+ "id",
+ "ms",
+ "hi",
+ "ur",
+ "bn",
+ "ne",
+ "si",
+ "ta",
+ "dz",
+ "dv",
+ "kk",
+ "uz",
+ "ky",
+ "tg",
+ "tk",
+ "fa",
+ "ps",
+ "ar",
+ "he",
+ "tr",
+ "az",
+ "hy",
+ "ka",
+ "el",
+ "es",
+ "pt",
+ "fr"
+]open_mockup1 field changedInput schema / properties / lang / enumPrevious value: -[
- "vi",
- "en",
- "th",
- "zh",
- "id",
- "es",
- "pt",
- "ms",
- "fil",
- "fr",
- "ja",
- "ko"
-]New value: +[
+ "vi",
+ "en",
+ "th",
+ "zh",
+ "id",
+ "es",
+ "pt",
+ "ms",
+ "fil",
+ "fr",
+ "ja",
+ "ko",
+ "hi"
+]search_mockups1 field changedInput schema / properties / lang / enumPrevious value: -[
- "vi",
- "en",
- "th",
- "zh",
- "id",
- "es",
- "pt",
- "ms",
- "fil",
- "fr",
- "ja",
- "ko"
-]New value: +[
+ "vi",
+ "en",
+ "th",
+ "zh",
+ "id",
+ "es",
+ "pt",
+ "ms",
+ "fil",
+ "fr",
+ "ja",
+ "ko",
+ "hi"
+]get_dielinelist_dielineslist_my_projectsmake_dielinemy_drintopen_mockupopen_my_projectreview_inboxsearch_mockupssend_to_3d_studioPackaging design with 3D mockups and print-ready dieline PDFs
Find, size, price and order packaging: boxes, mailers, poly bags, tape. Live price and stock.
Turn product photos or PSD templates into photorealistic mockups: place artwork, edit text, render.
Add one secure layer between your agents and this server.
