Skip to main content
Glama
fullbleed-engine

Fullbleed PDF Engine

by fullbleed-engine
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Manage Fullbleed assets

fullbleed_assets
DestructiveIdempotent

List, install, verify, or lock font, CSS, and icon packages for PDF documents, writing assets to your workspace and returning package details or operation results.

Instructions

Manage font, CSS, and icon packages with list, info, install, verify, or lock. Returns package details or operation results. Install writes workspace assets and may download supported remote packages. Use fullbleed_inspect for PDFs and fullbleed_verify for document validation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addNoFor lock only: built-in package references to add/update, for example ["@noto-sans", "@bootstrap"]. Omit to preserve existing entries or create an empty lock file; this does not scan arbitrary project files.
actionYeslist shows built-in and cached packages; info describes one package; install vendors it; verify checks package presence/hashes and optional lock constraints; lock creates or updates a lock file using add.
strictNoFor verify only: report a lock mismatch as a tool error. Defaults to false, which returns the verification result with ok=false and violations instead.
packageNoPackage name/reference, such as 'noto-sans' or '@bootstrap'. Required for info, install, and verify; ignored for list and lock. Use list to discover supported names.
availableNoFor list only: include the catalog of supported remote packages in addition to built-in and cached packages. Defaults to false.
lock_pathNoLock file under the MCP workspace root. For verify it must exist; omission skips lock comparison. For lock it is created or updated and defaults to 'assets.lock.json'.
vendor_pathNoFor install only: destination directory under the MCP workspace root, default 'vendor'. Existing matching asset files may be replaced.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv2.5.2
    • addedInput schema / properties / action / description
      Added value: +"list shows built-in and cached packages; info describes one package; install vendors it; verify checks package presence/hashes and optional lock constraints; lock creates or updates a lock file using add."
    • addedInput schema / properties / add / description
      Added value: +"For lock only: built-in package references to add/update, for example [\"@noto-sans\", \"@bootstrap\"]. Omit to preserve existing entries or create an empty lock file; this does not scan arbitrary project files."
    • addedInput schema / properties / available / description
      Added value: +"For list only: include the catalog of supported remote packages in addition to built-in and cached packages. Defaults to false."
    • addedInput schema / properties / lock_path / description
      Added value: +"Lock file under the MCP workspace root. For verify it must exist; omission skips lock comparison. For lock it is created or updated and defaults to 'assets.lock.json'."
    • addedInput schema / properties / package / description
      Added value: +"Package name/reference, such as 'noto-sans' or '@bootstrap'. Required for info, install, and verify; ignored for list and lock. Use list to discover supported names."
    • addedInput schema / properties / strict / description
      Added value: +"For verify only: report a lock mismatch as a tool error. Defaults to false, which returns the verification result with ok=false and violations instead."
    • addedInput schema / properties / vendor_path / description
      Added value: +"For install only: destination directory under the MCP workspace root, default 'vendor'. Existing matching asset files may be replaced."
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations declare openWorldHint, destructiveHint, and idempotentHint, so the safety profile is partly covered; the description adds real context beyond them by disclosing that install writes workspace assets and may download remote packages, and that results are package details or operation results. It stops short of telling the agent which of the five actions is the destructive one.

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

Conciseness5/5

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

Three sentences, front-loaded with the verb-resource-actions summary, then the side-effect disclosure, then the routing hint. No sentence is redundant with another.

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?

For a seven-parameter, five-action, open-world tool with a full output schema and rich parameter docs, the description supplies the essentials: scope of actions, write/download behavior, and alternative tools. The remaining gap is which actions are read-only versus destructive, which annotations partly imply but do not attribute to specific actions.

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 descriptions already explain per-action applicability, defaults, and constraints, so the schema carries the load. The description adds only marginal parameter meaning ('lock ... using add', 'install writes workspace assets') beyond what is already documented.

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 resource (font, CSS, icon packages) and enumerates the five operations (list/info/install/verify/lock), so an agent knows exactly what the tool does. Sibling differentiation is only partial: it names fullbleed_inspect and fullbleed_verify as alternatives, but does not distinguish itself from the other eight siblings such as fullbleed_compile or fullbleed_render.

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?

Explicitly routes the agent away from this tool for two adjacent tasks ('Use fullbleed_inspect for PDFs and fullbleed_verify for document validation'). It gives clear context for the mutating install path but never states when-not to use it against the remaining asset-adjacent siblings.

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