Alcoven

Put confirmed edits on the project

apply_edits

Destructive

Applies edits, or a skill, the person saw in a preview and said yes to: puts them on the project, under this person's name, by the proposal id that came with the preview. A proposal holds for 24 hours, goes on once, and is refused when a document changed since. For edits and skills the person has seen and said yes to.

Input Schema

Name	Required	Description
`project`	No	The project's slug, from open_project, like acme. Not needed when a § address names the project, or when the person is on one project.
`proposal`	Yes	The proposal id edit_document or add_skill returned.
`leave_out_ask`	No	True when the person wants what they asked left out of the project.
`leave_out_did`	No	True when the person wants what they did left out of the project.

Output Schema

Name	Required	Description	Default
`writes`	No
`applied`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

addedInput schema / properties / leave_out_did

Added value: +{
+  "description": "True when the person wants what they did left out of the project.",
+  "type": "boolean"
+}

First observedOct 22, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The annotations already declare destructiveHint=true and idempotentHint=false, and the description adds important behavior beyond them: the proposal is valid for 24 hours, applies only once, is refused when a document has changed since preview, and is attributed under the person's name. These are material operational details an agent needs before invoking a destructive mutation.

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 description is front-loaded with the core action and then adds key constraints such as expiry and single-use behavior. The final sentence repeats the confirmation condition already stated at the start, so it is slightly redundant, but overall it remains compact and useful.

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?

For a destructive mutation with an output schema and annotation coverage, the description supplies the crucial behavioral context: confirmation prerequisite, proposal lifetime, single application, conflict refusal, and attribution. An agent has enough information to know whether and how to call it without needing return-value details in the description.

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 each parameter, including the optional project slug, required proposal uuid, and leave_out flags. The description reinforces that the proposal id comes from the preview, but it does not add meaning for the leave_out parameters 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: applying confirmed edits or a skill from a preview to a project by proposal id. It distinguishes this operation from previewing or creating edits by tying it to a person's explicit confirmation and an existing proposal.

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?

The description clearly says when to use it: for edits and skills the person has seen in a preview and said yes to. It also notes that proposals expire after 24 hours and are refused if a document changed, giving useful preconditions, though it does not explicitly name sibling alternatives such as edit_document or add_skill.

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

All Alcoven tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?