Skip to main content
Glama
Sign In
Quiet File Team MCP

Quiet File Team MCP

by pandadad0214
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

draft_workflow

Read-onlyIdempotent

Drafts a fictional practice workflow with ordered steps, acceptance checks, and warnings for an empty disposable folder, helping teams rehearse tasks offline without production data.

Instructions

Draft a fictional lead/builder/helper task, board and pair exercise; unlike explain_method, return practice steps and acceptance checks. Use only in an empty disposable default-roster folder, not as production history or an executable fixture. Free offline template computation with no network or paid API, bounded work and unbenchmarked latency. Objective is treated as quoted prose, never executed; sensitive-shaped text is rejected heuristically. Returns scenario, ordered steps, acceptance checks and warnings.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "draft_workflow"
  }
}

Input Schema

NameRequiredDescriptionDefault
objectiveNoShort fictional, non-sensitive practice objective; no account data, credentials or real history.Sort a sample inbox

Output Schema

NameRequiredDescriptionDefault
stepsYes
scenarioYes
warningsYes
acceptanceYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent and closed-world, and the description adds genuinely new traits: free offline template computation, no network or paid API, bounded work, unbenchmarked latency, objective never executed and sensitive-shaped text rejected heuristically. The heuristic rejection note is especially valuable because it warns the agent a valid-looking objective may still fail.

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?

Purpose and sibling contrast are front-loaded, and the constraint sentences are packed but each carries non-redundant information. The middle clauses ('bounded work and unbenchmarked latency', 'quoted prose') are compressed to the point of being terse, which costs some readability.

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 single-parameter, closed-world tool with annotations and an output schema, this is close to complete: safety, environment preconditions, cost model and failure heuristics are all present. Listing the return shape (scenario, steps, checks, warnings) is mild redundancy against the output schema but reinforces the contrast with explain_method.

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?

With one parameter at 100% schema coverage the baseline is 3; the description goes further by stating the objective is treated as quoted prose and never executed, and that sensitive-shaped text is rejected. That explains the failure mode the schema's 'non-sensitive' wording only hints at, though it adds no length or format detail.

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 verb and resource are specific: draft a fictional lead/builder/helper task, board and pair exercise, and it explicitly contrasts with explain_method (steps and acceptance checks vs. explanation). The phrasing is jargon-dense ('default-roster folder', 'pair exercise'), so the deliverable takes a read to parse, but it is not a restatement of the name.

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 gives an explicit inclusion condition (empty disposable default-roster folder) and two exclusions (not production history, not an executable fixture), plus the sibling contrast. It does not state what to do when the folder is non-empty or how it relates to draft_owner_batch, which keeps it short of a 5.

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