Loading ToolBench
A flexible headless CMS API server built on JSON Schema and Git concepts, providing MCP tools for managing projects, branches, revisions, tables, rows, endpoints, and migrations
The Revisium MCP server provides 27 well-named tools with mostly complete schemas and descriptions. Naming follows verb_noun conventions consistently (get_*, create_*, delete_*, etc.). Parameter descriptions are present for most tools. However, several issues prevent a higher score: (1) Output schemas are not documented, the evaluation cannot verify what these tools return, which is critical for LLM planning and chaining; (2) Some tools have optional parameters that make them ambiguous in usage (e.g., get_revision accepts either revisionId OR uri, but the mutual exclusivity and fallback behavior are not clearly explained); (3) Error handling guidance is minimal, tools describe what they do but not what to do if they fail; (4) Some parameter descriptions lack constraints (e.g., no stated limits on 'first' pagination parameter, no format specification for ISO-8601 strings in apply_migrations); (5) A few tools have overly complex or vague descriptions that don't clearly answer 'when should the LLM call this tool instead of a similar one?' (e.g., get_revision_changes vs get_table_changes vs get_row_changes distinctions are unclear).
Apply migrations to a draft revision. Use this to sync schema changes from another Revisium instance. Migration IDs MUST be ISO-8601 datetime strings. Use the exact same format returned by get_migrations.
Create a new branch from a revision
Create a new endpoint for a revision. Endpoints expose revision data via GraphQL or REST API.
Create a new project in an organization
Commit changes in a draft revision. CRITICAL: ALWAYS ask user for permission before committing. Never commit automatically - head/draft may point to different environments and committing without permission can break production.
Delete a branch
Output schemas not documented. None of the 27 tools include explicit descriptions of what fields they return or the structure of responses. This prevents LLMs from planning downstream tool calls and understanding what data is available for chaining.
Ambiguous parameter optionality and fallback behavior. Tools like get_revision, get_migrations, upload_file, apply_migrations, and revert_changes accept EITHER an ID parameter OR a URI reference, but the mutual exclusivity is not explicitly documented. When both are optional, LLMs cannot determine which to pass or what the tool does if both/neither are provided.
Missing pagination constraints. Tools accepting 'first' parameter (get_branches, get_revisions, get_project_endpoints, get_projects, get_table_changes, get_row_changes) do not specify minimum/maximum values. Without bounds, LLMs may pass absurd values (0, -1, 1000000) that break the API or timeout.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
Delete an endpoint
Delete a project
Get branch by organization, project and branch name
List branches in a project
Get draft revision for a branch
Get endpoint with all related entities (revision, branch, project)
Fetch GraphQL schema (introspection) from a GRAPHQL endpoint. Returns the full schema introspection result that describes all types, queries, and mutations available. The endpoint URL is resolved server-side. If this fails with a connection error, check that ENDPOINT_SERVICE_URL or PUBLIC_URL env var is set correctly on the server.
Get all migrations from a revision. Migrations are schema change records that can be applied to other Revisium instances. Read revisium://specs/migration resource for migration format details.
Get organization by ID
Get the parent revision of a given revision. Returns null if the revision is the root (first) revision.
Get project by organization ID and project name. Returns project info with rootBranch containing draftRevisionId and headRevisionId.
Get all endpoints for a project
Get all projects in an organization
Get revision details
Get summary of all changes in a revision (tables and rows added/modified/removed). Use this to see what changed in draft vs head.
List revisions in a branch
Get detailed list of changed rows in a revision, including field-level diffs.
Get detailed list of changed tables in a revision, including schema changes.
Revert all uncommitted changes in a branch
Update project settings
Upload a file to a row's file field using base64 data. Requires storage to be configured (S3 or local provider via FILE_PLUGIN_PROVIDER env var). WORKFLOW: 1. Create a table with a file field using $ref: "urn:jsonschema:io:revisium:file-schema:1.0.0" in schema 2. Create a row - the file field will have status "ready" and a generated fileId 3. Get the row (get_row) to find the auto-generated fileId in the file field 4. Use this tool to upload the actual file data using that fileId 5. After upload, status changes to "uploaded" and url becomes available For arrays of files: each array element has its own fileId, upload files one by one. If you get "Storage is not configured" error, the server needs S3 or local storage provider configured.
Insufficient error handling guidance. Descriptions do not explain what errors are possible (e.g., 'Endpoint not found', 'Storage not configured' for upload_file) or what the LLM should do next. Error recovery paths are undocumented.
Unclear distinctions between related tools. get_revision_changes, get_table_changes, and get_row_changes all describe changes in a revision. The descriptions do not clearly answer: when should I call get_revision_changes vs get_table_changes vs get_row_changes? What is the difference in granularity and use case?
Missing constraints on ISO-8601 datetime format in apply_migrations. The tool description states that migrationIds 'MUST be ISO-8601 datetime strings' and references exact format, but does not provide a pattern or example to guide LLMs (e.g., '2024-01-15T10:30:00Z').
create_revision includes a critical security note ('ALWAYS ask user for permission before committing') but this is buried in the description and not machine-parseable. The tool lacks a confirmation/dry-run mechanism; LLMs may commit without explicit user approval.
revert_changes has all optional parameters (organizationId, projectName, branchName, uri). The fallback behavior when none are provided is undefined. Can the tool infer context from a session? Does it fail? This ambiguity prevents LLMs from using the tool reliably.
Parameter naming inconsistency: some tools use 'revisionId' and 'uri' (get_revision, get_migrations) while others use 'organizationId', 'projectName', 'branchName' as the primary identifiers. This forces LLMs to reason about multiple identity models rather than following a consistent pattern.