Alcoven

Run an outside agent's tool

use_agent

Destructive

Runs something at an outside agent's service for the person (a report, a search, a change there): runs one tool of an outside agent on the project, at its own service, on the project's sign-in there, and records what it sent and the answer on the project. A tool the project allows to run at once does so; a tool set to ask first asks the person to confirm in this AI tool, or answers with a preview and a proposal id. Returns the service's answer, marked as its text, and the § address where it is recorded. 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.
`tool`	Yes	The tool's exact name.
`what`	No	One line in the person's words of what the call does, like "Add the 12 negative keywords to the brand campaign". Needed for a tool that asks first: the person sees it before saying yes, and Changes shows it.
`again`	No	True only when the person wants the same call run again after it ran in the last ten minutes.
`agent`	Yes	The outside agent: its name or its member id, as open_project lists it.
`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.
`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.
`arguments`	No	The tool's inputs, as its input schema names them.
`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
`at`	No
`cut`	No
`ran`	Yes
`tool`	No
`agent`	No
`answer`	No
`record`	No
`status`	No
`preview`	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

A3.6/5.0

Behavior4/5

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

Annotations already flag destructiveHint, openWorld and non-idempotency, so the bar is lower; the description still adds real context beyond them. It discloses that the call runs on the outside service under the project's sign-in, that both the request payload and the answer are recorded on the project at a § address, and that ask-first tools may block on human confirmation or return a proposal id. It does not spell out what side effects may occur at the outside service, which is why it is not a 5.

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?

The opening sentence is front-loaded and clear, but the first clause restates the same idea twice ('Runs something at an outside agent's service for the person ... runs one tool of an outside agent'). The trailing sentence 'For people who write to the project' is vague and does little work.

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?

With an output schema present, return values need not be explained, yet the description does note the answer is returned as the service's text with its § address. Annotations cover the risk profile and the schema covers all parameters, so the description's remaining job is the execution/confirmation model, which it covers. The main gap is the absence of explicit routing to the confirmation sibling.

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 carries the meaning of all ten parameters including the nested arguments object. The description adds no parameter-level guidance of its own (no clarification of agent, project, again, or did semantics). Baseline 3 applies when the schema does the heavy lifting.

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: runs one tool of an outside agent, at its own service, on the project's sign-in. It also distinguishes the tool from the confirmation sibling by describing the ask-first path that yields a preview and proposal id. The parenthetical 'a report, a search, a change there' adds concreteness, though no sibling is named outright.

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 explains the two execution modes (runs at once vs asks first, returning a preview/proposal id), which implies when the flow will divert to a confirmation step. But it never names confirm_agent_call or agent_tools, nor states when to reach for this tool rather than those. Usage is implied rather than prescribed.

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?