tslink

Overview Schema Source Related Servers Discussions Admin

Apply an app recipe

recipe_apply

Idempotent

Register one app-specific recipe with overrides and ensure its background service, unless skipped; use it after reviewing a plan to apply a private app setup.

Instructions

Register one app-specific recipe with the supplied overrides, then ensure the background service unless no_daemon_install is true. Returns the created or preserved service, requested configuration, action and safety advice. Use recipe_apply after reviewing recipe_plan; template_apply registers a fixed multi-service stack instead. Leaves existing names unchanged. Never-public apps refuse Funnel unless the owner explicitly accepts force_unsafe_public and public_ack. Does not configure, install or probe the third-party app.

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

Input Schema

Name	Required	Description
`name`	No	Optional service name override.
`tags`	No	Comma-separated tags.
`allow`	No	Comma-separated private HTTP identities.
`funnel`	No	PUBLIC INTERNET exposure: review app authentication with the owner first.
`health`	No
`target`	No	Optional loopback HTTP(S) target override; use the host port.
`ephemeral`	No
`recipe_id`	Yes	Recipe ID from recipe_list.
`funnel_ttl`	No	Relative lifetime (descending unique units w,d,h,m,s,ms,us,ns) or until <RFC3339\|YYYY-MM-DD\|YYYY-MM-DDTHH:MM>. Local unless offset given; DST gaps/folds require an offset. Minimum 1h. Presets: 1h, 8h, 24h, 3d, 7d. Default 24h; guest/public maximum defaults to 7d, configurable in durations.public_max. Never refused. Omission on add preserves an existing deadline.
`public_ack`	No	Required acknowledgement when funnel is true.
`control_url`	No
`preserve_host`	No	Override the recipe Host forwarding default; omitted uses recipe.preserve_host. False explicitly restores upstream Host rewriting.
`request_limits`	No
`no_auto_provision`	No
`no_daemon_install`	No
`force_unsafe_public`	No	DANGER: overrides never-public recipe policy, potentially exposing host control, code execution or secrets to everyone. Requires funnel and public_ack.

Output Schema

Name	Required	Description
`next`	Yes
`action`	Yes
`recipe`	Yes
`applied`	Yes
`dry_run`	Yes
`service`	Yes
`warnings`	Yes
`requested`	Yes
`schema_version`	Yes
`catalog_version`	Yes
`daemon_installed`	No	Present only when this call installed TSLink's background service, a persistent OS autostart entry; absent when the service already ran or no_daemon_install was true.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 19, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Adds real behavioral context beyond annotations: the Funnel refusal policy for never-public apps unless force_unsafe_public and public_ack are accepted, that omission leaves existing names unchanged, and the explicit non-goal of configuring/installing/probing the app. Some of this (public_ack/force_unsafe_public coupling) is echoed in the schema, and permission/auth requirements are not stated, so it falls short of a 5.

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?

Front-loaded with the core action, followed by alternatives, return summary and safety boundary in compact sentences. Dense but nearly every clause carries weight; the return-value sentence is partly redundant given the output schema exists, which keeps it from a 5.

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 16-parameter, nested-object, mutation-style tool with an output schema and rich annotations, the description covers scope, routing, return shape and the key safety policy. It stops short of clarifying several untyped/undocumented parameters (ephemeral, no_auto_provision, control_url), leaving some gaps in an otherwise complete picture.

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 63%, so most parameters already carry their own defaults, ranges and semantics. The description speaks only generically of 'supplied overrides' and touches a few flags (no_daemon_install, funnel, force_unsafe_public), adding no syntax or meaning beyond schema text; undocumented params like ephemeral, no_auto_provision and control_url are left unexplained in both places.

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 ('Register one app-specific recipe with the supplied overrides, then ensure the background service') and draws hard boundaries: 'template_apply registers a fixed multi-service stack instead' and 'Does not configure, install or probe the third-party app.' An agent can distinguish it from template_apply and recipe_plan without opening either 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 sequences it after another tool ('Use recipe_apply after reviewing recipe_plan') and names the alternative plus the condition that selects it ('template_apply registers a fixed multi-service stack instead'). When/when-not routing is fully specified.

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