Skip to main content
Glama

coherra_audit

Run a full memory audit to detect contradictions, duplicates, and stale facts, returning a health score and detailed issues.

Instructions

Run a full Coherra memory audit and return the results.

Scans all entities in Sibyl Memory for three classes of drift:

  • contradiction two names that likely refer to the same fact but carry different values

  • duplicate two entities in the same category with nearly identical values

  • stale an entity whose body.updated_at exceeds the per-category threshold from coherra:config

Side-effects:

  • Seeds coherra:config with default thresholds if absent

  • Writes results to coherra:last_audit (memory_set_state)

  • Appends a coherra_scan journal event (memory_record_event)

Returns: { "ok": True, "timestamp": "", "health_score": 0-100, "entity_count": N, "issue_count": N, "issues_found": [ {severity, category, name, detail, ...} ] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and fully meets it: it lists all side-effects (seeding coherra:config, writing to coherra:last_audit, appending a journal event) and defines each drift class precisely. It also discloses the return shape, so an agent knows exactly what will change and what will come back.

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?

The description is front-loaded with a one-sentence summary, then uses tight bullets for drift classes, side-effects, and return fields. Every line earns its place and the structure makes the long content scannable for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no annotations, the description is complete: it explains what is scanned, what counts as an issue, what side-effects occur, and what the response contains. Nothing needed to invoke the tool correctly is missing.

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 tool has zero parameters and schema coverage is 100%, so there is no parameter ambiguity to resolve. Per the 0-parameter baseline, this dimension is satisfied without needing extra explanation.

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?

The description states a specific action ('Run a full Coherra memory audit') and names the exact resource (Sibyl Memory) with three concrete drift categories. This makes the tool clearly distinct from siblings like coherra_repair, coherra_recall, and coherra_list.

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?

The description establishes clear context: this is the diagnostic tool for detecting contradiction, duplicate, and stale entries across all entities. It does not explicitly name when-not-to-use or point to coherra_repair, but the audit-vs-repair distinction is strongly implied.

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

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/Steve2009729/coherra'

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