How do I use credence?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@credence I think the rate limit is 50, but confirm later." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

credence

by Lakshmi-Chakradhar-Vijayarao

Overview Schema Source Related Servers Discussions Admin

Python

Local

Credence

AI doesn't remember what it wasn't sure about. Credence does.

PyPI Python License: MIT

pip install credence-guard
credence demo   # 30-second smoke test, no API key required

[mcp] adds the FastMCP server for Claude Code. Core package has zero hard dependencies.

The problem

You say: "The rate limit is probably around 50 — I haven't confirmed it yet."

Fifteen turns later, Claude writes:

RATE_LIMIT = 50   # no warning. no flag. shipped.

The API rejects every request at 2am. The real limit was 10. Claude forgot you weren't sure.

This isn't hallucination. The model reproduced exactly what it read. What it read had the qualifier stripped — by context compression, fifteen turns back.

Related MCP server: reflect-mcp

What Credence does

Tracks uncertain values the moment you state them. Blocks writes that embed those values until you confirm them.

you say "rate limit is probably 50"
    → observer registers it (before Claude responds)
    → Claude writes: RATE_LIMIT = 50  # ⚠ CREDENCE[unverified]
    → write blocked until you confirm

Every other tool warns. Credence enforces.

What it looks like

# Claude generates this. Credence intercepts before it ships.

class StripeClient:
    API_VERSION  = "2023-10-16"  # ⚠⚠ CREDENCE[stale]: API date versions change on release — verify before shipping
    RATE_LIMIT   = 100           # ⚠  CREDENCE[unverified]: I think Stripe rate limit is around 100 req/min
    TOKEN_EXPIRY = 3600          # ⚠⚠ CREDENCE[stale]: Token/session lifetime values are set by the vendor — verify
    MAX_RETRIES  = 3
    TIMEOUT_MS   = 5000

credence: blocked Edit — 2 unverified value(s)
  → I think Stripe rate limit is around 100 req/min | TOKEN_EXPIRY = 3600
  Verify first, then retry. Use credence_constraints to see all pending.

After you confirm: "Confirmed — rate limit is 100 req/min per stripe.com/docs" → gate clears.

Gate demo

Setup

1. Add to .mcp.json:

{ "mcpServers": { "credence": { "command": "credence-server" } } }

2. Add to .claude/settings.json:

{
  "hooks": {
    "UserPromptSubmit": [
      { "hooks": [{ "type": "command", "command": "python3 -m credence.observer" }] }
    ],
    "PreToolUse": [
      {
        "matcher": "Write|Edit|Bash|NotebookEdit",
        "hooks": [{ "type": "command", "command": "python3 -m credence.hooks" }]
      }
    ]
  }
}

Done. No API key required.

Registry: Credence creates epistemic_registry.db in your working directory. Add *.db to your .gitignore, or set CREDENCE_DB=~/.credence/registry.db to keep it global.
Session tracking: Set CREDENCE_SESSION_ID=my-project to keep constraints stable across directory changes and terminal restarts.
Event log: The gate writes block/allow events to ~/.credence/events.jsonl (local only, never sent anywhere). Set CREDENCE_NO_LOG=1 to disable.
Constraint cap: The registry allows up to 500 constraints per session by default. Override with CREDENCE_MAX_CONSTRAINTS=<n>.

How it works

Two layers, neither requires model cooperation:

Layer	Hook	Role
Observer	`UserPromptSubmit`	Passive listener — registers uncertain values before Claude generates anything
Gate	`PreToolUse`	Blocks writes that embed unverified values

The observer fires before the model processes your message. If you say "I think the rate limit is 50", the registry has that entry before Claude generates a single token.

What gets blocked

credence: blocked Edit — 2 unverified value(s)
  → rate limit is probably 50 req/min | token expires in 3600s
  Verify first, then retry. Use credence_constraints to see all pending.

Once verified, the gate clears.

What Credence does NOT do

Does not verify facts — it cannot tell you if a value is correct
Does not catch uncertainty that was never stated
Does not block the model from saying a wrong value in prose — only from writing it to a file or command

