Alcoven

Add or update a skill

add_skill

Destructive

Installs or updates a skill on the project. Adds a skill from Alcoven's public directory to the project, as skills//SKILL.md with the documents in its folder, or updates one added from the directory to its newest version. skill takes the name of one of Alcoven's own (like ux-designer), @handle/name for one a person published, its alcoven.co/skills address, or words to find one; with words it returns the best matches, most used first, and adds nothing. Returns a preview of the whole skill, who published it and what every AI on the project will be given; nothing is written until the person confirms. This tool adds skills only from the directory; publishing happens in Alcoven, on People and agents. For people who write to the project.

Input Schema

Name	Required	Description
`did`	No	What the person did themselves in this work, in a few words they agree with: what they chose or decided, what they corrected, rewrote or wrote, what they checked and against what. Start with the verb, in the past tense, in their language: "Chose the three-step plan; fixed the March totals; rewrote the opening". Say nothing of what you did, what they did not do, how long it took, or a share of the work. Pass no did when their part was the request and the yes. Everyone who sees the change reads it, people outside the team included. At most 300 characters.
`read`	No	The § addresses you read for this work, kept with asked. Alcoven adds what it saw you read on this project since you last wrote on it, going back two hours at most.
`asked`	No	What the person asked for, in their own words, as they said it: their request only, never the rest of the conversation, and left out when they do not want it shared. It goes on the project with the change, so everyone who sees the change, and their AIs, see why it was made.
`skill`	Yes	A skill's name, like ux-designer; @handle/name for one a person published, like @omar-k/ux-review; its alcoven.co/skills address; or words to find one, like "release notes".
`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.
`replace`	No	True when the person wants this skill in place of the project's own skill of that name, or the newest version in place of the project's changed copy.
`asked_from`	No	Where the request came from, when the person says so, in a few words: "Tuesday's call with the bank", "Ines's email".

Output Schema

Name	Required	Description	Default
`skill`	No
`address`	No
`applied`	Yes
`matches`	No
`preview`	No
`version`	No
`proposal`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

addedInput schema / properties / did

Added value: +{
+  "description": "What the person did themselves in this work, in a few words they agree with: what they chose or decided, what they corrected, rewrote or wrote, what they checked and against what. Start with the verb, in the past tense, in their language: \"Chose the three-step plan; fixed the March totals; rewrote the opening\". Say nothing of what you did, what they did not do, how long it took, or a share of the work. Pass no did when their part was the request and the yes. Everyone who sees the change reads it, people outside the team included. At most 300 characters.",
+  "maxLength": 300,
+  "type": "string"
+}

First observedOct 22, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Adds real behavior beyond the annotations: the two-phase flow (returns a preview of the whole skill, publisher, and what every AI on the project will be given; 'nothing is written until the person confirms') and the on-disk target path. This meaningfully softens the picture given by destructiveHint=true. The one gap is that the confirming step is never named, so the agent doesn't know which tool completes the write.

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?

Front-loaded with the action and tightly packed with useful detail; every clause carries information. The sentences are long and run together (write path, search behavior, preview flow, exclusions in one block), and the trailing 'For people who write to the project' is slightly loose, costing 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?

An output schema exists and annotations carry the safety profile, so the description's burden is modest and it meets it: it covers what is created, what is replaced, the preview return, and the search fallback. It stops short of naming the confirmation mechanism that gates the actual write, which is the one thing an agent still needs to infer.

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, but the description adds genuinely new semantics for `skill`: the accepted forms and the fact that word-based input triggers a ranked, most-used-first search that writes nothing. The `replace` intent is also hinted at ('updates one added from the directory to its newest version'). The remaining params (did, read, asked, asked_from, project) are already richly documented in the schema and get no added treatment.

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?

States a specific verb and resource ('Installs or updates a skill on the project') and immediately scopes it: it adds from the public directory, writes skills/<name>/SKILL.md, or updates an existing directory-sourced skill. It also explicitly excludes publishing ('publishing happens in Alcoven, on People and agents'), so an agent can separate it from sibling write tools like add_document or add_note.

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?

Gives concrete when-to-use routing for the `skill` argument: an exact name, @handle/name, an alcoven.co/skills address, or search words — and states that with words it only returns matches 'and adds nothing'. It also states the when-not: this tool does not publish skills. That is explicit conditional guidance an agent can act on without inference.

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?