Skip to main content
Glama
rgdevment

Tisty

by rgdevment
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Say a document has had its day, which is how a document gets deleted

flag_doc

Marks documents for deletion review, recording the reason and replacement location so a person can inspect and remove them; batch-mark copies together.

Instructions

The tool for «delete this document», and the only one: you cannot delete, so you mark and the person deletes. Mark a document you found is no longer worth keeping — a copy of another, notes folded into a living document, a handover for a flow that was retired — with its reason, where what it said lives now in instead, and in body what makes it old and how you know. Several copies of one thing go in one call, marked alike, so the person settles the set with one click. The mark changes nothing: the document reads the same, stays where it is, and the person sees the mark when they open it. Deleting it and taking the mark off are theirs, from the window; archive_doc puts it away only when they ask for that. One mark at a time — a document already marked is refused until the person has looked, and in a set it is skipped and named.

Input Schema

NameRequiredDescriptionDefault
docYesThe id of the document to mark, as `docs` hands it back — an opaque name like `q7ntmzbm-0001`, not its title. A list of ids marks them all alike in one go
bodyYesWhat makes it old and how you know, in the person's language: what it describes that no longer exists, and what replaced it
reasonNoWhy it has had its day: a duplicate of another, moved into another (only once what it holds worth keeping is there), superseded by another, wrong, obsolete, or a scratch nobody needs
insteadNoThe id of the document or the task that holds what it said now. Needed with duplicate_of, moved and superseded

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so well: it explains that the mark changes nothing about the document content or location, that the person sees it when opening, and that deletion/unmarking remain human actions. It also discloses refusal semantics for already-marked documents and skip-and-name behavior within a batch.

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 first sentence front-loads the core purpose and the rest is information-dense, with each major clause adding behavioral or usage context. The ornate phrasing makes it longer and more indirect than necessary, but there is little outright filler.

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?

It covers state effects, human-in-the-loop deletion, batch behavior, and refusal semantics, which is substantial for a no-annotation, no-output-schema tool. The only notable gap is that it does not explicitly describe the tool's return/confirmation format beyond implying skipped documents are named.

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 the schema already documents doc, body, reason, and instead thoroughly, including enum values and required combinations. The description reinforces the meaning of reason/instead/body but adds little syntax or constraint detail beyond what the schema provides.

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 states a specific verb and resource: marking a document as no longer worth keeping, with the explicit framing that this is how deletion is proposed because the agent cannot delete. It distinguishes the tool from siblings by naming archive_doc and by explaining that deleting/removing the mark is done by the person in the UI.

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

Usage Guidelines5/5

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

It gives clear when-to-use examples (duplicate, notes folded into a living document, handover for a retired flow) and explicit exclusions: archive_doc is only for putting away when asked, and actual deletion/unmarking is the person's job. It also explains batching multiple copies into one call and the refusal behavior for already-marked documents.

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