Measured results

46% of uncertainty qualifiers are stripped by Claude Haiku during context compression. Credence blocks 100% of those writes (n=50, bootstrap CI: [0%–0%]).

Validated across 7 open-weight models (Qwen, Mistral, Llama, Phi, Gemma) from 5 organizations: same failure mode, same block rate.

credence demo                     # smoke test, no API key
credence stats                    # false-positive rate from real gate usage
credence feedback 1|2|3           # tag last gate block: correct / noise / skip
python3 -m pytest tests/ -q       # 829 tests
python3 -m evals.latency_report   # P50/P95/P99

Full methodology: docs/TECHNICAL_REPORT.md

Project layout

credence/         pip-installable package
  observer.py     passive UserPromptSubmit hook
  hooks.py        PreToolUse enforcement gate
  mcp_server.py   17-tool MCP server
  registry.py     SQLite constraint store
  memory.py       cross-session persistence
tests/            829 tests
evals/            validation studies + multi-model benchmarks
docs/             technical report, architecture, ETP spec
credence_gate/    Rust gate (alternative to Python hooks.py)
experimental/     Phase 2 work — not yet shipped
paper/            Research paper draft + figures

Research

The scientific basis for Credence is documented in paper/ (EQL / EQLR / FCR).

The companion geometry thesis — on confabulation detection and why the detection axis is dissociable from the causal control axis — lives in a separate repo: → Detection Without Control

Built by

Lakshmi Chakradhar Vijayarao — GitHub · LinkedIn · X

Apache 2.0 License

Available Tools

17 tools

credence_auditA

Per-session epistemic timeline — all constraints (verified and unverified) in chronological order with full certainty trajectory.

Use to answer "what have we tracked this session?" or "what's still open?" before starting an implementation phase.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	The session to audit.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes the output format but does not explicitly state whether the operation is read-only, idempotent, or requires special permissions. It implies safety by being an audit, but could be more explicit.

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?

Two sentences with no wasted words. The first sentence defines the tool's primary function, and the second provides usage context. Front-loaded and efficient.

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?

Given the presence of an output schema and the parameter schema with 100% coverage, the description provides sufficient context for a query tool. With many sibling tools, the description clearly differentiates its purpose. However, it could briefly mention that it is read-only to enhance completeness.

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% with the single parameter 'session_id' described as 'The session to audit.' The description does not add further detail about the parameter beyond the schema, so baseline 3 is appropriate.

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 clearly states the tool returns a per-session epistemic timeline with all constraints in chronological order and certainty trajectory. It specifies the resource (session constraints) and the action (audit), distinguishing it from siblings like credence_scan or credence_verify.

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 provides usage guidance: 'Use to answer "what have we tracked this session?" or "what's still open?" before starting an implementation phase.' This tells the agent exactly when to invoke this tool.

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

credence_autoverifyA

Scan text for natural-language verification signals and auto-verify matching unverified constraints — zero API calls.

When a user says "actually it's 3600", "confirmed: rate limit is 100", or "I checked, the port is 5432", this tool detects those confirmation phrases and automatically marks matching constraints as verified.

Matching: a constraint is a candidate if ≥ 2 non-stopword tokens from the constraint text appear in the confirmation sentence.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	The user or assistant message to scan for confirmations.
`session_id`	Yes	Session whose constraints to check against.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden. It transparently describes the detection logic (matching based on token overlap) and disclosure of zero API calls. No contradictions.

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 concise with three short paragraphs. The main action is front-loaded in the first sentence, and every sentence adds value. No wasted words.

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?

Given that an output schema exists (as per context signals), the description does not need to explain return values. It covers matching logic and usage context. For a tool with 2 parameters, it is complete.

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. The description adds meaning by explaining that 'text' is the user/assistant message and 'session_id' is the session whose constraints are checked, beyond the schema descriptions.

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 clearly states the tool's action: scanning text for natural-language verification signals and auto-verifying matching constraints. It provides specific examples of confirmation phrases, making the purpose distinct from sibling tools like 'credence_verify'.

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 explains when to use the tool (e.g., when a user says confirmation phrases) but does not explicitly state when not to use it or mention alternatives. However, the examples and context imply appropriate use.

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

