tslink

Overview Schema Source Related Servers Discussions Admin

Preview a service template

template_plan

Read-onlyIdempotent

Preview a built-in multi-service template before applying it; review each service configuration, create-or-skip action, and created/skipped counts without local registry writes.

Instructions

Preview a fixed built-in multi-service stack against the local registry; return each service configuration and create-or-skip action, with created/skipped counts. Use template_plan before template_apply to review without registry writes; recipe_plan previews one app-specific recipe with overrides instead.

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": {
      "name": "<name>"
    },
    "name": "template_plan"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	Template name from template_list.

Output Schema

Name	Required	Description
`name`	Yes
`applied`	Yes	True only when the registry was written; template_plan always reports false.
`created`	Yes
`dry_run`	Yes
`skipped`	Yes
`summary`	Yes
`services`	Yes
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 19, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond them: that no registry writes occur, and that the result is per-service configuration plus a create-or-skip action with created/skipped counts.

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?

Two dense sentences, no filler, and the core purpose plus return shape are front-loaded before the alternatives are mentioned.

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?

With full annotation coverage, a 100%-documented single parameter, and an output schema that carries return details, the description covers everything an agent needs. It also flags the read-only preview role relative to template_apply and recipe_plan, closing the remaining routing gap.

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 coverage is 100% for the single required 'name' parameter and the schema already says it comes from template_list. The description adds no format or source details beyond that, so it neither helps nor harms — the correct baseline is 3 when the schema does the heavy lifting.

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 (preview) and resource (fixed built-in multi-service stack) plus the scope (against the local registry) and what it returns. It explicitly distinguishes itself from recipe_plan and template_apply, so an agent can route without opening a 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?

Gives an explicit when-to-use ('Use template_plan before template_apply to review without registry writes') and names the sibling alternative (recipe_plan) with the condition that selects it (one app-specific recipe with overrides). Nothing is left to inference.

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