Blog › Drint MCP tested

Does a packaging MCP server make AI assistants more reliable? A measured test of Drint MCP

By Nguyễn Thành Dân, Founder of Drint · 01/11/2026

Key findings

• Relevance: mean precision at 5 (P@5) was 0.82 across 40 briefs. The first result was relevant in 37 of 40.
• Speed: median response for mockup search was 149 ms, 95th percentile 245 ms, worst 496 ms. Dieline lookups had a median of 81 ms.
• Determinism: 40 of 40 queries returned the same five models in the same order when repeated.
• Completeness: all 198 returned models carried a size in millimetres and a picture.
• Coverage: 20 dieline queries surfaced 228 distinct die codes: 114 FEFCO, 65 ECMA and 49 Drint house styles, each with a default size.
• Defects: 63 of 198 results (31.8%) showed Vietnamese text to an English request. Three briefs failed because a modifier outranked the product noun.
• After the fix: rerun live on drint.io the same evening, P@5 rose to 0.935, the first result was relevant in 40 of 40, and Vietnamese text fell to 7 of 200 results.

What question does this study answer?

We set four research questions before the run:

1. RQ1, relevance. Does a plain-English brief return the product the designer meant?
2. RQ2, latency. Is the tool fast enough to sit inside a chat without slowing it?
3. RQ3, stability. Does the same question give the same answer twice?
4. RQ4, completeness. Does every answer carry the facts a designer needs: size, picture, die code?

These questions matter because a tool-using assistant inherits the tool's errors. If the tool is slow, the chat stalls. If it is unstable, two designers get two answers to one brief. If it is wrong, the assistant repeats the error with confidence.

How was the test run?

System under test. The public endpoint https://drint.io/mcp, version live on 1 November 2026, between 14:30 and 14:40 UTC.

Client. A script on a single computer in Vietnam sent JSON-RPC tools/call requests directly to the server. No language model sat in the loop. This isolates the tool from the behaviour of any one assistant.

Tools. search_mockups (limit 5, language English) and list_dielines (language English). Both are open tools that need no account. Tools that consume a user's plan, such as dieline file downloads, were excluded.

Query set. 40 briefs written to match how designers describe work, spread across boxes, bags, bottles and jars, cans, cups, apparel, print and display. The full list is in the appendix.

Relevance rule. Each brief has a list of target words fixed in advance. A result counts as relevant when its English name, kind or group contains one of them. For "wine bottle" the targets are "wine" and "bottle". The rule is strict and mechanical. It cannot reward a near miss, and it cannot be bent after seeing results.

Metrics. P@5 is the share of the top five results that are relevant, averaged over briefs. Top-1 hit is whether the first result is relevant. Latency is wall-clock time per call, measured at the client, so it includes the network. Each brief ran twice, giving 80 search calls.

RQ1: does the search return what the designer meant?

Mostly, yes. Mean P@5 was 0.82. In 24 of 40 briefs all five results were relevant. The first result was relevant in 37 of 40.

Source: Drint MCP benchmark, 1 November 2026, n = 40 briefs.

The rule undercounts in places. For "candle jar" it scored a candle box as irrelevant, yet a designer planning candle packaging may want it. For "egg carton" two of the missed results were egg and cake trays filed under a carton kind. We kept the strict scores rather than adjust them by hand.

Where did the search fail, and why?

Three briefs failed for the same reason: a modifier outranked the head noun.

• "coffee mug" returned a magnetic coffee box, a coffee paper bag and paper coffee cups. No ceramic mug appeared, although the library holds ceramic mugs. The word "coffee" matched more models than "mug".
• "paint bucket" returned a bucket hat first. The library has paint pails, but under the word "pail".
• "cosmetic jar" returned cosmetics bags and trays before a cosmetic bottle. "Cosmetic" outweighed "jar".

In English noun phrases the last noun names the object; the words before it qualify it. A ranking that weights every word alike will drift toward whichever modifier is most common in the catalogue. The fix is to weight the head noun above modifiers and to map synonyms such as bucket and pail. This is a ranking defect, not a gap in the library.

Did fixing the ranking help?

Yes. Drint changed the ranking the same day, in two steps. First, when a brief ends in a specific container noun (mug, jar, bucket, bottle, can, cup, tube, tin, pouch or sachet), models of that kind now rank first. "Bucket" now also matches "pail". Generic nouns such as box, bag and carton are left out of the rule. In a first version they were included, and "sleeve box" fell from three relevant results to none, because every box is a box. Second, the search now reads a shared table of trade words in several languages, and a model matching the most words of the brief leads the list.

We first tested the changes on a local copy of the catalogue, then reran the same 40 briefs on drint.io once they were live, at 15:42 UTC.

Source: Drint MCP benchmark, drint.io, 1 November 2026, 14:30 and 15:42 UTC. Median search latency in the second run was 138 ms, and all 40 briefs again repeated exactly.

No brief scored lower than before. An intermediate version did: "candle jar" fell to 1 of 5, as plain jars pushed out candle jars, until the second step restored it to 3 of 5. The weakest briefs are now magnetic box, pillow box, sleeve box, paint bucket and candle jar, each at 3 of 5.

RQ2: is it fast enough for a chat?

Yes. Across 80 search calls the median was 149 ms and the 95th percentile 245 ms. The slowest call took 496 ms. Dieline lookups were faster: median 81 ms, 95th percentile 98 ms, over 20 calls.