credence_bandit_statusA

Adaptive compression threshold status (Thompson sampling bandit).

Returns current learned thresholds per session type, or the static defaults if insufficient data has been collected (< 100 sessions).

Returns: status (learning|active), threshold, current_thresholds, message.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

The description discloses the threshold condition (requires 100 sessions for learning) and the return fields. As a read-only status tool, no destructive hints are needed. No annotations existed to contradict, but some details like permissions or rate limits are omitted.

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 concise, using three lines to cover purpose, conditions, and returns. It is front-loaded with the key concept and uses a clear structured list for outputs.

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?

Given no parameters and the presence of an output schema, the description sufficiently explains the tool's function, conditions, and return format. It leaves no ambiguity about what the tool does.

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?

No parameters exist, so the baseline is 4. The description does not need to add parameter info. It effectively explains the tool's behavior without parameter details.

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 clearly states it returns 'adaptive compression threshold status' using Thompson sampling bandit, with specific conditions (learned vs static defaults). It distinguishes from siblings like 'credence_scan' or 'credence_verify' by focusing on compression threshold status.

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?

The purpose implies usage for checking bandit status, but there is no explicit guidance on when to use this tool versus alternatives like 'credence_project_status' or 'credence_memory_snapshot'. No conditions for when not to use are stated.

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

credence_constraintsA

List all unverified constraints for a session.

Use before writing code that may embed user-stated values, or at session end to audit what still needs confirmation.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	Session identifier.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It states the tool lists unverified constraints, implying a read-only operation, but does not disclose any potential side effects, error conditions, or constraints on usage (e.g., session must exist). The output schema exists but is not described here, so the description is minimally transparent.

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 extremely concise at two sentences, with the core action front-loaded. Every word serves a purpose, and there is no redundancy or extraneous information.

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 simple listing tool with one parameter and an existing output schema, the description is sufficiently complete. It covers the primary use case and when to use it, though it could briefly mention the output structure (e.g., what fields a constraint has) to aid understanding.

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?

There is only one parameter (session_id), and its schema already provides a description ('Session identifier.'). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate given 100% schema description coverage.

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 clearly states the tool's function: 'List all unverified constraints for a session.' This is a specific verb-resource combination that distinguishes it from sibling tools like credence_verify or credence_audit, which have different purposes.

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 provides explicit usage guidance: 'Use before writing code that may embed user-stated values, or at session end to audit what still needs confirmation.' This tells the agent when to use the tool, though it does not explicitly mention when not to use it or recommend alternatives.

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

credence_diffA

Compare two texts for numeric contradictions.

Extracts numeric claims from both texts and detects when the same topic context has different values. Optionally checks against verified registry constraints when session_id is provided.

ParametersJSON Schema

Name	Required	Description
`text_a`	Yes	First text (e.g. prior agent response).
`text_b`	Yes	Second text (e.g. new agent response).
`session_id`	No	Optional — check text_b against verified constraints.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It transparently explains that the tool extracts numeric claims, detects contradictions, and optionally verifies against registry constraints. This gives a clear behavioral model without unexplained side effects.

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 concise with two short paragraphs. The first sentence states the core purpose, and the second provides additional detail. Every sentence adds value without repetition or fluff.

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?

Given the tool's simplicity (3 parameters, no nested objects, output schema present), the description sufficiently covers purpose and behavior. Minor omission: it doesn't address what happens if texts have no numeric claims, but overall it's complete.

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%, and the description adds context for each parameter: identifying text_a as 'prior agent response' and text_b as 'new agent response,' and explaining session_id's optional verification role. This enhances understanding beyond the schema.

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 clearly states the verb 'compare' and the resource 'two texts,' with a specific goal of detecting numeric contradictions. This differentiates it from sibling tools like credence_verify or credence_scan, which serve different purposes.

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?

