Quiet File Team MCP

Overview Schema Source Related Servers Discussions Admin

draft_owner_batch

Read-onlyIdempotent

Structures supplied owner-decision questions into a bounded review batch before an authorized owner review, merging duplicates and flagging unresolved task IDs.

Instructions

Structure supplied owner-decision questions into a bounded review batch; unlike draft_workflow, organize decisions rather than simulate job execution. Use before an authorized owner review, never to send messages, infer approval or invent answers. Free offline text processing, no network or paid API and unbenchmarked short latency. Identical explicit questions merge task ids; missing questions or cap overflow preserve unresolved references. Returns questions, unresolved ids and warnings; summaries alone do not establish a decision.

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": {
      "items": "<items>"
    },
    "name": "draft_owner_batch"
  }
}

Input Schema

Name	Required	Description	Default
`items`	Yes	Generic unresolved task summaries with original ids and optional explicit questions.
`max_questions`	No	Maximum deduplicated questions to return; overflow ids are marked unresolved.

Output Schema

Name	Required	Description	Default
`warnings`	Yes
`questions`	Yes
`unresolved_task_ids`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, closed-world and non-destructive behavior, yet the description still adds real context: offline text processing with no network or paid API, dedup/merge semantics for identical explicit questions, and that missing questions or cap overflow leave ids unresolved. The return-value sentence ('Returns questions, unresolved ids and warnings') is partly redundant with the output schema, and 'unbenchmarked short latency' is a vague hedge, keeping it below a 5.

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 dense sentences, front-loaded with purpose then constraints then behavior, with no filler sentences. It is tight but heavily compressed, and phrases like 'unbenchmarked short latency' and 'summaries alone do not establish a decision' take parsing effort without crisp operational value.

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?

With an output schema present, rich annotations, and fully documented parameters, the description covers the remaining burden: purpose, guardrails, merge/overflow behavior, and the epistemic caveat that summaries alone do not establish a decision. Nothing an agent needs to invoke this correctly 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; the description nonetheless explains what max_questions actually does behaviorally (deduplicated cap with overflow ids marked unresolved) and that identical explicit questions merge task ids. That adds meaning the schema does not convey, though item-level field semantics are left entirely to 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?

The first clause gives a specific verb and resource ('Structure supplied owner-decision questions into a bounded review batch') and immediately contrasts it with the sibling draft_workflow ('organize decisions rather than simulate job execution'). An agent can distinguish this from draft_workflow without opening either schema.

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 states explicit timing ('Use before an authorized owner review') and explicit exclusions ('never to send messages, infer approval or invent answers'), plus the routing condition versus draft_workflow. Both when-to-use and when-not-to-use are covered.

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

Deploy Server