Loading ToolBench
MCP server for interacting with a PocketBase instance (records, collections, files, logs, crons and migrations).
PocketBase MCP presents a comprehensive server with 33 well-defined tools covering collections, records, files, migrations, backups, and settings. Most tools have explicit schemas and descriptions. However, several tools have incomplete parameter documentation, some descriptions lack context about when to use them vs similar tools, and error handling guidance is minimal. Tool naming is generally strong (verb-first, clear intent), but some tools like 'run_sql' and 'batch_records' need clearer security/risk warnings. Output schemas are not explicitly documented in the code, requiring inference from SDK documentation. The server demonstrates good structural quality with proper TypeScript types, but falls short of A-grade polish in parameter completeness and recovery guidance.
Create a migration file for adding a field to an existing collection.
Apply all pending migrations.
Apply a specific migration file.
Execute multiple record create/update/upsert/delete operations in a single transactional batch request (PocketBase >= v0.23). If any operation fails, the whole batch is rolled back by the server. NOTE: on PocketBase >= v0.39 the server disables batch by default — enable it via update_settings with { "batch": { "enabled": true } } or the call fails with 403 "Batch requests are not allowed".
Create a new database+storage backup on the PocketBase instance. The operation is queued by the server and may take a moment to appear in list_backups.
Create a migration file specifically for creating a new PocketBase collection.
Missing output schema documentation. Tools return results but no tool definition includes explicit outputSchema or description of return structure. LLMs must infer output from descriptions, leading to misuse.
Incomplete parameter descriptions. Multiple tools have parameters lacking detailed descriptions of constraints, format, or usage. Examples: 'fields' param in list_cron_jobs lacks explanation of the CSV format; 'filter' and 'sort' in list_records and list_logs describe them as 'PocketBase filter string' without explaining what that means or providing examples.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Create a new, empty PocketBase migration file with a timestamped name.
Create a new record in a PocketBase collection.
Delete a record from a PocketBase collection by ID (permanent — the record is removed server-side).
Get the URL to download a file from a PocketBase collection record field.
Validate a VIEW collection query without saving the collection (server >= v0.37). Returns the resulting field definitions and a sample of rows, or a validation error.
Fetch a single record from a PocketBase collection by ID.
Get example collection schema payloads (scaffolds) from the PocketBase instance (server >= v0.37) — an object keyed by collection type (base, auth, view) with ready-to-edit templates for building new collections.
Get the schema (fields, rules, etc.) of a PocketBase collection.
Get a single API request log by ID.
Get API request logs statistics with optional filtering.
Fetch all PocketBase app settings (meta, logs, smtp, email templates, external stores, etc.). Secret fields are returned masked by the server.
List all backup files available on the PocketBase instance (name, size, last modified).
List all collections in the PocketBase instance.
Returns list with all registered app level cron jobs.
List API request logs from PocketBase with filtering, sorting, and pagination.
List all migration files found in the PocketBase migrations directory.
List records from a PocketBase collection. Supports filtering, sorting, pagination, and expansion.
Restore the PocketBase instance from an existing backup file. DESTRUCTIVE: replaces all current data. Requires confirm=true.
Revert a specific migration file.
Revert migrations up to a specific target.
Triggers a single cron job by its id.
Execute a raw SQL query against the PocketBase instance (server >= v0.39). DANGEROUS: requires the server process to be started with POCKETBASE_ENABLE_SQL=true; returns an error otherwise. Use read-only queries when possible.
Set the directory where migration files will be created and read from.
Delete ALL API request logs from the PocketBase instance (server >= v0.40). DESTRUCTIVE and irreversible. Requires confirm=true.
Update an existing record in a PocketBase collection by ID.
Bulk-update PocketBase app settings with a partial payload (PATCH semantics: only the provided keys change). Provide real values for secret fields — the masked "******" placeholder from get_settings is not accepted by the server.
Upload a file (provided as content string) to a PocketBase collection record field.
Insufficient error recovery guidance. Tool descriptions note dangerous operations (restore_backup, truncate_logs, delete_record, run_sql) but provide no guidance on what errors are expected, how to detect them, or how to recover. The error handler returns generic validation errors without suggesting next steps.
run_sql tool lacks sufficient risk documentation. Description mentions 'DANGEROUS' and the POCKETBASE_ENABLE_SQL requirement, but does not clearly state that this tool can modify or destroy data, should only be called with explicit user consent, or provide examples of safe vs unsafe queries.
Tool naming overlap and ambiguity. Multiple tools interact with similar resources (list_records, fetch_record, create_record, update_record, delete_record) but lack clear guidance on when to use list_records with filtering vs fetch_record (does fetch_record also accept patterns?). Migrations have similar names (apply_migration, apply_all_migrations, revert_migration, revert_to_migration) that could confuse LLMs.
Batch operations lack per-item error reporting. batch_records returns a single success/failure, if 1 of 50 operations fails, the entire batch rolls back with no detail on which operation(s) failed or what to retry.
Missing pagination limit enforcement. list_records and list_logs accept perPage up to 500, but no guidance on performance impact for large result sets. For context window efficiency, should recommend max 50 items per call and provide cursor or offset pagination.
Parameter validation errors generic. invalidParamsError() throws without explaining what constraint was violated or how to fix it. Examples: batch_records['requests[0]: missing required field collection/action'], LLM must infer the schema, risking malformed retries.