The description mentions optional behavior with session_id but does not provide explicit guidance on when to use this tool versus alternatives like credence_verify or credence_scan. It lacks exclusions or context for selection.

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

credence_gateA

Pre-execution epistemic gate (CP4): block irreversible tool calls that embed unverified constraint values.

Call BEFORE write_file, execute_code, send_request, deploy, or any tool that would embed a user-stated value into code or infrastructure. Uses synonym-expansion to catch paraphrase overlap ("how fast" ↔ "rate limit").

ParametersJSON Schema

Name	Required	Description
`tool_name`	Yes	Name of the tool about to be called.
`session_id`	Yes	Session identifier.
`arguments_summary`	Yes	Brief summary of arguments (omit secrets).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It explains the blocking and synonym-expansion mechanism, but does not disclose what happens when a call is blocked (error or other response), authentication requirements, or side effects. More detail on behavior beyond the stated mechanism would improve transparency.

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 concise with 4 sentences. It is front-loaded with the core purpose ('Pre-execution epistemic gate'), each sentence adds value, and there is no fluff.

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

Completeness3/5

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

The tool has an output schema (not shown) but the description does not explain the return behavior (e.g., what the agent receives when a call is blocked vs allowed). It also does not address practical details like idempotency or error conditions. Given the gate's critical role, more completeness is needed.

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% for 3 parameters. The description does not elaborate on parameter formats or constraints beyond what the schema provides, so it adds marginal value. Baseline 3 is appropriate.

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 clearly states the tool is a 'pre-execution epistemic gate' that 'block[s] irreversible tool calls that embed unverified constraint values'. It specifies the verb (block) and resource (irreversible tool calls), and the purpose is distinct from sibling tools like credence_scan or credence_verify.

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 explicitly says 'Call BEFORE write_file, execute_code, send_request, deploy, or any tool that would embed a user-stated value into code or infrastructure.' This provides clear when-to-use context. It does not explicitly state when not to use, but the positive guidance is strong.

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

credence_marker_healthA

Marker statistics from accumulated session data.

Shows which uncertainty markers are most reliable (high precision) vs. noisy (low precision) based on observed FCR outcomes. Requires 10+ sessions before returning data.

Returns: status (insufficient_data|available), threshold, markers list.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the prerequisite (10+ sessions) and the return structure (status, threshold, markers list). There is no mention of side effects, but as a read-only analytic tool, this is adequate.

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 extremely concise with three sentences: purpose, condition, and return format. No unnecessary words, and the structure is front-loaded with the primary function.

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?

Given that the tool has no parameters and an output schema exists (implied by 'Returns'), the description is well-rounded. It covers the data requirement and output fields, leaving little ambiguity for a simple info-gathering tool.

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 the schema coverage is 100%. Per guidelines, no parameters means baseline 4. The description does not need to add parameter information.

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?

The description clearly states it provides marker statistics showing reliability vs noise based on FCR outcomes. It distinguishes itself from sibling tools like credence_scan and credence_session_summary by focusing on marker health analytics, though it does not explicitly differentiate.

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?

The description implies usage when there are at least 10 sessions of accumulated data, but it does not provide explicit guidance on when to use this tool instead of alternatives like credence_bandit_status or credence_self_probe.

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

credence_memory_recallA

Load project memories into a new session at session start.

Call at the START of a new session. Injects all previously unverified constraints into the new session so enforcement works from turn 1.

ParametersJSON Schema

Name	Required	Description
`project_id`	Yes	Project identifier matching credence_memory_snapshot.
`context_hint`	No	Optional keyword filter.
`new_session_id`	Yes	ID for the new session.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description partially discloses behavior by mentioning injection of unverified constraints, but lacks details on side effects, permissions, or idempotency.

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?

Two focused sentences front-load the purpose and usage, with zero extraneous content.

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?

Given the presence of an output schema and the specific use case, the description adequately covers when and why to call, though it could expand on what 'unverified constraints' entail.

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%, so the description adds minimal value beyond the schema, mainly repeating the required parameters without deeper semantics.

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 clearly states it loads project memories into a new session at startup, explicitly distinguishing it from sibling tools like credence_memory_snapshot by specifying 'injects all previously unverified constraints'.

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?

