Loading ToolBench
An MCP server for managing claims, sources, sessions, and wiki documents in a knowledge management system with validation and evidence tracking
Scrinium has 41 tools with inconsistent quality. Most tools have descriptions (good), but many lack proper input schemas or have incomplete parameter documentation. Tool naming is generally clear (verb_noun pattern), but parameter descriptions are often generic. Output schemas are not documented. Error handling is minimal. The server exposes session_id as an optional parameter across many tools, which is a protocol anti-pattern (stateless handling per 2026-07-28 spec). Many tools appear to be inferred from code rather than explicitly registered with full schemas.
Abandon an active session by ID with a required reason
Adopt the LLM wiki structure and return a report
Append content to a log file
Apply source migration with optional session ID
Archive a wiki page
Assess the status of source migration
Begin a new session and set it as the current session
Return server capabilities including schema version and preferred operations
Stateful session_id parameter anti-pattern: 41 tools expose optional session_id as a parameter, violating 2026-07-28 spec requirement for stateless request handling. Sessions should be managed via server-side context or request metadata, not tool parameters.
Output schemas not documented: No tool explicitly documents its return type or structure. LLMs cannot plan downstream tool calls or extract required fields without knowing what each tool returns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Attach evidence to an existing claim
Create a new claim with subject, statement, authorship, evidence, and validation policy
Retrieve a claim by ID
Run linting checks on all claims and return a deterministic report
List claims with optional filtering by validator ID, binding reference, target, lifecycle, assessment, freshness, or locator prefix
Set the validation policy for a claim
Mark a claim as superseded by a successor claim
Update an existing claim's subject and statement with optional meaning-unchanged flag and expected revision
Validate a claim using either a specific binding or required bindings
Withdraw a claim with an optional reason
Continue an existing session by ID and set it as the current session
Create a new draft document with a name and content
Create a new wiki page at the specified path with content
Finish an active session by ID
Run linting checks on the LLM wiki and return a report
List all active sessions
Move a wiki page from one path to another
Read the content of a wiki page by path
Rebuild the source-registry.md file from canonical source records
Register a source with required source_id, title, and raw_path, plus optional metadata
Abandon an active session with a reason
Begin a new session
Continue an existing session by ID
Finish an active session
List all active sessions
Get the status of a session by ID
Initialize the LLM wiki structure with canonical files and directories
Retrieve a source by ID
List all registered sources
Assess the status of source migration
Refresh a source's metadata with expected revision for optimistic concurrency
Register a new source with metadata including title, raw path, source type, origin, trust level, dates, and summary
Update the content of a wiki page at the specified path
Duplicate/overlapping tool names: session_begin/begin_session, session_continue/continue_session, session_finish/finish_session, session_abandon/abandon_session, session_list/list_active_sessions, source_register/register_source. LLMs waste reasoning cycles deciding between near-identical tools.
Minimal parameter descriptions: Many tools have parameters with generic or missing descriptions (e.g., 'input' described only as 'following scrinium.claim-create/v1 schema'). LLMs cannot infer what values are valid or required without explicit guidance.
No error handling guidance: Tool descriptions do not explain what errors can occur, when to retry, or what the LLM should do if a call fails. Error responses likely lack actionable recovery hints.