For scale, the language model's own reply in a chat usually takes seconds. A tool that answers in under a quarter of a second adds little a user would notice. These numbers include the network from Vietnam; users nearer the server would see less.

RQ3: does the same question give the same answer?

Yes. All 40 briefs returned the same five model ids in the same order on the second run. The search is a ranked lookup over a fixed index, not a generative step, so it does not vary from run to run.

This matters more than it seems. A language model alone can name different box styles each time it is asked. With the tool, two designers on the same brief start from the same list.

RQ4: does each answer carry the facts a designer needs?

Every one of the 198 returned models had a size in millimetres and a picture. Every one of the 228 die codes had a default length, width and height and a link that opens the die in Drint's editor at that size.

Of the codes, 114 were FEFCO (corrugated) and 65 ECMA (folding carton), close to the "about 180" the tool describes. The other 49 were Drint's own named styles, such as a flip-top box with a lock tab or a pizza box with a window.

What about language?

This is the clearest defect. Asked in English, 63 of 198 results (31.8%) contained Vietnamese text in the name, kind or group. Some of it is correct: Tết and bánh mì are proper names. Most is not, such as a kind shown as "Hộp cứng nắp nam châm" instead of "Magnetic rigid box". Of the 228 die codes, 39 had Vietnamese names.

The cause was in the server's dictionary lookup, not the catalogue. Entries were stored with a note in brackets, such as "Hộp cứng nắp nam châm (hộp sách)", so an exact lookup missed them. Names ending in a size, such as "50 ml", were not split before lookup. Drint fixed both and added 17 missing names in English, French, Japanese and Korean.

On drint.io after the fix, Vietnamese text fell from 63 of 198 results to 7 of 200. Six are the proper name Tết. One, a kind named "Khối đa diện" (polyhedron box), still lacked an English name; Drint has added it for the next release. Die codes with Vietnamese names fell from 39 of 228 to 9, and those nine have been translated for the same release.

Does it save tokens?

Probably, and more as use grows. We measured only the Drint side. A die code lookup returned about 55 tokens of text for the model to read. A five-model search returned about 140, and a list of 32 mailer styles about 630. These are estimates at four characters per token, from the tool output of 1 November 2026.

An assistant working alone has to write the die itself. A full dieline as SVG, with cut and crease lines and glue flaps, runs to thousands of output tokens, which providers bill at several times the rate of input. Complex shapes such as a star, a 12-sided box or a hexagonal pizza box need more. If the geometry is wrong, the designer asks again and pays again.

There is a fixed cost too: the tool definitions load into every conversation. For one question the saving may be small. For a studio making dozens of dies a week, reading a few hundred tokens instead of writing thousands adds up. We did not run a paid API comparison, so we give no exact figure.

How much should these results be trusted?

Every study has limits. These are ours.

• Author bias. Drint tested its own product. The pre-fixed query list and scoring rule reduce, but do not remove, that bias.
• Small sample. 40 briefs cannot represent every request. Precision on briefs for apparel or signage may differ from packaging.
• Mechanical relevance. The word-match rule is objective but coarse. Human raters might score some results differently, in both directions.
• No assistant in the loop. We measured the tool, not a full chat. A real assistant may rephrase a brief before calling the tool, for better or worse.
• No baseline. We did not measure how often an assistant without the tool invents a structure or a size. That comparison needs a separate study with human scoring.
• Token cost not measured. The token section rests on Drint's output size and on estimates, not on billed usage.
• One place, one time. Latency was measured from one client over ten minutes.

What this means for designers

An MCP server does not make an assistant creative. It makes it accountable. The answers come from a catalogue that returns the same models, sizes and die codes every time, fast enough to go unnoticed. Where the tool fails, it fails visibly: a wrong model is on the screen, not hidden in fluent prose.

The practical rule follows from the failures. Name the container precisely: "ceramic mug" beats "coffee drinkware". Always check the size and code in the file before it goes to a printer. Connection steps are in the MCP connection guide. What each tool does is set out in Drint MCP for ChatGPT and Claude, and day-to-day use in How designers use MCP to create packaging mockups.

Appendix: the 40 briefs and their scores

Score marks each of the top five results in rank order: 1 relevant, 0 not.

The 20 dieline queries were: FEFCO, ECMA, 02, 03, 04, 05, 06, 07, 09, A20, A60, tuck, mailer, tray, sleeve, carton, lock, window, handle, divider. Anyone can repeat the test by sending the same tools/call requests to https://drint.io/mcp. Results will drift as the catalogue grows.

Sources

• Drint MCP benchmark, 80 search_mockups and 20 list_dielines calls to https://drint.io/mcp, 1 November 2026, 14:30–14:40 UTC, repeated at 15:42 UTC after the fixes.
• Model Context Protocol, specification and documentation, accessed 1 November 2026.
• FEFCO, International Fibreboard Case Code, accessed 1 November 2026.
• ECMA, European Carton Makers Association, accessed 1 November 2026.
• Manning, Raghavan and Schütze, Introduction to Information Retrieval, Cambridge University Press, 2008, chapter 8 on evaluation and precision at k.

Try it

Connect https://drint.io/mcp using the MCP connection guide, then ask your assistant to "list mailer box structures with FEFCO codes". Browse the same models on Drint mockups and the die codes under dieline codes.

Frequently asked questions