Explicitly directs to call 'at the START of a new session', providing clear context for use, but does not mention when not to use it or alternatives.

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

credence_memory_snapshotA

Persist all unverified constraints from a session as project memory.

Call at the END of a session. Next session on the same project calls credence_memory_recall to inherit what was still uncertain — the new session starts knowing what it doesn't know.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	Stable project identifier (e.g. "my-api-project").
`session_id`	Yes	Current session ID.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It indicates a write operation ('persist') and provides lifecycle context, but does not detail side effects (e.g., overwrite behavior) or failure modes.

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?

Two efficient sentences: first defines the action, second gives precise timing and links to the sibling tool. No wasted words.

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 simple tool with complete schema and output schema present, the description adequately covers its role in the session lifecycle. Could mention idempotency or safety, but not necessary.

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%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, which are already clear.

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?

Clearly states it persists unverified constraints as project memory, and differentiates from its sibling 'credence_memory_recall' which retrieves this memory.

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?

Explicitly says 'Call at the END of a session' and explains the subsequent recall, providing clear usage context. Lacks explicit when-not-to-use or alternatives beyond the sibling.

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

credence_project_statusA

Project-wide epistemic health dashboard.

Shows all unverified constraints across sessions that have been snapshotted to this project via credence_memory_snapshot.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	Project identifier.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so description carries full burden. It states the tool 'shows all unverified constraints' but does not disclose whether it is read-only, has performance implications, or requires specific permissions. Lacks behavioral context beyond the basic output.

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?

Two sentences with no wasted words. First sentence provides a clear summary ('epistemic health dashboard'), second sentence details scope. Front-loaded and efficient.

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?

Tool is simple (one parameter) and has an output schema, so description need not explain return values. It sufficiently covers the tool's purpose and scope. No additional context is necessary for correct invocation.

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% with parameter 'project_id' described as 'Project identifier.' The description reinforces that the project is the container for snapshotted constraints but adds no new semantic detail about format, constraints, or valid values. Baseline 3 applies.

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?

Description clearly states verb ('shows'), resource ('all unverified constraints'), and scope ('project-wide', 'snapshotted to this project'). It distinguishes from siblings by specifying the context of snapshots via credence_memory_snapshot, providing a specific purpose.

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?

Description implies use for checking unverified constraints in a project context but gives no explicit guidance on when to use this tool versus alternatives like credence_scan or credence_verify. No when-not-to-use or sibling differentiation beyond mentioning the snapshot relation.

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

credence_registerA

Use whenever the user states something uncertain: an unconfirmed vendor claim, an assumption, a 'I think' statement, a number from a quick search. All registered values are UNVERIFIED until explicitly confirmed.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	The uncertain claim text (exact quote preferred).
`session_id`	Yes	Session identifier.
`source_type`	No	Epistemic origin (see above). Default "observation".	observation

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It states that registered values are 'UNVERIFIED until explicitly confirmed,' which is a key behavioral trait. However, it does not mention other behaviors like return value, side effects, or required permissions, leaving some gaps.

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?

Two sentences: first defines the action, second provides usage guidelines. No unnecessary words, front-loaded with purpose. Each sentence 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?

Given the tool's low complexity (3 params, no enums, output schema exists), the description covers purpose, usage, and behavioral note. It is complete enough for an agent to decide when to use this tool and what to expect. Minor omission: no mention of error cases or handling of duplicate registrations, but not critical.

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 schema describes all three parameters with 100% coverage. The description adds value by recommending 'exact quote preferred' for the content parameter, which is actionable guidance beyond the schema. It does not add much for session_id or source_type, but the schema already defines them well.

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 clearly states the tool registers an uncertain constraint in the epistemic registry, distinguishing it from siblings like `credence_verify` and `credence_autoverify` which handle verification. The verb 'register' and resource 'epistemic registry' are specific and unambiguous.

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 explicitly says to use when the user states something uncertain and provides concrete examples (unconfirmed vendor claim, assumption, 'I think' statement, number from quick search). While it doesn't explicitly state when not to use, the context implies it should not be used for certain facts, and siblings cover other cases.

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

