This server converts technical drawings and engineering values between metric and imperial units, all deterministic and offline (no API keys).
Convert individual values: lengths, tolerances, GD&T, surface roughness, weights, and thread designations, with exact and display-rounded values, derivation methods, and confidence scores.
Convert callout strings: transforms entire annotations (e.g., "Ø30 H7" → "Ø1.1811 H7", "84±0.1" → "3.3071±0.0039", "M8" → "5/16-18 UNC") while preserving notation; angles unchanged; supports category hints and a fallback mode to treat bare numbers as lengths.
Cross-reference threads: looks up ISO metric ⇄ Unified (UNC) threads, showing major diameters, pitch/TPI, match quality, and provides the full M2–M30 chart on request.
Extract PDF text: reads the text layer of a drawing PDF, returning tokens with index, text, position, rotation, page geometry, and a heuristic unit-system guess.
Convert a drawing PDF: generates a converted copy with converted values stamped in place (white cover, matching size/rotation) using automatic heuristics or per-token classifications from extraction; source file is never modified.
Guided workflow: includes a built-in prompt that walks the AI assistant through extract → classify → convert steps.
Convert technical drawings (PDF) and engineering callouts between metric and imperial — from any MCP-enabled AI assistant.
This Model Context Protocol server exposes the conversion engine behind metric-to-imperial-converter.imnoo.com (by Imnoo): shop-floor-precision unit conversion for dimensions, ± tolerances, ISO fit classes, threads, surface roughness and weights — including producing a converted copy of a drawing PDF with every value stamped in place.
"Convert bracket.pdf to imperial and tell me what replaces the M8 thread"
│
▼ (your AI assistant calls the tools)
extract_drawing_text ──► classify values ──► convert_drawing_pdf
│
▼
bracket.imperial.pdf ✓ Ø30 H7 → Ø1.1811 H7
✓ M8 → 5/16-18 UNCTool | What it does |
| One value, engineering-grade rounding: length (mm⇄in), tolerance deviation, GD&T value, surface roughness (Ra µm⇄µin), weight (kg⇄lb), thread designation. Returns exact + display values, derivation method and confidence. |
| A printed callout string, notation preserved: |
| ISO metric ⇄ Unified (UNC) cross-reference: major diameters, pitch/TPI, nearest-standard matching. Omit the designation for the full M2–M30 chart. |
| Reads a drawing PDF's text layer: indexed tokens with positions/rotation, page geometry, and a heuristic guess of the drawing's unit system. |
| Writes a converted copy of the PDF with every recognised value stamped over the original callout (size and rotation matched). The source file is never modified. |
Plus a convert-drawing prompt that walks the assistant through extract → classify → convert.
The AI-analysis step stays with your assistant. extract_drawing_text hands the model every printed token with its position; the model decides which tokens are real values (and whether a bare 3.2 is a length or an Ra roughness) and passes that as classifications to convert_drawing_pdf. No API keys, no cloud calls — the server itself is fully deterministic and offline.
Related MCP server: pdfmux
Requires Node.js ≥ 18.
claude mcp add drawing-converter -- npx -y drawing-converter-mcpAdd to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"drawing-converter": {
"command": "npx",
"args": ["-y", "drawing-converter-mcp"]
}
}
}Add to Cursor — or add to ~/.cursor/mcp.json:
{
"mcpServers": {
"drawing-converter": {
"command": "npx",
"args": ["-y", "drawing-converter-mcp"]
}
}
}code --add-mcp '{"name":"drawing-converter","command":"npx","args":["-y","drawing-converter-mcp"]}'Any client that launches stdio servers works with:
npx -y drawing-converter-mcpYou: Convert
C:\drawings\flange.pdfto imperial.Assistant: calls
extract_drawing_text— 63 tokens, source system: metric (high confidence — "mm", ISO 2768). classifies tokens, skips the title block, marks1.6next to the surface symbol as roughness, callsconvert_drawing_pdf— wroteC:\drawings\flange.imperial.pdf, 17 values converted: Ø40 H7 → Ø1.5748 H7, 2× M6 → 1/4-20 UNC (nearest standard — not interchangeable), Ra 1.6 → Ra 63 µin…
Quick one-liners work too: "what's 84±0.1 mm in inches?" → convert_text → 3.3071±0.0039.
Conversions follow the same rules as the web app:
Exact factors by international definition (25.4 mm/in, 0.45359237 kg/lb — NIST/ISO 80000).
Display rounding mirrors shop-floor convention: a 0.01 mm step maps to 4-decimal inches; tolerance deviations keep an extra significant digit.
Threads are resolved against an ISO-metric ⇄ UNC chart (M2–M30), tagged table for charted rows or nearest when snapped by major diameter. Metric and inch threads are never interchangeable — the tools say so on every thread conversion.
Every converted value reports how it was derived (exact / rounded / table / nearest) and a confidence score.
The PDF must have a text layer. Scanned or flattened CAD exports have none — the web app handles those with in-browser OCR + AI analysis.
One page is converted per call (page parameter, default 1); other pages pass through unchanged.
Fractional-inch callouts (1 3/4) aren't converted yet — decimal-inch drawings work fine.
Converted values are stamped over the original callouts. Always verify safety-critical dimensions before manufacturing use.
This package is built from the Drawing Converter monorepo at Imnoo, where it imports the web app's conversion engine directly — so the web app and this server convert identically by construction. Every release is gated on 31 end-to-end checks that drive all five tools over stdio against a generated sample drawing.
Issues and feature requests are welcome in this repository.
Imnoo — The System for Manufacturers | AI Planning, Scheduling & Quoting · Complete Assemblies · DFM · Tool & Material Libraries · Quoted-Parts Database · Toolpath & G-Code · Machine Connection · Webshop · ERP · Shop Analytics & Optimization · Drawing Masking & IP Security
Plan It. Schedule It. Quote It. Win It. — trusted by over 3,000 manufacturers.
Imnoo is the AI-powered planning, scheduling, and quoting platform for CNC manufacturers — your automatic production platform. One system that covers it all: automatic manufacturing planning with raw-material, catalog and purchase-part, and subcontracting sourcing; scheduling with smart reminders and AI-driven customer workflows; and AI cost and cycle-time estimation for milling, turning, and EDM — even from a 2D PDF alone. Quote complete assemblies: drop in one file and Imnoo explodes it into single parts automatically — with DFM checks, quality protocols, tolerance extraction and 2D-to-3D matching, toolpath and G-code generation, tool and machine recommendations, and connected machines feeding real production data back into every quote. Built on your own tool and material libraries and a growing database of every part you've ever quoted — powering statistics, benchmarks, and shop optimization. Extends to deep hole drilling, sheet metal, casting, and profile parts — with a 24/7 webshop, built-in ERP, hourly-rate calculation, market-price benchmarking, and imperial ⇄ metric conversion. Your data lives in its own physically separated environment — automatic drawing masking, Swiss hosting, end-to-end encryption. From messy RFQ to production-ready order, on one platform.
Automatic manufacturing planning — production plans generated straight from the quote.
Machine recommendation — every job routed to the machine that runs it best.
Catalog & purchase part management — norm parts, screws, and bought-in components recognized straight from the BOM, managed and priced alongside your machined parts.
Raw material sourcing — price, source, and order material without leaving the workflow.
Purchase part & external step sourcing — bought-in components, coating, heat treatment, and subcontracting sourced and ordered in the same flow.
Beyond milling & turning — deep hole drilling, sheet metal, casting, and profile parts.
Scheduling & smart reminders — via email, Telegram, or WhatsApp. Nothing slips.
Email-to-quote automation — a messy inbox in, structured quotes out.
AI customer agents — RFQ answers, clarifications, and follow-ups handled automatically.
Built-in lightweight ERP — orders, companies, payment terms, and margins without the bulky software.
Complete assemblies, exploded automatically — upload one assembly file and Imnoo blows it out into single parts: every component recognized, drawings matched to the right parts, sub-assemblies nested, purchase parts pulled from the BOM. Quote the whole machine as easily as one part.
CNC quoting in one place — milling, turning, and EDM jobs quoted from a single AI-powered platform.
AI cost & cycle-time estimation — know price, time, and effort before engineering ever looks at it.
Drawing-only estimation — quote from the PDF alone. No 3D model needed.
Feature-by-feature costing — see exactly which holes, pockets, and tolerances drive the price.
Instant quotes — respond in minutes while competitors are still opening the STEP file.
24/7 instant-quoting webshop — customers upload parts and buy while you sleep.
Instant market-price benchmarking — know where your bid stands before you send it.
Hourly-rate calculation — your true machine and labor rates, always current.
Imperial ⇄ metric conversion — international RFQs without manual cleanup.
Tool library — your cutting tools, holders, and parameters in one managed catalog.
Material library — standard and custom materials with live supplier pricing.
Quoted-parts database — every part you've ever quoted, searchable by geometry: similar part found, price found.
Statistics & analytics — win rates, margins, throughput, and quoting performance at a glance.
Shop optimization — learn from already-quoted parts to sharpen prices, spot profitable niches, and load the right machines.
DFM — Design for Manufacturing — manufacturability checked before you quote: undercuts, thin walls, unreachable features, and impossible tolerances flagged with the part still on the screen.
Quality check protocols — inspection plans generated automatically: stamped and numbered drawing features, inspection classes and rates, ready-to-use measurement reports.
Axis & orientation detection — AI finds the best part orientation and machining axes.
Automatic tolerance extraction — critical tolerances pulled straight off the drawing.
2D-to-3D tolerance matching — drawing requirements linked to the right model features.
AI tool recommendation — stop searching catalogs: Imnoo suggests the exact cutting tools for every feature.
Automatic toolpath generation — from quote to machining strategy in one step.
G-code generation & estimation — generate and evaluate programs before work hits the floor.
Machine connection — your machines feed real production data back into the AI. Every quote gets smarter.
Physically separated data — every manufacturer runs in its own isolated environment. Your drawings, prices — never pooled with anyone else's: not for storage, not for AI training.
Automatic drawing masking & redaction — customer names, logos, and confidential data hidden before a drawing ever leaves your workflow. Share with suppliers and subcontractors without exposing whose part it is.
Your customers' IP, treated like your own — end customers' designs stay within your tenant, full stop.
Swiss hosting & end-to-end encryption — data sovereignty and security engineered to Swiss standards.
Trusted at scale — over 3,000 manufacturers run their quoting on Imnoo.
Quote the complete job — not just the spindle time.
MIT © Imnoo AG
Produce a converted copy of a technical-drawing PDF with every recognised value stamped in place (white cover over the original callout, converted text in matching size/rotation) — dimensions, ± tolerances, fit classes, Ø/R callouts, threads. The input file is never modified. Without classifications, a heuristic converts unambiguous callouts plus (by default) bare numbers as lengths; for full control call extract_drawing_text first and pass per-token classifications. Requires a PDF with a text layer — scanned drawings need the web app (https://metric-to-imperial-converter.imnoo.com). Converted values are stamped over the original callouts. Verify safety-critical dimensions before manufacturing use.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page to convert (default 1); other pages pass through unchanged | |
| overwrite | No | allow replacing an existing output file | |
| input_path | Yes | path to the source drawing PDF (read-only) | |
| output_path | No | where to write the converted PDF (default: next to the input as <name>.<target>.pdf) | |
| bare_numbers | No | heuristic mode only — 'convert' (default) treats bare numbers as lengths (year-like and id-like integers excluded); 'skip' converts only unambiguous callouts | |
| source_system | No | unit system of the source drawing (default auto-detect from its text) | |
| target_system | No | default: the opposite of the source system | |
| classifications | No | authoritative per-token classification: when provided, ONLY listed tokens (minus skips) are converted |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the input is never modified (consistent with destructiveHint=false) and notes that converted values are stamped over originals. It adds a safety warning about verifying critical dimensions, which provides context beyond what annotations convey about idempotency and non-destructiveness.
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 concise (~100 words), front-loaded with the core function, and every sentence contributes essential information (modes, prerequisites, limitations, safety warning). No redundant or filler content.
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?
Covers purpose, input/output, modes, prerequisites, and limitations. While no output schema exists, the description implies the output is a file at the specified path. Missing explicit return value details, but sufficient for a file-generation tool with high schema coverage.
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 baseline is 3. The description adds value by explaining the interplay between heuristic and classification modes, linking to specific parameters (classifications, bare_numbers). It also describes default output path behavior, integrating parameter usage into an actionable workflow.
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 clearly states the action ('produce a converted copy'), resource ('technical-drawing PDF'), and outcome ('every recognised value stamped in place'). It distinguishes from siblings by focusing on PDF conversion with stamping, while other tools handle individual values or text extraction.
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?
Explicitly states when to use heuristic mode vs. classification mode, prerequisites (PDF with text layer), and alternatives for scanned drawings (web app) or preparatory step (extract_drawing_text). This provides clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a printed drawing callout (or short text with several callouts) between metric and imperial, preserving notation: "Ø30 H7" → "Ø1.1811 H7", "84±0.1" → "3.3071±0.0039", "R13" → "R0.5118", "M8" → "5/16-18 UNC", "1/4-20 UNC" → "M6". Angles (°) are left unchanged. Set category=surface to read bare numbers as Ra roughness instead of lengths. assume_lengths=true additionally converts every remaining number as a length (for tolerance-table rows like "bis 30").
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | unit system the text is currently in | |
| text | Yes | ||
| category | No | how to read bare numbers (default dimension = length; surface = Ra roughness) | |
| assume_lengths | No | fallback: convert every number as a length when nothing else matched |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses detailed behavioral traits: angles left unchanged, how bare numbers are interpreted based on category, the fallback with assume_lengths, and specific conversion examples. There is no contradiction with annotations.
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 concise yet packed with information: examples, behavior rules, and parameter explanations. It is front-loaded with the core purpose and uses multiple sentences that each add value without redundancy.
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?
The description covers key aspects: unit conversion, notation preservation, category effects, and assume_lengths use. However, it lacks detail on return format (e.g., does it return converted text or structured output?) and error handling for unrecognized patterns, leaving minor gaps given the tool's complexity and no output 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?
The description enriches the schema by explaining the 'text' parameter (as callout string), the effect of 'category' on number interpretation, and the use case for 'assume_lengths'. It compensates for the missing schema description on 'text' by context. The examples clarify parameter semantics.
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 clearly states the tool converts printed drawing callouts between metric and imperial while preserving notation. It provides concrete examples and distinguishes itself from sibling tools (e.g., convert_value, lookup_thread) by focusing on callout text with complex patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives good guidance on when to use this tool (converting callout strings) and explains parameter nuances (category for surface roughness, assume_lengths for tolerance rows). However, it doesn't explicitly mention when not to use it or direct users to alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert one engineering value between metric and imperial with shop-floor precision rules. Kinds: length (mm⇄in), tolerance_deviation (a ± deviation, keeps an extra significant digit), geometric_tolerance (GD&T value), surface_roughness (Ra µm⇄µin), weight (kg⇄lb), thread (designation lookup, e.g. "M8" ⇄ "5/16-18 UNC"). Returns the exact value, the display-rounded value, and how it was derived (exact/rounded/table/nearest) with a confidence score.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | unit system the value is currently in | |
| kind | Yes | ||
| value | No | numeric value — required for every kind except thread | |
| designation | No | thread designation, e.g. "M8", "M8x1.25", "1/4-20 UNC" — required for kind=thread |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only safe operation. Description adds value by detailing return structure (exact value, display-rounded, derivation, confidence), which goes beyond annotations. No contradictions.
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?
Description is informative and well-structured: first sentence states purpose, then lists kinds with examples, then return structure. Efficient but packs necessary detail.
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?
Despite no output schema, description explains return values and derivation method clearly. Covers all kinds and parameter constraints. Could mention error handling or edge cases, but overall complete for typical use.
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 covers 75% of parameters with descriptions. Description adds context: explains each kind, gives examples, and clarifies that value is required except for thread. This compensates for the schema's lack of description for the 'kind' parameter.
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?
Description clearly states it converts engineering values between metric and imperial, lists specific kinds with examples, and distinguishes from sibling tools like convert_text (text conversion) and lookup_thread (thread lookup).
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?
Description provides clear context on when to use (for engineering conversions) and lists supported kinds, but does not explicitly state when not to use or suggest alternatives, though sibling tool names provide implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the printed text tokens of one page of a technical-drawing PDF: each token with its index, text and position (page points, top-left origin, rotation in degrees), plus page geometry and a heuristic guess of the drawing’s unit system. Use the token indices to build classifications for convert_drawing_pdf when you want to decide yourself which tokens are convertible values (e.g. mark a bare "3.2" next to a surface symbol as category=surface, or a title-block number as skip).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number (default 1) | |
| path | Yes | path to the drawing PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds behavioral details: it returns token index, text, position, rotation, page geometry, and a heuristic unit system guess. It also notes it's per-page. No contradictions or hidden behaviors are present.
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 consists of two sentences: the first introduces the tool's output, and the second explains its purpose using token indices. Every sentence adds value with no padding. The structure is clear and front-loaded.
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?
Given no output schema, the description explains the output in sufficient detail: token index, text, position, rotation, page geometry, and unit system guess. It also clarifies the relationship with convert_drawing_pdf. Missing error handling details, but for a read-only extraction tool, this is adequate.
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 input schema covers 100% of parameters with descriptions for 'path' and 'page'. The description adds no new parameter-level details beyond stating that page is optional and 1-based (already in schema). Baseline 3 is appropriate as the schema already does the heavy lifting.
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 'Read the printed text tokens of one page of a technical-drawing PDF' specifies a clear verb ('read') and resource ('printing text tokens of a technical-drawing PDF'). It distinguishes itself from siblings like convert_drawing_pdf, which converts the whole PDF, and convert_value/convert_text, which handle individual values. The purpose is unique and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use the token indices to build classifications for convert_drawing_pdf when you want to decide yourself which tokens are convertible values'. It implies a specific workflow. However, it does not explicitly mention when not to use it or alternatives, though the sibling context makes differentiation clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the closest standard counterpart of a thread designation (ISO metric coarse ⇄ Unified UNC), with major diameters, pitch/TPI and how close the match is. Omit designation to get the whole cross-reference chart (M2–M30).
| Name | Required | Description | Default |
|---|---|---|---|
| designation | No | e.g. "M8", "M12x1.75", "5/16-18 UNC", "#8-32 UNC" — omit for the full chart |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations (readOnlyHint=true): it returns the closest standard counterpart, major diameters, pitch/TPI, and match closeness. It also reveals special behavior (full chart when designation omitted). No contradictions with annotations.
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 concise sentences. The first sentence covers purpose and outputs; the second covers special behavior. No wasted words, and essential information is front-loaded.
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?
Given no output schema, the description adequately explains return values (major diameters, pitch/TPI, closeness). It covers the optional parameter behavior. A minor gap: it doesn't clarify if multiple matches are possible or if the closest match is exact.
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%, and the description enriches the parameter 'designation' with examples (e.g., 'M8', '5/16-18 UNC') and the key behavior of omitting for full chart. This adds practical meaning beyond the schema 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 clearly states the tool's purpose: 'Look up the closest standard counterpart of a thread designation (ISO metric coarse ⇄ Unified UNC), with major diameters, pitch/TPI and how close the match is.' It uses a specific verb ('look up') and resource ('thread designation'), and distinguishes from siblings (conversion/extraction 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?
The description provides clear usage context: cross-referencing metric and inch threads. It also hints at when to omit the parameter ('omit `designation` to get the whole cross-reference chart'). However, it does not explicitly state when not to use or mention alternatives, though siblings are clearly different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct: convert_value for single values with detailed precision, convert_text for batch callouts, lookup_thread for threads, and two PDF-specific tools. Some overlap exists between convert_value and convert_text for single values, but descriptions clarify usage.
All tool names follow a consistent 'verb_noun' pattern in snake_case (convert_value, convert_text, lookup_thread, extract_drawing_text, convert_drawing_pdf), making the set highly predictable.
With 5 tools, the server is well-scoped for converting engineering drawings. Each tool has a clear, non-redundant purpose spanning single values, text, threads, PDF extraction, and PDF conversion.
The tool surface covers the full workflow: value conversion, batch text conversion, thread lookup, PDF text extraction, and PDF conversion with stamping. No obvious missing operations for the stated domain.
Construction takeoff and estimating for AI agents. Measure a drawing PDF, export a priced estimate.
High-fidelity PDF to structured Markdown conversion and document field extraction.
Markdown in, any format out. PDFs merged, split, watermarked. Runs on our own doc engines.
Turn agent intent into physical parts: engineering review, measured geometry, calibrated pricing.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/imnoo-team/drawing-converter-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
