Loading ToolBench
MCP server that exposes CarterOS database and services to Claude via Telegram. Provides both generic database access and ergonomic service methods for life management, job tracking, notes, scheduling, and analytics.
CarterOS MCP server has 15 tools with inconsistent definition quality. Naming is generally action-verb based (execute_query, create_note, get_schedule_for_date), which is good. However, descriptions vary significantly in depth and clarity. Most tools have basic descriptions (50-150 chars) but lack detailed WHEN-to-use guidance, error recovery hints, and output schema documentation. Input schemas are present with type declarations for all visible tools, but lack granularity, parameters like 'sql' and 'status' have minimal constraint documentation. No tool annotations (readOnlyHint, destructiveHint) are visible. Parameter descriptions are minimal (10-50 chars typically), below the baseline of 72 chars. Several tools (execute_query, execute_write, list_tables, describe_table) are database-adjacent and expose raw SQL without sanitization language in their descriptions, raising injection concerns. Composition is reasonable, tools are mostly single-responsibility, but chaining guidance is absent (e.g., get_all_notes returns folder list, but create_note accepts folder_id without explicitly saying 'use folder_id from get_all_notes'). Error handling is not documented in any tool description.
Track a new job application.
Create a new note. Optionally specify folder_id to put it in a folder.
Create a time block in the schedule. Times in HH:MM format (24h). Date defaults to today if not specified.
Get schema for a table (column names, types, nullable).
Execute read-only SQL query against CarterOS database. Use for SELECT queries to explore any data. Returns list of row dictionaries.
Execute write SQL (INSERT, UPDATE, DELETE) against CarterOS database. Use for modifying data. Returns affected row count. For INSERTs with RETURNING, also returns the inserted data.
SQL injection risk: execute_query and execute_write accept raw SQL strings with only a description claiming 'read-only' or 'write'. No input validation, sanitization hints, or prepared statement guidance visible in descriptions. LLM could construct malicious SQL.
Parameter descriptions are too brief (10-50 chars vs. baseline 72). 'status' in get_job_applications lists enum values inline ('applied, interviewing, offer, rejected, ghosted, withdrawn') but this is not a formal enum constraint, LLM could pass invalid values. Same issue for 'color' in create_time_block.
No output schemas documented. Descriptions state what's returned (e.g., 'Returns {folders: [...], notes: [...]}' for get_all_notes) but do not specify field types, which fields are always present, or what structure nested arrays contain. LLM cannot reliably extract or chain results.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 17 | - | v1 |
Get all notes and folders. Returns {folders: [...], notes: [...]}.
Get job applications. Optionally filter by status. Status options: applied, interviewing, offer, rejected, ghosted, withdrawn
Get a single note by ID.
Get job applications that need follow-up action.
Get time blocks for a specific date. Date format: YYYY-MM-DD
Get all time blocks scheduled for today. Returns list of {id, title, start_time, end_time, description, color}.
List all tables in the CarterOS database.
Search notes by title and content (case-insensitive).
Update an existing note. Only updates provided fields.
No error recovery guidance. Tool descriptions do not explain what errors might occur (e.g., invalid date format, note not found, folder not found) or how the LLM should recover. Missing error classification (retryable vs. user-fixable vs. fatal).
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). These are current-spec features that help agents reason about safety and side effects. create_note, update_note, create_time_block, create_job_application, and execute_write are destructive but not marked as such.
Missing WHEN-to-use guidance. Descriptions state WHAT each tool does but not WHEN to call it vs. similar tools or as part of multi-step workflows. E.g., get_todays_schedule vs. get_schedule_for_date, when should LLM prefer one?
Parameter naming ambiguity: 'table_name' and 'note_id' and 'folder_id' use different suffix styles (_name vs. _id). Inconsistent naming across tools creates cognitive load for LLMs deciding whether to pass IDs or names.
No pagination parameters or limits documented. get_all_notes, search_notes, get_job_applications accept no limit/offset/cursor parameters, and descriptions do not state how many results are returned. Large note/application sets could exhaust context window.
Composition chain documentation missing. get_all_notes returns folder list and create_note accepts folder_id, but descriptions do not explicitly say 'pass folder_id from get_all_notes'. get_schedule_for_date requires date in YYYY-MM-DD format but no guidance on how to construct this from natural language user input.