credence_resetA

Clear all constraints for a session.

Use after completing a verification pass, or when starting a fresh implementation phase where all prior uncertain values have been resolved.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	The session to clear.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It indicates a destructive action (clearing constraints) but lacks details on side effects, reversibility, or prerequisites.

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?

Two concise sentences, front-loaded with the core action, then usage context. Every word earns its place.

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 simple tool with one parameter and an output schema present, the description fully covers purpose and usage, leaving no critical gaps.

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 the parameter 'session_id' is already described. The description adds no additional semantic value beyond the schema.

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 clearly states the action ('Clear all constraints') and the resource ('for a session'), distinguishing it from sibling tools like credence_constraints which likely manage constraints rather than reset them.

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?

Provides explicit guidance on when to use the tool (after a verification pass or starting fresh), but does not mention when not to use it or point to specific alternatives.

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

credence_scanA

Generation-Time Constraint Scanner (CP3): scan model output for numeric literals that match registered unverified constraints.

Two annotation tiers (no confidence scores — unknown = unverified): ⚠⚠ CREDENCE[stale] — source="temporal_scan" (structurally stale values) ⚠ CREDENCE[unverified] — all other registered constraints

Scans both code blocks and prose.

ParametersJSON Schema

Name	Required	Description
`session_id`	Yes	Session whose constraints to check against.
`output_text`	Yes	Raw model output to scan.
`current_turn`	No	Turn number for confidence decay (default 0).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description discloses key behaviors: two annotation tiers (stale/unverified), their sources, and scope (code blocks and prose). It does not mention output format, but output schema is present, so this is sufficient.

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 concise, uses bullets for tiers, and front-loads the purpose. Each sentence adds value with no redundancy.

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?

Given the tool's complexity (3 params, output schema, no annotations), the description adequately explains the scanning behavior and tiers. It could mention the output structure but the schema fills this gap. Overall complete for the context.

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 baseline is 3. The description does not add additional parameter meaning beyond what the schema already provides (session_id, output_text, current_turn).

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 clearly states the tool scans model output for numeric literals matching registered constraints, with a specific verb-resource combination ('scan model output') and distinguishes it from sibling tools (e.g., verify, register).

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?

The description implies usage for scanning output against constraints and defines two annotation tiers, but does not explicitly state when to use this tool versus alternatives (e.g., credence_verify), nor provides exclusions or prerequisites.

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

credence_scan_ghostsA

Scan a session for ghost constraints.

Ghost constraints are vendor-supplied facts registered without hedging language — they look certain but are actually unverified. The ghost detector flags unverified vendor_claim constraints with no hedging.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	Session to scan.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

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

The description explains that ghost constraints are unverified vendor claims and that the detector flags them, revealing the tool's behavior. However, with no annotations, it could additionally mention any side effects or requirements.

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?

Three concise sentences front-load the action and provide essential context without waste.

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?

Given an output schema exists and the tool has a narrow, well-defined purpose, the description is sufficient for an agent to understand and invoke the tool correctly.

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?

The schema covers the parameter fully ('Session to scan'), and the description provides context about the scan's purpose but adds no new semantic details about the parameter beyond what the schema already offers.

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 clearly states 'Scan a session for ghost constraints' and explains what ghost constraints are, distinguishing this specialized scan from siblings like 'credence_scan'.

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?

The description does not specify when to use this tool versus alternatives like 'credence_scan' or other sibling tools, leaving the agent without explicit guidance on selection.

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

credence_self_probeA

Extract domain-relevant values from generated code and register them as unverified by default — zero API calls, zero model judgment.

