activate 须用户明确确认开始首期、提供当前 policy_version 与稳定幂等键，Key 须有显式 activate 权限；查询不自动激活。也可对本人 EveryData 采集结果提交固定配方清洗、取消任务或删除结果。submit 只接受recipe/source/version/selected_fields/options 和稳定 idempotency_key，不接受任意 prompt、model、tools 或 URL；任务由服务器稍后执行。清洗不扣钱包，但受充值权益、账户级 5 RPM、并发 5、每日 1,000 与首期 30,000 成功单元限制。超时或 unknown 不得换幂等键重发；先读原任务。delete_result 会立即使正文不可读。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already flag mutation/destruction/idempotency, and the description goes beyond them: explicit user confirmation for activate, account-level rate limits, asynchronous execution, durable idempotency-key rules on timeout/unknown, and immediate unreadability after delete_result. No contradiction with the annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and packed with high-value caveats, with no filler. It could be more scannable if split into per-action bullets, but each clause earns its place and the most safety-critical activation warning is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a polymorphic action tool with no output schema, the description covers the main behavioral risks, async submission, rate limits, idempotency recovery, and destructive side effects. It leaves some details to the schema and sibling read tool (e.g., exact field formats, how to query status), but the essential invocation decisions are supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides constraints like idempotency_key pattern and recipe enum, and the description adds semantic meaning: idempotency keys must be stable and not swapped after timeout/unknown, submit only accepts recipe/source/version/selected_fields/options, and activate requires confirm_activation/policy_version. This is meaningful value beyond the schema, though not every field is individually described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names concrete actions (activate, submit fixed-recipe cleanup, cancel, delete_result) and the target resource (the user's own EveryData collection results), so an agent can tell this is the mutation counterpart to everyinfra_data_cleanup_read. It is much more specific than the tool name and clearly distinguishes the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-not guidance ('查询不自动激活', 'submit 只接受...', '不接受任意 prompt/model/tools/URL') and tells the agent to read the original task before retrying. It does not name sibling tools directly, but the exclusions are strong enough to route an agent away from chat/free-form call usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.