Skip to main content
Glama
imnoo-team

drawing-anonymizer-mcp

by imnoo-team
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Analyse a drawing PDF for sensitive data (Imnoo drawing analysis)

analyze_drawing

Detects sensitive data in technical-drawing PDFs — company names, logos, people, addresses, phone numbers, emails, drawing numbers and dates — with page, box, confidence and title-block flags, so you can mask them before sharing.

Instructions

Upload a technical-drawing PDF to Imnoo's drawing analysis and return the sensitive data it finds — company names, logos, person names, addresses, phone numbers, emails, websites, article numbers, drawing numbers, dates and other identifying text — each with a detection id, category, value, PDF page, box (analysis image pixels), confidence, whether it sits in the title block and whether it is masked by default, plus the page sizes. Up to 4 pages are treated as one drawing. Analysis takes roughly 10–120 s; the call waits up to timeout_seconds and otherwise returns status "processing" with the drawing_id to resume with. An identical PDF analysed earlier in this session is returned from memory (no upload). analyze_drawing uploads the PDF to Imnoo's drawing analysis (the service behind the web app): 1 free analysis per day per IP address (signed-in users get more in the web app); uploaded files are deleted automatically within 24 hours and nothing else is stored. Masking itself runs locally and is unlimited.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pdf_pathNopath to the drawing PDF (vector or scanned, ≤ 30 MB)
drawing_idNoinstead of pdf_path: the drawing_id of an earlier upload that returned status "processing" — keeps waiting for it without a new upload
timeout_secondsNohow long to wait for the analysis before returning "processing" (default 180)
save_analysis_toNowrite the analysis JSON to this path (re-open it later with load_analysis, no upload needed)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: quota (1 free analysis/day/IP), retention (files deleted within 24h, nothing else stored), latency (10–120 s), timeout behaviour with status "processing" plus resumable drawing_id, and session-level caching. The idempotentHint=false annotation is not contradicted — caching an identical PDF in-session is distinct from idempotent mutation semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and return shape, then quotas and retention last. Dense but nearly every clause carries information; the only mild redundancy is restating the wait/timeout behaviour in both the timing sentence and the upload sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by enumerating returned fields (detection id, category, value, page, box, confidence, title-block flag, masked flag, page sizes). Inputs, cost, and retention are covered; only error/failure handling is left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds relationships the schema states only locally: that drawing_id resumes an earlier call that returned "processing" without a new upload, that timeout_seconds caps the wait before returning "processing", and that up to 4 pages count as a single drawing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Upload a technical-drawing PDF to Imnoo's drawing analysis and return the sensitive data it finds', then enumerates exactly what is detected. It separates itself from siblings by stating that memory-cached re-analysis avoids a new upload and that masking runs locally, making it distinguishable from load_analysis and mask_drawing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real operating context: 1 free analysis per day per IP, identical PDFs served from session memory without re-upload, and the drawing_id resume path. It falls short of explicitly naming when to prefer `load_analysis` or `mask_drawing` over this call, leaving that routing to be inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools