Skip to main content
Glama

ap_delete_records

ap_delete_records
Destructive

Permanently delete one or more records by their IDs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tableIdYesID of the table the records belong to. Use ap_find_records to find it.
recordIdsYesArray of record IDs to delete. Use ap_find_records to find them.
displayNameNoShort approval prompt shown to the user (e.g. "Delete 3 records from Emails table"). Must include what the action does and the target name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds 'Permanently', which usefully confirms there is no recovery path, but it says nothing about cascading effects, behavior on unknown IDs, or partial-failure semantics for a bulk operation.

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?

A single front-loaded sentence with zero filler; the destructive intent is immediately clear. It is efficient, though arguably too terse to carry much operational detail.

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 bulk destructive tool with no output schema but fully documented parameters, the description is minimally viable. It omits details an agent would want before calling it, such as partial-failure behavior, whether deleted records can be restored, or return/confirmation shape.

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 all three parameters (tableId, recordIds, displayName) are already documented in the schema itself. The description contributes no additional parameter meaning beyond the one-word ID-based scope, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb ('delete'), resource ('records'), and scope ('one or more ... by their IDs'), including the permanence qualifier. It does not differentiate itself from siblings like ap_delete_table or ap_update_record beyond the resource noun, so it stops short of a 5.

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?

The description gives no when-to-use or when-not-to-use guidance, no mention of alternatives such as ap_update_record for modifying rather than removing data, and no stated prerequisites. The only routing hint ('Use ap_find_records to find it') lives in the schema, not the description.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources