Skip to main content
Glama

奇妙生产力 · Qimiao Productivity

prepare_task

免费准备私有任务草稿(没有附件也可用);媒体工具必须传tool_id,返回分块上传协议和用户上传页,返回草稿凭据、15分钟直传地址与用户上传页。没有付款、不会运行任务。保存草稿凭据,上传只用HTTP文件字节,不让模型抄Base64。

Input Schema

NameRequiredDescriptionDefault
tool_idNo

Output Schema

NameRequiredDescriptionDefault
recoveryYes
next_stepYes
schema_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only say write, non-idempotent, non-destructive, open-world. The description adds real substance: no charge occurs, no task is executed, credentials must be saved, the direct upload address expires in 15 minutes, and uploads must be raw HTTP bytes rather than Base64. The repeated mention of the upload page and the jumbled ordering cost it a point.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense and information-rich, but the sentence is a run-on chain of semicolons and '用户上传页' is stated twice in consecutive clauses. The key safety facts ('no payment, no execution') sit mid-paragraph instead of being front-loaded.

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-optional-parameter write tool with an output schema, the description covers the essentials an agent needs: cost, side effects, credential handling, and the upload expiry window. Return-value detail is partly redundant with the output schema but nothing critical is missing.

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 0%, so the description must carry the parameter, and it does partially: it tells the agent tool_id is mandatory for media tools. However, it does not explain the four enum values or what omitting tool_id means for non-media drafts, so the gap is only half closed.

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?

States a specific verb and resource: prepare a private task draft, free of charge, and usable without attachments. It also bounds the scope with 'no payment, will not run the task', which separates it from the ordering/payment siblings, though it never names create_order or quote_order directly.

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?

It gives one conditional rule ('media tools must pass tool_id') and implies the pre-order drafting context via 'no payment / won't run the task', but never explicitly says when to call this versus create_order or what to do after receiving credentials.

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