Works with any coding agent (Claude Code, Codex, Cursor, Copilot). The agent's own model is NOT asked to rate its confidence. Instead, every extracted value is treated as unverified until the user explicitly calls credence_verify with evidence.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	The generated code block (raw string, fenced or plain).
`session_id`	Yes	Session identifier.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description discloses zero external calls, no model judgment, and unverified registration. It could mention if any state is persisted or side effects, but the transparency is strong for a simple registration tool.

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 three sentences, front-loaded with the core action, and no wasted words. Every sentence adds value.

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?

Despite having an output schema (not mentioned), the description covers purpose, behavior, usage context, and next steps (credence_verify). It is complete for the tool's complexity.

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?

The input schema covers both parameters with clear descriptions (code and session_id). The description adds no new semantics beyond the schema, so a baseline score of 3 applies.

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 clearly states the tool extracts domain-relevant values from generated code and registers them as unverified, with no API calls or model judgment. It distinguishes itself from the sibling credence_verify by specifying that verification is a separate step.

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 defines the use case: after generating code with any coding agent, extract values and register them unverified. It implies when to use by contrasting with zero API calls and zero model judgment, but does not explicitly list when not to use.

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

credence_session_summaryA

Brief of unverified constraints for a session.

Returns action_required, unverified_count, and a summary list so the model can decide whether to snapshot or prompt the user to verify.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	No	Optional project to associate with the snapshot.
`session_id`	Yes	Session to summarize.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns specific fields, which is helpful. However, it does not mention whether the tool is read-only, has side effects, or requires permissions. The name suggests a summary, but behavioral details are missing.

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 two sentences, perfectly front-loaded with the purpose ('Brief of unverified constraints for a session.') followed by return details and purpose. Every sentence adds value with no waste.

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?

Given the presence of an output schema (not fully shown, but context indicates it exists), the description does not need to explain return values in detail. It covers the key points for a low-complexity tool, but could mention that the tool is read-only or define 'unverified constraints' for clarity.

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?

Input schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what is already in the schema descriptions. It does not clarify parameter usage or constraints.

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?

The description clearly states it provides a brief of unverified constraints for a session and lists the return fields (action_required, unverified_count, summary list). It distinguishes itself from siblings like credence_constraints or credence_verify by focusing on a summary, but does not explicitly differentiate.

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?

The description implies usage: 'so the model can decide whether to snapshot or prompt the user to verify.' It gives a hint about when to use (before making decisions), but does not explicitly state when to use vs alternatives or when not to use.

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

credence_verifyA

Mark a registered constraint as verified with its confirmed value.

After verification the constraint is excluded from Truth Buffer injection and Consistency Enforcer enforcement. An audit trail is recorded — who verified, on what basis, and what the confirmed value is.

ParametersJSON Schema

Name	Required	Description	Default
`source`	No	Who verified this. Use "user" for human confirmation, "api_response" for automated checks, "agent:<name>" for downstream agents, "external_doc" for documentation.	user
`evidence`	No	What was checked to confirm this. Strongly recommended. Examples: "checked Stripe dashboard 2026-05-02", "confirmed in production logs", "vendor email attached". An empty evidence string is accepted but leaves no audit basis.
`session_id`	Yes	Session identifier.
`constraint_id`	Yes	ID from credence_register.
`verified_value`	Yes	The confirmed value (e.g. "100 req/min per Stripe docs §4.2").

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

Despite no annotations, the description discloses important behavioral traits: the constraint is excluded from Truth Buffer injection and Consistency Enforcer enforcement, and an audit trail is recorded. It does not mention permissions or reversibility, but these are less critical for a verification action.

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 extremely concise: two sentences covering purpose, consequences, and audit. Every sentence adds value with no fluff. Structure is front-loaded with the primary action.

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?

Given the existence of an output schema and the specific nature of the tool, the description covers the main purpose and side effects adequately. It could mention what happens if the constraint doesn't exist or if there are errors, but overall it's sufficient.

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% with adequate descriptions for each parameter. The tool description does not add additional meaning beyond the schema, so it meets the baseline of 3. No improvements needed.

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 clearly states the action ('Mark a registered constraint as verified') and the resource ('constraint'). It also specifies the confirmed value. The tool's role is unique among siblings (e.g., 'credence_register' creates constraints, 'credence_autoverify' presumably automates verification).

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?

