What spanner for an M12 bolt? An agent that knows DIN and ISO disagree

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Fastener Spec Agent answers metric hex fastener questions correctly, including the ones where the official standards disagree with each other.

DIN 933 and ISO 4017 describe the same part: a fully threaded hex head set screw. ISO 4017 replaced DIN 933, but the trade still orders by the old name every day. The two standards are identical at almost every size, except four, where the head's width across flats changed:

Size	DIN 933	ISO 4017
M10	17 mm	16 mm
M12	19 mm	18 mm
M14	22 mm	21 mm
M22	32 mm	34 mm

So "what spanner do I need for an M12 bolt?" has no single correct answer. A chatbot that confidently says "19 mm" is wrong half the time, and a 19 mm spanner on an 18 mm head rounds the corners.

I manage the e-commerce platform for a UK fastener supplier, so this is a question real customers ask. The agent:

• looks up both standards in a Sanity Knowledge Base before answering,
• gives both values when they differ and explains how to tell which one you have,
• notes that DIN 933 is withdrawn but still sold under that name, and
• cites the entries it used and shows every tool call it made.

A keyword search wouldn't get there. "M12 across flats" returns 19 mm or 18 mm depending on which page ranks first. The answer only works because the relationship between the two standards is modelled explicitly.

Demo

The four example questions and what the agent gets right:

• "What spanner do I need for an M12 hex set screw?" 19 mm for DIN 933, 18 mm for ISO 4017, plus how to check which you have (measure across the flats).
• "Is a DIN 933 M22 interchangeable with ISO 4017?" No. M22 is the only size where the ISO head is larger (34 vs 32 mm).
• "What's the head height of an M16 set screw?" 10 mm, identical in both. It doesn't invent a difference.
• "Is DIN 933 still a current standard?" Withdrawn and superseded by ISO 4017, still widely ordered by the old name.

To run it yourself: clone the agent repo, set three values with dotnet user-secrets (a Sanity organization token with Context Viewer permission, the MCP endpoint URL, and an Anthropic API key), then dotnet run. The README has the full steps.

Code

• Agent (.NET 9): https://github.com/aftabkh4n/fastener-spec-agent
• Sanity Studio, schemas and seed data: https://github.com/aftabkh4n/sanity-fastener-kb

How I Used Sanity

The content model

Five document types: standard, fastenerType, propertyClass, sizeSpec (one document per size per standard) and equivalence.

equivalence is the important one. It links two standards and holds an array of differences, each with the size, the attribute, both values and a plain-English practical impact ("Different spanner: 19 mm for DIN, 18 mm for ISO"). Instead of hoping a model notices that two tables disagree, the disagreement is stored as data.

Every dimension came from a published standard sheet, with a source URL and a verified flag I ticked after checking it by hand. Nothing was filled in from a model's memory.

What I pointed Sanity Context at

One Knowledge Base with three sources:

1. My Sanity dataset: 38 documents across all five types, with references unfolded so each size spec carries its standard's code and status.
2. A supplier's DIN 933 standard sheet (PDF).
3. A reference web page comparing DIN 931/933 with ISO 4014/4017.

My first build crawled that website without limits and pulled in 43 pages about flange bolting torque and ASTM stud bolts. Limiting the crawl to the one relevant page kept the Knowledge Base focused and well inside the 150-document budget.

What the Knowledge Base caught

The build raised three issues, and each taught me something.

It found an error in my own data. I had seeded DIN 933 with the status current. The PDF said withdrawn and superseded by ISO 4017, and the PDF was right. I fixed the status in the Studio, linked it to ISO 4017 with supersededBy, and rebuilt.

It caught a real conflict between published sources. The supplier's PDF lists M14 at 21 mm under a DIN 933 heading. That's the ISO value; the original DIN 933 figure is 22 mm. The Knowledge Base showed both claims side by side, each traced to its sources, and I resolved it as 22 mm. That decision persists across builds.

It flagged a conflict that wasn't one, which proved the point of the schema. The build reported M22 as 32 mm in one entry and 34 mm in another. Both are correct: one is DIN, one is ISO. Picking either card would have created a standing instruction teaching the Knowledge Base something false. Instead, I added an instruction stating that DIN and ISO values for the same size belong to separate standards and aren't conflicting facts, and put the same principle in the Knowledge Base's purpose. The false conflict was gone on the next build.

That was the clearest argument for structured content I ran into: without the explicit DIN↔ISO modelling, even the build confused the two standards.

Which Context tools the agent uses

The agent connects to a Context MCP endpoint in Knowledge Base mode, which serves three tools:

• initial_context: fetches the Knowledge Base outline at the start of a conversation, so the agent knows which entries exist
• knowledge_base_read: reads specific entries by path, e.g. dimensions/fully_threaded/din_933, dimensions/fully_threaded/iso_4017 and standards_comparison
• knowledge_base_search: available for questions that don't map neatly onto the outline

What the agent does with the content

The agent is a .NET 9 minimal API using the official Model Context Protocol C# SDK, with Claude running a tool loop over the Context tools. For the M12 question, it reads the outline, pulls the DIN 933, ISO 4017 and standards-comparison entries, then compares them and answers with both values and their sources. Every tool call is shown under the answer, so you can see exactly what it read.

The system prompt rules that mattered most:

• Always consult the Knowledge Base; never answer dimensions from memory.
• When DIN and ISO differ, give both values and say which is which.
• Never guess which standard the user's parts are made to. Tell them how to check instead.

That last rule came from testing. An early answer added "if you bought off-the-shelf stock, it's most likely DIN 933". It sounds helpful, but nothing in the Knowledge Base supported it, so I removed it.

Sanity Project Details

• Project ID: tko9cbz7
• Dataset: production (public)
• Schema: standard, fastenerType, propertyClass, sizeSpec, equivalence (see the Studio repo)

Agent Session

I built both repos with Claude Code. The moment worth showing: I asked it to extract DIN and ISO values from a standard sheet that only tabulated DIN 933. My instructions said to mirror DIN values into ISO if ISO wasn't listed. Following that literally would have produced an equivalence with zero differences, so instead it stopped and explained the collision. I found a second source for the ISO values and confirmed them against a manufacturer's product listings.