Skip to main content
Glama
UnboundCompute

lachesis-mcp

Official

leads

Retrieve cached shape-matcher findings from a prior flow pass, filter by pattern, function, or source position, and get a summary or structured results.

Instructions

Query the flow pass's LEADS in memory -- the shape-matcher findings the 3rd pass already computed and cached, not a fresh cold run. This is the warm counterpart to re-deriving leads by hand every question: the pass is materialized once (via flow_pass), then this filters the held result. No arg: a by-pattern summary plus the honesty fields (whether the run timed out, which functions were truncated) -- an empty result over a partial run is never 'clean'. pattern filters to one bug shape; function to one enclosing function; at locates by source position file, file:line, or file:lo-hi (a lead carries only its function + line, so the file is resolved through the symbol index; a basename or path suffix is enough). Leads are leads, not verdicts -- adjudicate with sources_of/reaches. Calls against one session are serialized; results are bounded and paged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNolocate by source position: file | file:line | file:lo-hi
limitNo
formatNotext (compact, default) | json (structured result page)
offsetNo
patternNokeep only this bug-shape pattern
functionNokeep only leads in this function
Install Server

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description fully discloses core behaviors: cached vs fresh, honesty fields, partial-run caveat, serialization, bounded/paged results, and file resolution semantics. This is exemplar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though lengthy, it packs crucial context (caching, honesty fields, source position resolution, adjudication routing, serialization/paging) with no redundancy. The core purpose is front-loaded, and each clause earns its place.

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?

Covers purpose, usage routing, behavior, parameter semantics, and caveats. Lacks a detailed return shape for text/json, but gives a high-level summary and mentions pagination. Given no output schema, the description provides sufficient guidance for invocation, though exact lead fields (beyond function+line) are not enumerated.

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?

The description enriches parameter semantics beyond the schema: it explains the `at` format and file resolution process, clarifies that `pattern` and `function` filter the cached result, and describes the no-arg summary behavior. Even though schema covers most parameter names, the description adds usage context that improves correct invocation.

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 (query), resource (flow pass's LEADS in memory), and explains it's not a fresh cold run but a filtered view of a cached result. Also names siblings (flow_pass, sources_of/reaches) for differentiation.

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?

Explicitly states the tool is a warm counterpart to a cold run, references flow_pass for materialization, and directs to sources_of/reaches for adjudication, effectively routing usage. Also mentions session serialization and paging constraints.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/UnboundCompute/lachesis'

If you have feedback or need assistance with the MCP directory API, please join our Discord server