@littlebigbrain/mcp

lbb_fit_sources_delete

DestructiveIdempotent

Delete a fit source to stop its class reading while keeping its filed suggestions; requires client approval and sends nothing if declined.

Instructions

Delete a fit source: the fit stops reading its class. The suggestions it filed stay. The server asks the person to approve it through the client (MCP form elicitation) and sends nothing when they decline (approval_declined). A client that cannot show the question gets approval_required and nothing is sent, unless the MCP server's environment sets LBB_MCP_DESTRUCTIVE=allow.

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": "lbb_fit_sources_delete"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The fit source name.
`graph`	No	Graph to target; defaults to the connection's graph
`detail`	No	Response detail level. Defaults to compact.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.16.0Oct 29, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / confirm

Removed value: -{
-  "description": "The same name again, to confirm.",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "name",
-  "confirm"
-]New value: +[
+  "name"
+]

Addedv0.14.0Oct 14, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes far beyond the destructiveHint/idempotentHint annotations: it discloses what is destroyed vs preserved (suggestions stay), the required approval via MCP form elicitation, the decline path (approval_declined, nothing sent), the client fallback (approval_required), and the environment override LBB_MCP_DESTRUCTIVE=allow. This is unusually rich behavioral context for a mutation tool.

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-loads the core action and consequence, then layers the approval mechanics. Every sentence is substantively useful, though the approval-flow prose is dense and could be tightened without losing meaning.

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 destructive tool with no output schema, it fully covers consequences, the human approval requirement, error states, and the escape hatch. An agent has everything needed to call it correctly and predict outcomes.

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%, so name, graph, and detail are already documented in the schema. The description adds no parameter-specific meaning (no clarification of what 'name' references or how 'detail' affects the approval output), so the baseline 3 applies.

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 ('Delete a fit source') and immediately clarifies the effect ('the fit stops reading its class. The suggestions it filed stay'), which distinguishes it from list/manage siblings like lbb_fit_sources and lbb_fit_sources_manage. An agent knows exactly what operation this is 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 Guidelines3/5

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

The description describes consequences and the approval flow, implying this is a careful destructive action, but never states when to use this versus the manage sibling or when-not to use it. The usage context is implied rather than made explicit.

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