Loading ToolBench
This BaseHub MCP server demonstrates good overall definition quality with 15 well-structured tools. All tools have names following verb_noun patterns (checkout_branch, create_blocks, etc.), comprehensive descriptions (avg ~150-250 chars), and explicit Zod schemas with parameter descriptions. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are consistently present. However, several tools lack output schema documentation, some descriptions could better explain WHEN to use the tool vs alternatives, and error handling guidance is inconsistent across tools. The server avoids exposing secrets as parameters and uses server-side token injection via getMcpToken() from headers.
Checkout (switch to) a specific branch in BaseHub. This changes the current working branch to the specified branch name.
Create a new commit in BaseHub, publishing all draft changes (note: this not only commits your changes, but also other changes that may've been drafted by others).
Create one or more BaseHub blocks (with possible nested children). Children should be always nested in the value key of its parent, never as another item in the array. Use create_blocks to add new blocks. Create data objects require specifying the block type and its initial values. ### Basic Create Structure ```json { "parentId"?: "<layout-block-id>", "data": [{ "type": "text" | "image" | "richtext" | "date" | "list" | "component" | "document" | "select" | "reference" | "boolean" | "oimage", "title": "<block-title>", "value": <block-value-dependant-on-type> }] } ```
Create a new branch based on an existing branch in BaseHub. The new branch will be created from the specified base branch and optionally checked out.
Delete one or more BaseHub blocks in a single transaction. Only requires the block ID.
Output schemas not documented in source code. Tools like create_blocks, update_blocks, delete_blocks return responses but the exact structure (fields, types, nesting) is not declared where the tool is registered. This forces LLMs to infer output structure and risks misinterpreting pagination or nested data.
Inconsistent error recovery guidance. Some tools return actionable errors (e.g., checkout_branch includes a note about BASEHUB_REF env var), but others (e.g., get_token) lack guidance on what to do if retrieval fails. Users/agents cannot distinguish retryable from fatal errors without examining code.
Descriptions for some tools are generic or lack differentiation guidance. For example, 'Get example content structures from template repositories' for get_example_content_structure doesn't explain WHEN to use this vs get_content_structure, and whether results are for reference only or can be cloned.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 68 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 67 | - | v1 |
Retrieve the structure of the current BaseHub repository in XML format and optional documentation. Use when you need to know the structure / schema / blocks / tree of the repository.
Get the current branch/ref in BaseHub. This returns information about the currently active branch.
Get example content structures from template repositories.
Get a BASEHUB_TOKEN.
Get a signed URL to upload a file to BaseHub. This is useful for uploading files to BaseHub.
List all branches in the current BaseHub repository.
Merge a BaseHub branch into another branch.
Query the BaseHub repository content. Use this as you need to get content created by the user, or specific IDs for subsequent content changes. When querying content: - Use proper GraphQL syntax - Include necessary fields and arguments - Be mindful of query depth and complexity - Use fragments for reusable field sets - Consider using variables for dynamic queries
Search the BaseHub developer docs.
Use update_blocks to modify existing blocks. You must specify the block ID and the properties you want to change. ### Update Structure ```json (example) { "autoCommit"?: "<commit-message>", "data": [{ "id": "<layout-block-id>", "value": { // primitive block updates go here } "variantOverrides": { // optional record of <variant-set-api-name>-<variant-apiName> and block value } }] } ``` Notice how the update syntax is the same as the create operation of the `instance` block: by API Name directly!
Parameter constraints are documented informally in descriptions but not enforced via schema. For example, list_branches accepts limit/offset but the schema does not specify min/max bounds (e.g., 1 - 100 for limit). LLMs may pass invalid values.
Dry-run / confirmation step missing for destructive operations. delete_blocks and commit are marked destructiveHint: true and idempotentHint: false, but the tools do not offer a preview or confirmation mode. Agents cannot review consequences before executing.
Tool chaining metadata incomplete. For example, create_blocks returns transaction status but likely returns block IDs needed for subsequent update_blocks or delete_blocks calls. Response fields that enable chaining are not documented in tool definitions.