Alcoven

What changed

what_changed

Read-only

What is new or changed on the project and what others did: a catch-up since this person last looked in Alcoven (two weeks at most), or everything since a given day, for a status update or the week in review. By default the changes by others; with who set to "everyone", the person's own changes too, each marked as theirs. What is waiting on them comes first, then the changes in what they look after, then the rest.

Input Schema

Name	Required	Description
`who`	No	others (the default): changes by others only. everyone: the person's own changes too.
`since`	No	YYYY-MM-DD. Default: since the person last looked, at most two weeks.
`detail`	No	short, the default: one line for each change (its § address, what changed, who, the day, and what the person asked and did where they said), the first 40 in the answer's order, then how many more. full: up to 150 changes, each with its time and where it was made (in Alcoven, by a push, or from an AI app).
`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.

Output Schema

Name	Required	Description	Default
`more`	No
`changes`	Yes
`waiting`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 26, 2026

addedInput schema / properties / detail

Added value: +{
+  "description": "short, the default: one line for each change (its § address, what changed, who, the day, and what the person asked and did where they said), the first 40 in the answer's order, then how many more. full: up to 150 changes, each with its time and where it was made (in Alcoven, by a push, or from an AI app).",
+  "enum": [
+    "short",
+    "full"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / changes / items / properties / asked
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / changes / items / properties / did
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / more
```
Added value: +{
+  "type": "number"
+}
```

First observedOct 22, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, non-destructive, closed-world, so the safety profile is covered. The description still adds real behavior: default scope excludes the person's own changes unless who=everyone, each item is marked as theirs, and results are ordered as waiting-on-them first, then their area, then the rest. It does not mention rate limits or volume caps beyond the detail-mode counts, which are already in the schema.

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?

Three sentences, front-loaded with the core purpose before defaults and ordering. Dense but every clause carries information; the only friction is unexplained internal jargon like '§ address' and 'what the person asked and did where they said', which assumes prior knowledge of the product.

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, the description need not describe return values, and it covers scope defaults, the time window, and result ordering — enough to call it correctly. It could still flag what happens when nothing has changed or how the two-week cap interacts with an explicit since date.

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 100% and each parameter already carries its own description, so the burden is on the schema. The description restates the who=everyone default and the two-week since fallback almost verbatim from the schema, adding little beyond it; the 'each marked as theirs' note is the only genuinely new semantic. Baseline 3 is correct here.

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 concrete verb-plus-resource: what is new or changed on the project and what others did, plus the catch-up framing and a status-update use case. An agent can tell it is a scoped activity feed rather than a full audit log. It never names a sibling (history, search) explicitly, so the differentiation is implied rather than stated.

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?

Gives explicit triggering contexts: a catch-up since the person last looked (two weeks at most), or a status update / week in review over an arbitrary day. That is clear when-to-use guidance. It stops short of saying when not to use it or pointing at alternatives such as history or search for older or narrower lookups.

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?