Skip to main content
Glama
RPasquale

lightbulb-mcp

by RPasquale
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

clio_delete_damage

DestructiveIdempotent

Delete damage records in Clio via the governed connector, using project-scoped authentication and idempotency keys to ensure accurate, repeatable removals.

Instructions

Clio connector operation delete_damage (platform tool clio.delete_damage).

Routes only through the exact project/account governed connector authority.

Args: arguments: JSON string of arguments for the connector operation. project_id: Authenticated Project UUID. project_ref: Exact project correlation reference. connector_account_ref: Project-bound connector account alias. idempotency_key: Stable business-action identity. effect: Claimed read or write effect; Spring verifies it. approval_ref: Approved platform task UUID when resuming a write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
effectNo
argumentsNo{}
project_idNo
project_refNo
approval_refNo
idempotency_keyNo
connector_account_refNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.1
    • addedInput schema / properties / approval_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Approval Ref"
+}
    • addedInput schema / properties / connector_account_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Connector Account Ref"
+}
    • addedInput schema / properties / effect
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Effect"
+}
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Idempotency Key"
+}
    • addedInput schema / properties / project_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Id"
+}
    • addedInput schema / properties / project_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Ref"
+}
  2. First observedv0.1.0

TDQS

B3/5.0
Behavior4/5

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

Annotations already indicate destructive and idempotent behavior, so the bar is lower. The description adds meaningful context beyond those annotations: the call is restricted to the exact project/account governed connector authority, the effect parameter is a claimed read/write status that Spring verifies, and approval_ref is an approved platform task UUID when resuming a write. No contradiction with annotations.

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?

The argument list is clean and front-loaded after a brief contextual line, with no filler. The first line is somewhat redundant with the tool name, but the rest of the description earns its place. The structure makes the parameter roles easy to scan.

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

Completeness3/5

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

For a generic connector envelope with zero schema descriptions, the description covers every parameter and supplies routing/approval context. However, it never explains what 'damage' represents in Clio, how to structure the `arguments` JSON for a delete operation, or which sibling tools provide the relevant damage ID and context. The output schema may cover return values, but selection-time domain context is still thin.

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 description coverage is 0%, so the description must compensate, and it does by describing all 7 parameters with one-line definitions. Terms like 'Authenticated Project UUID', 'Stable business-action identity', and 'Approved platform task UUID when resuming a write' add useful meaning beyond the bare schema. The 'arguments' description remains generic as 'JSON string of arguments for the connector operation' without domain-specific guidance for damage deletion, so it is not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Clio connector operation delete_damage (platform tool clio.delete_damage)', which essentially restates the tool name without explaining what a 'damage' is or what deletion accomplishes in Clio. The routing sentence and argument list are operational details rather than purpose. It never explicitly states 'Deletes a damage record in Clio' or similar.

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

Usage Guidelines2/5

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

No guidance is given about when to use this tool versus siblings like clio_create_damage, clio_get_damage, clio_list_damages, or clio_update_damage. The only note, 'Routes only through the exact project/account governed connector authority', is a constraint, not a selection criterion or alternative comparison.

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