figlens

Overview Schema Source Related Servers Discussions Admin

verify

Checks a zipped or extracted bundle against its manifest before building, reporting missing or changed files, missing assets, visible-text font faces, and preflight findings with node IDs.

Instructions

Check a bundle, zipped or extracted, against its manifest before building from it: verified, missing and changed files, the bundle's missing assets, and the font faces the visible text uses (with node ids). Fonts are always unverified here: confirm each face in the running project with document.fonts.load, and check browser delivery of assets there. findings gathers these checks with the bundle's unresolved variables, truncated state inventory, render limitations and unemitted semantics into one handoff preflight list, each with node ids, evidence, impact and next action. Reports without blocking; no design file is read.

Input Schema

Name	Required	Description	Default
`bundle`	Yes	path to a bundle .zip or the directory it was extracted to

Output Schema

Name	Required	Description
`path`	Yes
`files`	Yes	verified count; missing paths; changed entries with expected and actual size/sha256 (actual null when larger than declared, unreadable, with error, or not a regular file inside the bundle); invalid manifest paths
`fonts`	Yes	family, style, weight, postScriptName, nodeIds and status, always unverified
`findings`	Yes	handoff preflight, missing inputs first: category (integrity, asset, variable, scope, render, semantics, font), status (missing, unsupported or unverified), source file, nodeIds (at most 20, none over 1 KiB) and nodeCount, evidence, impact and action; at most 500 entries and 1 MiB
`truncated`	Yes	original length of each other list cut to stay within the reply budget (files.missing, files.changed, files.invalid, missingAssets, fonts); empty when nothing was cut
`unverified`	Yes
`missingAssets`	Yes	missing-assets.json entries
`findingsSummary`	Yes	scope (bundle root nodeId and name), total, returned, truncated, counts per category/status, unexamined metadata files, semanticsCoverage (the handoff inventory's coverage) and the coverage the findings do not establish

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.9.3Oct 29, 2026

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations present the description carries the full burden and does it well: "Reports without blocking" declares non-failure-on-issues semantics, "no design file is read" declares the read-only boundary, and it discloses aggregation behavior and truncation of the state inventory. It also pre-warns that findings may include render limitations and unemitted semantics, so the agent knows what class of noise to expect.

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?

The purpose sentence is front-loaded correctly and there is no marketing filler, but the second sentence is an overloaded run-on packing findings contents, evidence fields, and caveats into one clause stack. Terms like "unemitted semantics" and "truncated state inventory" cost parsing effort and would read better as a short list.

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?

The tool has an output schema, so return values needn't be fully explained, yet the description still characterizes the report shape (verified/missing/changed files, missing assets, font faces with node ids, findings entries carrying node ids, evidence, impact, next action). Combined with the explicit non-blocking/read-only disclosure, an agent has enough to call it and interpret results.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents the bundle path including the .zip-or-directory duality. The description's "zipped or extracted" restates that rather than adding format, naming, or resolution rules, so baseline 3 applies.

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?

States a specific verb and resource ("Check a bundle, zipped or extracted, against its manifest") and anchors it to a phase ("before building from it"), which separates it from siblings like bundle/export (produce) and inspect/tree (explore). An agent can tell what it does and when it fires without opening the schema.

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 a clear usage context (pre-build preflight) and an explicit exclusion: fonts are never verified here, and the agent is told to confirm faces in the running project via document.fonts.load and check asset delivery in the browser. It stops short of naming a sibling tool as the alternative for those follow-ups, but the routing intent is unambiguous.

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

Deploy Server