Skip to main content
Glama

Delete a question to my human

delete_ask
DestructiveIdempotent

Delete an answered or expired question to your owner, with its answer, for good. With older_too: true, also every older answered or expired ask of the plan. Questions still waiting for an answer cannot be deleted, and a withdrawn one only after its expires_at. Works after the plan ended too.

Input Schema

NameRequiredDescriptionDefault
ask_idYesask_id from ask_human.
older_tooNotrue: also delete every older answered or expired ask.
instance_idYesUtility instance id from buy or list_utilities.
passport_tokenNoYour amp_ token, only if you have no app sign-in and cannot send a header.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "ask_id": "qst_exampleexampleexample2",
      +    "instance_id": "ask_exampleexampleexample2"
      +  }
      +]
    • changedInput schema / properties / passport_token / description
      Previous value: -"Your amp_ token, only if your app has no sign-in and cannot send it as an Authorization header."New value: +"Your amp_ token, only if you have no app sign-in and cannot send a header."
  2. Changed4 schema fields changed
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / passport_token / description
      Previous value: -"Your amp_ token, only if your client cannot send it as an Authorization header; leave it out when your MCP app signed in."New value: +"Your amp_ token, only if your app has no sign-in and cannot send it as an Authorization header."
    • addedInput schema / properties / passport_token / maxLength
      Added value: +200
    • removedInput schema / properties / passport_token / pattern
      Removed value: -"^amp_(?:s_)?[A-Za-z0-9_-]{43}$"
  3. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / ask_id / description
      Added value: +"ask_id from ask_human."
    • changedInput schema / properties / passport_token / description
      Previous value: -"Leave it out when your MCP app signed in to AgentMart (it is refused then). Otherwise your passport bearer token (amp_...) or session token (amp_s_...), only if your client cannot send it as an Authorization header. A token here sits in your context, so it never authorizes sensitive actions."New value: +"Your amp_ token, only if your client cannot send it as an Authorization header; leave it out when your MCP app signed in."
  4. 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 idempotentHint=true, and the description complements this with the concrete blast radius: the answer is destroyed too, and older_too wipes every older answered/expired ask on the plan. It doesn't state whether deletion is reversible or what the response returns, which the annotations alone can't cover.

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-loaded with the destructive scope and the answer loss, then the older_too cascade, then eligibility rules. Every clause carries information, though the sentence runs long and could be broken for faster scanning.

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?

No output schema exists, but for a destructive delete tool the description supplies the state preconditions, cascade behavior, and post-plan applicability an agent needs before calling. The unstated reversibility and the unnamed withdraw_ask fallback are the only remaining gaps.

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% and each parameter carries its own description, so the baseline is 3. The description restates the older_too semantics, which is marginal added value; instance_id and passport_token are left entirely to the schema.

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?

The description gives a specific verb and resource (delete an answered or expired question to your owner) and scopes the effect to include the answer. It effectively distinguishes from get_ask and withdraw_ask by spelling out which states are deletable, though it never names the sibling alternative explicitly.

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 states the preconditions (answered or expired; not while awaiting an answer; withdrawn only after expires_at) and notes it works after the plan ended. The implicit alternative for pending questions is withdraw_ask, but it's never named, leaving the agent to infer the routing.

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.