Loading ToolBench
The MCP server with the most ironic name in the registry — persistent semantic memory for your SQL databases
amnesic demonstrates solid definition quality with consistent naming conventions, comprehensive parameter descriptions, and well-documented schemas. All 12 tools follow verb_noun naming (db_query, db_get_schema, db_annotate, etc.). Descriptions are typically 100-250 characters with clear purpose statements. Parameters include type definitions and usage guidance. However, output schemas are documented only in docstring Returns sections (not as formal JSON Schema objects), and some tools lack explicit enum constraints for categorical parameters. Tool annotations (readonly/destructive hints) are present in the Risk field but not formally registered in MCP schema. The server shows mature design with sophisticated composition (knowledge persistence, schema discovery, relationship mapping) but misses some formal specification completeness.
Persist semantic annotations for a table or column — survives across sessions. This is the core of amnesic's persistent memory. Every annotation saved here is automatically merged into future db_get_schema() responses, so the AI never has to rediscover what a status code means or what a table is for. Call this after discovering: what an enum value means, what a column represents, how a table relates to another, or what a table is used for.
Soft-retire an annotation by flagging it with a deprecation warning. The annotation remains readable and is merged into db_get_schema responses, but is marked as deprecated so the AI knows to avoid it. Reversible: pass undo=True to un-deprecate. Use this when an annotation is going stale but the table/column still exists and you want to preserve its historical meaning.
Audit saved annotations against the live schema. Surfaces orphaned annotations (the table/column no longer exists in the database) and undocumented tables (exist in the database but have no annotations). Run after schema changes to identify stale knowledge that needs cleanup via db_deprecate or db_forget.
Scan the database for foreign key relationships and populate the knowledge store. Analyzes the live schema and extracts FK references, storing them as semantic annotations. Run once per database to bootstrap the FK graph; db_annotate can add additional semantic relationships if needed.
Output schemas documented in docstrings only, not as formal JSON Schema objects in tool registration. LLMs and client libraries rely on structured schema definitions to understand response shapes and plan downstream calls.
Tool annotations (Risk field with READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) are documented in comment form but not formally declared as toolAnnotations (readOnlyHint/destructiveHint/idempotentHint) in MCP protocol. This prevents clients from enforcing safety policies or warning about irreversible operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 73 | 2026-07-28+ | v2 |
Permanently delete a wrong or orphaned annotation. Use after discovering that an annotation is incorrect, or after db_detect_drift flags it as orphaned (the table/column no longer exists). Pass cascade=True to also remove a table's columns and relationships when deleting a table-level annotation.
Get the stored foreign key relationships for a table. Returns a list of known FKs, both discovered from the schema via db_discover_relationships and added manually via db_annotate. Useful before writing complex JOINs.
Get column schema for a table, merged with any saved semantic annotations. Checks the local cache first; fetches from the database on cache miss or when force_refresh=True. Saves the result to cache for future calls. Merges column descriptions, enum value mappings, and FK references from previous db_annotate() calls into the response.
List all configured database connections. Returns connection names and basic metadata. Use this to discover what databases are available before calling other tools.
List all known tables for a connection, with descriptions and column counts. Tables appear once they have been fetched via db_get_schema or annotated via db_annotate. Descriptions come from the knowledge store — richer than raw INFORMATION_SCHEMA.
Execute a read-only SELECT query and return rows as a list of dicts. All queries run inside an immediately-rolled-back transaction — write statements are blocked both statically and at the transaction level. Call db_get_schema first if you are unfamiliar with the table structure.
Search the knowledge layer for tables/columns matching a query — BM25-ranked. Use this BEFORE db_list_tables when you're looking for a specific concept (e.g. "payments", "user email", "shipping address"). db_list_tables returns every table; db_search returns just the relevant ones with descriptions and highlighted snippets. Searches across: table names, descriptions, and aliases; column names, descriptions, and enum_values. Falls back gracefully to empty results if the query has invalid FTS5 syntax.
Synchronize the knowledge store with the live database schema. Scans the database for new tables/columns and merges them into the knowledge store. Existing annotations are preserved. Use this when the schema has changed outside of amnesic's purview (e.g. migrations run by another tool).
db_search target parameter accepts free-form string ('tables', 'columns', 'all') but lacks enum constraint. Should declare valid values as enum in schema to prevent LLM hallucination of invalid values like 'relationships' or 'schemas'.
db_deprecate undo parameter is boolean but context-dependent (only meaningful when column is provided or not). Interdependent parameter logic not explicitly documented in descriptions.
No explicit error handling or recovery guidance documented in tool descriptions. Tools do not indicate what happens on connection failure, schema not found, invalid SQL, or permission denied. LLMs cannot determine whether to retry, ask user, or escalate.
db_annotate accepts unstructured enum_values parameter (object/dict) with no schema or example. Should show expected format: {"1": "active", "2": "inactive"}. Without formal schema, LLMs may pass malformed data.