The description implies the tool is used after registering a constraint and when manual verification is needed, but it does not explicitly say when to use it versus alternatives like 'credence_autoverify' or when not to use it. No exclusions or prerequisites are given.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

17 tool updatesv1.2.5Jul 28, 2026
- First observedcredence_audit
- First observedcredence_autoverify
- First observedcredence_bandit_status
- First observedcredence_constraints
- First observedcredence_diff
- First observedcredence_gate
- First observedcredence_marker_health
- First observedcredence_memory_recall
- First observedcredence_memory_snapshot
- First observedcredence_project_status
- First observedcredence_register
- First observedcredence_reset
- First observedcredence_scan
- First observedcredence_scan_ghosts
- First observedcredence_self_probe
- First observedcredence_session_summary
- First observedcredence_verify

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-07-28 16:35 across 17 tools

Disambiguation4/5

Each tool has a distinct purpose, though some overlap exists between constraint listing tools (credence_constraints, credence_session_summary, credence_audit). Descriptions clarify their different focuses, reducing ambiguity.

Naming Consistency4/5

All tools follow a 'credence_' prefix with descriptive lowercase_underscore names. Most are verb_noun (e.g., credence_register, credence_verify) or noun phrases (e.g., credence_project_status). Slight inconsistency in verb forms but overall pattern is consistent.

Tool Count4/5

17 tools is on the higher side but appropriate for the complex domain of epistemic tracking. Each tool addresses a specific need, and the count is justified by the breadth of operations (register, verify, scan, gate, memory, audit, etc.).

Completeness4/5

The tool set covers the full lifecycle of constraint management: registration, verification, scanning, gating, memory persistence, and auditing. Minor gaps exist (e.g., no single constraint deletion or update), but core workflows are well-covered.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

penholder
ai.penholder
Preventive human-approval write-gate for AI agents: writes commit only after a human approves.
Security Autonomous Agents Agent Orchestration
1
Rosey – Quality verification for human and AI contentOAuth
com.getrosey
Fact-checks generated content against your sources of truth showing what to trust, change, & verify.
Testing & QA Tools RAG Systems AI & Machine Learning
1
Senlay Physical Context A
io.github.smartsurfsolar
Physical-world evidence and operability checks with provenance and explicit data gaps.
Home Automation & IoT Monitoring Security
41
Spectral — verified-knowledge oracle A
com.seespectral
Cross-check a factual claim against a verified knowledge graph before you assert it. Never guesses.
Knowledge & Memory Search
1

Related MCP Servers

ClickProof
Autonomous Agents Knowledge & Memory Testing & QA Tools
sandeep-alluru
A
license
Not graded
quality
A
maintenance
UI interaction verifier for computer-use agents — tracks which UI elements exist and their expected behavior to catch ghost actions.
Updated a month ago (2026-08-18 02:17 UTC)
MIT
reflect-mcp
Research & Data Autonomous Agents
jeffma8888
A
license
Not graded
quality
C
maintenance
Enables extraction of structured data from messy text with multi-model verification and human-in-the-loop review, surfacing only high-confidence results or flagging uncertain fields for confirmation.
Updated a month ago (2026-08-04 04:58 UTC)
MIT
sint-epistemic-mcp
kostyk348
A
license
Not graded
quality
C
maintenance
Tracks what an agent KNOWS vs INFERS vs ASSUMES with calibrated confidence. Provides tools to register, query, and analyze epistemic status of claims across domains.
Updated 2 months ago (2026-07-31 08:43 UTC)
Apache 2.0
llm-safe-sql
Databases Security
hyuga611
A
license
Not graded
quality
F
maintenance
Enables LLMs to propose UPDATE/DELETE SQL that is run in a transaction, measured, and rolled back, requiring human approval before applying to prevent unauthorized changes.
Updated 14 days ago (2026-09-02 04:35 UTC)
78 npm
MIT