kutt-mcp

kutt_links

Destructive

Manage Kutt short links: list, create, update, delete, and read stats, with preview-first guarded writes.

Instructions

List, create, update, delete, and read stats for Kutt short links. List query is limit, skip, all, and source-supported search. There is no native GET /links/{id}. Writes run only when confirm is true and KUTT_ALLOW_WRITES=true. Omit confirm or pass false for a preview that sends nothing. Actions: list, create, update, delete, stats.

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

Input Schema

Name	Required	Description
`id`	No	Link UUID for update, delete, and stats.
`all`	No	Documented admin-all query. v3.2.6 GET /links still scopes to the user.
`skip`	No
`limit`	No
`reuse`	No	Reuse an existing link with the same target. False is sent as false.
`action`	Yes	Kutt operation to call.
`domain`	No	Custom domain address owned by the user.
`search`	No	Source-supported search query on GET /links. Not listed in OpenAPI.
`target`	No	URL to shorten or the updated target.
`address`	No	Updated short path on update.
`confirm`	No	Boolean true runs the write when KUTT_ALLOW_WRITES is true. Omit it or pass false for a dry-run preview that sends nothing. The string true is rejected.
`password`	No	Password to protect the short link.
`customurl`	No	Custom short path on create.
`expire_in`	No	Expiration such as 2 minutes, 8h, or 42 days.
`description`	No	Link description. Empty string is sent as-is. Official edit treats falsy description as unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare a destructive, non-idempotent, open-world write surface, and the description adds the exact gate that determines whether a call mutates anything (confirm plus the KUTT_ALLOW_WRITES env flag) and the default dry-run behavior that sends nothing. It also discloses a real API gap ('There is no native GET /links/{id}') so the agent won't assume a per-id read exists. That is substantial disclosure beyond structured fields.

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?

Four sentences, front-loaded with the action surface, then list semantics, then the missing-endpoint caveat, then the write gate. No sentence is redundant and the highest-risk information (writes need confirm) is stated plainly rather than buried.

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 15-parameter, five-action tool with no output schema, the definition covers the critical unknowns: action list, list query params, the read gap, and write gating. The main remaining gap is that the stats action's return shape is never characterized, which matters precisely because no output schema exists to describe it.

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 already 87%, so the baseline is 3; the description still adds meaning by naming which parameters drive the list action and flagging that search is source-supported rather than in OpenAPI. It does not clarify how the many write-only parameters (target, customurl, address, expire_in, reuse) differ between create and update, leaving some action-parameter mapping to the schema.

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 set (list, create, update, delete, stats) against a specific resource (Kutt short links) and closes with an explicit action enum restatement. The resource is unambiguous against kutt_domains and kutt_info, so an agent can route 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 concrete operational rule for the risky path: writes only fire when confirm is true and KUTT_ALLOW_WRITES=true, and omitting confirm yields a safe preview. It also scopes the list action to limit, skip, all, and search. It does not discuss when to prefer list vs stats vs the sibling domain tool, so it stops short of full alternative routing.

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

Deploy Server