Alcoven

Search the project

search

Read-only

Finds or looks up where something is, or where the project talks about something: the documents, sections, tasks, notes and files that mention a subject, a person, a client or a contract, by their words. Takes one to five queries, each with terms that must appear and terms that raise the rank (synonyms, other spellings, the other language if the project uses two). Files are found by their name and path, and text files by their words too. Returns § addresses ranked by the words and by how things link to each other, each with its kind, title, headline, author, date and length in tokens: 20 by default, 50 at most. It ranks what matters most and does not list every line that holds a string.

Input Schema

Name	Required	Description
`kinds`	No	Only these kinds. Default: all.
`limit`	No	How many results. Default 20.
`since`	No	Only things changed on or after this day, YYYY-MM-DD.
`until`	No	Only things changed on or before this day, YYYY-MM-DD.
`detail`	No	full, the default: each row with its § address, kind, title, headline, author, date and length in tokens. short: each row with its § address, title, headline, author and date.
`reason`	Yes	What you are looking for and why, in a sentence. Kept with the search.
`folders`	No	Only these top-level folders, like research.
`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.
`queries`	Yes	One to five phrasings of what is looked for. Each is ranked on its own and the rankings are fused by reciprocal rank, so what several phrasings find comes before what one finds; two to four phrasings in other words (other word forms, synonyms, the other language) find more in a large project than one.

Output Schema

Name	Required	Description	Default
`rows`	Yes
`engine`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 26, 2026

addedInput schema / properties / detail

Added value: +{
+  "description": "full, the default: each row with its § address, kind, title, headline, author, date and length in tokens. short: each row with its § address, title, headline, author and date.",
+  "enum": [
+    "short",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / queries / description

Added value: +"One to five phrasings of what is looked for. Each is ranked on its own and the rankings are fused by reciprocal rank, so what several phrasings find comes before what one finds; two to four phrasings in other words (other word forms, synonyms, the other language) find more in a large project than one."

addedInput schema / properties / until

Added value: +{
+  "description": "Only things changed on or before this day, YYYY-MM-DD.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

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 readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavior beyond that: results are § addresses ranked by term match and by inter-item links, fused across phrasings by reciprocal rank, 20 default with a 50 cap, and it deliberately does not return every string match.

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?

It is a single front-loaded block with no wasted preamble, but it is dense and repeats structured facts already in the schema, notably the 20/50 limit and the detail-level field list. Those sentences crowd out more valuable routing guidance against sibling tools like grep and related.

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?

For a 9-parameter search tool with an output schema and full annotation coverage, the description supplies the query-construction strategy and ranking model an agent needs. The remaining gap is the absence of explicit sibling routing, which matters given how many retrieval tools (grep, related, read, list) sit beside it.

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 baseline is 3, but the description adds meaning beyond the schema by explaining that 'must' terms must appear while 'should' terms raise rank (synonyms, other spellings, a second language) and that files match on name/path rather than content. The multi-query ranking fusion is also explained, which the schema only hints at.

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 and resource set: finds/looks up documents, sections, tasks, notes and files by their words. It also carves out a behavioral boundary ('does not list every line that holds a string'), which implicitly separates it from grep, but no sibling is named explicitly, so an agent must infer the routing rather than read it.

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 clear usage context ('where something is, or where the project talks about something') and prescribes query strategy — one to five phrasings, two to four with synonyms or the other language for large projects. It stops short of an explicit 'use X instead when...' rule against grep or related, so the alternative routing stays implicit.

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?