Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

verify_manual_authenticity

Read-only

Verify whether a buyer's PDF or 3MF manual is the official release by matching its SHA-256 hash or release ID against indexed records.

Instructions

Buyer-facing verification — is THIS PDF the official manual?

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pdf_path": "<pdf_path>"
    },
    "name": "verify_manual_authenticity"
  }
}

Input Schema

NameRequiredDescriptionDefault
pdf_pathYesLocal path to the buyer's PDF — OR the augmented .3mf the kit-maker shipped (auto-detected by extension / ZIP magic). When a .3mf is supplied the embedded ``Kiln/manual.pdf`` is extracted and verified; the embedded ``Kiln/release_manifest.json`` (when present) auto-supplies the release_id so the buyer doesn't have to know it. When a bare PDF is supplied with no other identifiers, the buyer's SHA-256 is matched against the indexed ``manual_pdf_sha256`` column on every release — the buyer doesn't need a release_id at all.
design_idNoId of the design the release belongs to, for a name-based lookup when the buyer has no release id. Used only together with ``release_name`` and only when ``release_id`` is not given.
release_idNoDirect release identifier (preferred when the buyer has it from a QR or invoice). Auto-populated from a 3MF's embedded manifest when not supplied explicitly.
release_nameNoThe release's name (e.g. ``"v1.2"``), looked up under ``design_id``. A name lookup reaches only releases kept on the machine answering the call, not those signed into a Kiln account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.1

TDQS

B3.2/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. Beyond that the description adds essentially nothing: it doesn't say what 'verified' means, what is compared (hash, manifest, signature), what happens when no match is found, or whether a failed check errors or returns a negative verdict.

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

Conciseness3/5

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

It is genuinely short with zero filler and front-loads the verb, but the single fragment-plus-question construction is under-specified rather than efficient for a tool with four parameters and non-trivial input resolution rules.

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 annotations covering safety, a full-coverage schema explaining all four inputs and the 3MF/PDF resolution paths, and no output schema to document, the remaining burden on the description is modest. It still omits what a verification result looks like and how ambiguity (multiple candidate releases) is resolved, keeping it short of complete.

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

Parameters3/5

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

Schema description coverage is 100% and the parameter docs are unusually rich — they explain 3MF auto-detection, embedded manual extraction, manifest-driven release_id population, and SHA-256 matching without any identifiers. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and object — verifying whether a given PDF is the official manual — and frames it as a buyer-facing check, which is a real scope signal. It does not distinguish itself from nearby siblings such as batch_verify_manuals or verify_design_release, so the reader can't tell from the description alone which verification tool applies when.

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

Usage Guidelines3/5

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

Usage is only implied: 'Buyer-facing' suggests the caller is a purchaser checking a file they received, not a kit-maker or auditor. There is no explicit when-to-use, no when-not-to-use, and no routing to batch_verify_manuals for multi-file checks or to list_manual_history for revision questions.

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