Skip to main content
Glama
Sign In
Fulcra MCP Server

Fulcra MCP Server

by fulcradynamics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Delete Records

delete_records
Destructive

Remove up to 500 records from one of your v1 data types by supplying the data type ID and record IDs, so deleted items stop appearing in get_records within about a minute.

Instructions

Delete records from one of the user's own v1 data types.

Takes the records' ids, as get_records returns them in each record's id (record_data also returns the id of each record it creates). Deleted records stop appearing in get_records within about a minute, for the user and for anyone the type is shared with; anyone who already read them may still have a copy.

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": {
      "data_type": "<data_type>",
      "record_ids": "<record_ids>"
    },
    "name": "delete_records"
  }
}

Input Schema

NameRequiredDescriptionDefault
data_typeYesThe ID of a v1 data type the user owns, e.g. "Event/<uuid>".
record_idsYesThe ids of the records to delete, at most 500.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.18.7
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  2. Addedv1.2.4

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses key behavioral traits: deletions propagate to shared users within about a minute, previously read copies may persist, and only the user's own v1 data types are affected. This is exactly the kind of contextual risk information an agent needs for a destructive mutation.

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?

The description is three tight sentences: purpose first, ID provenance second, deletion effects third. Every sentence adds actionable information with no repetition or filler.

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 but clear annotations, the description covers what is deleted, which IDs to use, ownership constraints, visibility timing, and shared-user impact. No critical call-time context is missing.

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 100%, so the baseline is 3, but the description adds useful provenance for record_ids by explaining they are the IDs returned by get_records and record_data. The data_type parameter is also tied to the user's own v1 data types, reinforcing schema semantics.

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?

The description uses a specific verb and resource ('Delete records') and scopes it to 'one of the user's own v1 data types,' which clearly distinguishes it from file/share deletion siblings. It also names related tools (get_records, record_data) to anchor the operation.

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?

It clearly explains the context for use by specifying that record IDs come from get_records or record_data, and that the data type must be owned by the user. It does not explicitly compare against alternatives such as archive_data_type, so it falls short of a 5.

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