Skip to main content
Glama
Sign In
calllint

CallLint

Official
by calllint
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

calllint_apply_prepared_install

Applies an approved install plan to write a pinned MCP server into a host config after verifying the approval digest, aborting before any write on mismatch.

Instructions

Apply an install plan you already prepared and explicitly approved, writing the pinned MCP server into a host's config. This is a WRITE — it is the only CallLint tool that changes a file, and it refuses unless you name a supported host AND pass approvalDigest equal to the exact planDigest calllint_prepare_safe_install returned. Before writing it re-runs the full local gateway from scratch and recomputes the plan: if the host config or the pinned target changed since you prepared, the digest differs and the apply aborts with nothing written. A public BLOCK/UNKNOWN/unsupported route, a local BLOCK/UNKNOWN decision, or an exact-target mismatch all refuse before the write. The write itself is delegated to CallLint's shipped apply engine, which backs up the current config, writes atomically under a lock, re-reads to verify, and rolls back on any failure — so a failed apply leaves the original config in place. Outcomes: APPLIED_AND_VERIFIED (written and verified, with a decision receipt returned inline for later verification), ABORTED_ON_MISMATCH, BLOCKED, LOCAL_PREFLIGHT_REQUIRED, or UNSUPPORTED. This is a one-time protected setup: it installs no CallLint components, leaves no persistent CallLint files, and never starts, connects to, authenticates to, or tests the server it installed.

Input Schema

NameRequiredDescriptionDefault
hostYesTarget host to write: claude-code, cursor, or windsurf. Required — an apply never guesses a host.
canonicalNameYesThe resource's canonical name / slug (the same one you prepared).
approvalDigestYesThe exact sha256:<64-hex> planDigest calllint_prepare_safe_install returned and you reviewed. Required; a mismatch against the freshly recomputed plan aborts with nothing written.
hostConfigPathNoPath to the host's MCP config to write. Optional for claude-code and windsurf (their own config path is used); REQUIRED for cursor, whose config is project-scoped.
expectedVersionNoOptional exact version to assert; a mismatch aborts with nothing written.
expectedArtifactDigestNoOptional sha256:<64-hex> artifact digest to assert against the contract; a mismatch aborts.
expectedContractDigestNoOptional sha256:<64-hex> contract digest to assert + record as plan provenance; a mismatch aborts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.2

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it declares WRITE semantics, the digest re-verification against a freshly recomputed plan, the backing up/atomic-with-lock/verify/rollback behavior, the guarantee that a failed apply leaves the original config in place, all five outcome values, and negative guarantees (installs no components, leaves no persistent files, never connects to the server).

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?

Single front-loaded paragraph that leads with the action, then prerequisites, then failure/rollback guarantees, then outcomes. Dense but nearly every clause adds operational information; the outcome enumeration and negative guarantees could be tightened slightly.

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

Completeness5/5

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

For a high-risk destructive write with no annotations and no output schema, the definition covers prerequisites, refusal conditions, atomicity/rollback, outcome vocabulary, and what happens afterward (decision receipt returned inline). Nothing an agent needs to invoke it correctly is missing.

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 genuine cross-parameter meaning the schema only hints at: approvalDigest must equal the planDigest returned by prepare, and the host must be a supported value or the call refuses. It does not enumerate per-parameter format beyond what the schema already documents.

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 ('Apply an install plan ... writing the pinned MCP server into a host's config') and immediately differentiates itself from siblings by declaring it is 'the only CallLint tool that changes a file.' An agent can distinguish it from calllint_prepare_safe_install and verify_baseline without opening any schema.

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

Usage Guidelines5/5

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

Explicitly names the prerequisite ('a plan you already prepared and explicitly approved') and the producing sibling (calllint_prepare_safe_install), plus the exact conditions that select refusal: unsupported host, missing/mismatched approvalDigest, public BLOCK/UNKNOWN/unsupported route, local BLOCK/UNKNOWN, exact-target mismatch. When and when-not are both stated.

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