Skip to main content
Glama

Delete question

delete_question
Destructive

Delete a single item from a form by code — a question, a page break (Breaker) or a display block (Statement / Swiper). Deleting the last one is allowed (a form can be an empty shell). In the ai_quiz scene, {{code}} references to the deleted question are also removed from report.aiReport.instructions.

Input Schema

NameRequiredDescriptionDefault
codeYesThe code of the question to delete
formIdYesThe form ID the question belongs to

Output Schema

NameRequiredDescriptionDefault
formIdNoThe form that was edited
deletedCodeNoThe question code that was removed
remainingCountNoQuestion / page-break count left in the form

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the description correctly spends its words elsewhere: it discloses that deleting the last element is permitted (a form can be emptied) and, importantly, that {{code}} references are stripped from report.aiReport.instructions in the ai_quiz scene. That is exactly the kind of non-obvious side effect an agent needs before calling a destructive 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?

Three short sentences, front-loaded with the core action, then the edge case, then the side effect. No filler, though the mid-sentence type enumeration makes the first sentence slightly dense.

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 two-parameter destructive tool with an output schema, the description covers what gets removed, the empty-form edge case, and cross-entity cleanup. Missing only failure modes (e.g., unknown code) and whether the form must be in a draft/editable state.

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 coverage is 100%, so both parameters are already documented; the description adds only that deletion is keyed by code and scoped to a form. No format, uniqueness, or error semantics for code are added beyond 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 (delete) and the precise resource (a single item identified by code), and enumerates the item kinds it applies to (question, Breaker, Statement/Swiper). This clearly separates it from delete_form (whole form) and update_question (modify rather than remove).

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 'single item by code' framing implies it is not the whole-form delete and not a modification, but no sibling is named and no explicit when/when-not guidance is given. The ai_quiz note hints at a conditional context but is framed as a behavior, not a usage rule.

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