The Boarderless MCP Server connects AI agents to a live Boarderless canvas running in a local browser, enabling inspection, creation, mutation, and export of canvas content, plus local file utilities and 3D rendering.
Diagnostics & Status
get_server_status — Health check on browser connectivity, canvas bridge, and authentication
Canvas Inspection
get_board_state — Retrieve the full canvas as a structured JSON ledger of all objects
calculate_export_bounds — Get the collective bounding box of all active canvas objects
Canvas Manipulation
create_object — Create text or shape objects (rect, ellipse, triangle, arrow)
mutate_object — Modify position, size, style, and other properties of existing objects
delete_objects — Remove one or more objects by ID
group_objects / ungroup_objects — Group or ungroup canvas objects
reorder_object — Change z-index layering (front, back, forward, backward)
remix_style — Apply a Boarderless color palette to selected objects or the entire board
History Management
history_undo / history_redo — Undo or redo canvas actions
Workspace & File Management
get_board_workspace / set_board_workspace — Check or set the local directory for .bdrl.json board files
export_board_file — Save the current canvas as a .bdrl.json snapshot
import_board_file — Load a .bdrl.json file and switch the live canvas to it
Export
export_board — Export the canvas to PNG, PDF, or SVG
3D Rendering
render_board_in_blender — Generate a 3D studio render using Blender (EEVEE or Cycles engine)
Local Photo Utilities
graduation_rename_photos — Rename and sequentially number photo files in a local directory
graduation_standardize_images — Convert HEIC/progressive JPEGs to standard baseline RGB JPEGs
Connects to Brave Browser via Chrome DevTools Protocol to control the Boarderless canvas tab.
Connects to Google Chrome via Chrome DevTools Protocol to control the Boarderless canvas tab.
Connects to Opera Browser via Chrome DevTools Protocol to control the Boarderless canvas tab.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Boarderless MCP Server show me the current canvas state"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Operating System & Browser Support: This Model Context Protocol (MCP) server and launcher tool are designed and optimized specifically for Windows and Google Chrome. Chromium-based browsers (including Microsoft Edge, Brave Browser, and Opera) are also supported on Windows. Other platforms (such as macOS or Linux) are supported as fallbacks but are not the primary target.
A Model Context Protocol (MCP) server for https://Boarderless.app/, allowing Ai agents (like Claude Desktop, Cursor, and Claude Code) to inspect and edit the live browser-resident canvas directly. Boarderless remains Local First: the browser owns the working canvas, and this server connects an agent to that visible local session rather than inventing a hidden cloud copy.
Looking for the app-wide map—canvas tools, image editing, slides, Ai Partner, persistence, plan boundaries, and the exact MCP subset? Ai agents connecting to this repository should parse the Boarderless Product & MCP Feature Catalog before proposing work. Connector distribution and OpenAI/Microsoft readiness are tracked in docs/connector_distribution_plan.md; the future OAuth 2.1/Streamable HTTP adapter design is in docs/oauth21_remote_adapter_plan.md; Joel's selected Option A browser bridge is specified in docs/remote_session_bridge_spec.md; Joel's operator path is in docs/connector_operator_runbook.md.
Rather than scraping pixels or guessing layouts from DOM selectors, agents communicate with a clean, typed spatial ledger.
Step 1: Start the Interactive Configurator (Windows, Mac, or Linux) Run the installer to configure your environment and client settings:
Windows (PowerShell):
Set-ExecutionPolicy Bypass -Scope Process -Force; .\src\setup.ps1Mac / Linux (Terminal):
chmod +x ./src/setup.sh && ./src/setup.shStep 2: Choose Option 1 (Standard Auto-Setup) The interactive installer will:
Explain permissions (browser connection, file access).
Install pure JavaScript dependencies automatically.
Register the MCP server in your Claude Desktop configuration.
Provide immediate copy-paste instructions for Cursor or Windsurf.
Related MCP server: Excalidraw MCP Server
+------------------+ +--------------------+
| Ai Agent Client | | Boarderless App |
| (Claude/Cursor) | | (Zustand + React) |
+--------+---------+ +---------+----------+
| ^
| (Stdio JSON-RPC) | (window.boarderlessMcp)
v v
+------------------+ CDP / Puppeteer +---------+----------+
| MCP Server +------------------>| Chrome / Edge |
| (Stdio Transport)| | Debugging Port |
+------------------+ +--------------------+Boarderless Web App: Exposes window.boarderlessMcp containing typed tool execution methods over Zustand state.
MCP Server (mcp-stdio-server.js): Connects only to a visible browser via Chrome DevTools Protocol (CDP), brings the Boarderless canvas tab to the front, rejects headless or invisible browser identities, maps incoming stdio messages to the browser runtime, and checks authentication. If the remote debugging port (9222) is closed, the server automatically scans and launches a visible Chrome or Edge window in remote-debugging mode.
Ai Agent: Connects as a client to the MCP server's stdio transport.
Workspace Board File: After every successful canvas mutation, the MCP server asks the browser persistence layer for the canonical schema-v2 snapshot and atomically writes <board-name>--<board-id>.bdrl.json into the configured local workspace.
Ai Partner lives inside the Boarderless app. It interprets supported natural-language canvas requests through Gemini, OpenAI, Anthropic Claude, Z.AI/GLM, local models, or a custom OpenAI-compatible endpoint, and performs local per-image background removal.
Boarderless MCP connects external agent clients to the running, human-visible canvas. It can inspect, measure, create supported text/shapes, mutate, delete, group, ungroup, reorder, undo, redo, export, and maintain durable .bdrl.json artifacts.
MCP does not inherit the user's Google identity, grant itself Drive access, upload arbitrary local images into the canvas, or bypass plan restrictions. Those boundaries stay with the human and the app.
The complete app feature surface—including image editing, presentations, minimap, typography, exports, persistence, plan boundaries, Ai Partner, and MCP—is indexed in docs/features_catalog.md.
.bdrl.json workflowAgents must treat the board file as part of the task artifact, not as an optional final export:
Call get_board_workspace before canvas work.
If it is not the user's current project directory, call set_board_workspace with that absolute directory (or set BOARDERLESS_WORKSPACE_DIR in MCP configuration).
Use the normal mutation tools. Every successful create, mutate, delete, group, reorder, undo, or redo automatically refreshes the canonical .bdrl.json file.
Before handoff, call export_board_file and report its returned path. This explicit final flush makes the artifact requirement visible even if an earlier autosave warning occurred.
To resume work, place a schema-v2 .bdrl.json file in the workspace and call import_board_file with its filename. The backend validates containment and schema, imports it through Boarderless persistence, switches the live canvas to it, and refreshes autosave.
Board file reads and writes are restricted to the configured workspace. Filenames cannot contain directories or traversal segments. Writes use a same-directory temporary file followed by an atomic rename so interrupted writes do not leave half-valid JSON.
Node.js (v18 or higher)
Supported OS & Browser: Windows 10/11 with a Chromium-based browser—Google Chrome, Brave Browser, Opera, or Microsoft Edge—uses the primary tested path. macOS and Linux use community fallback paths.
Boarderless Web App: Access via production at https://boarderless.app/canvas (default) or your local dev server if running one.
Note: This Model Context Protocol server is optimized specifically for Windows. Google Chrome, Brave Browser, Opera, and Microsoft Edge are all fully supported. macOS and Linux are supported as community fallbacks.
To allow the MCP server to attach to your browser tab, you must start Chrome or Edge with debugging port 9222 active.
The MCP server will automatically try to find and launch Chrome/Edge on port 9222 if it is not already running.
If you want to launch it manually, we provide pre-built launchers:
Windows: Double-click ./launch-chrome-debugging.bat (or run it via cmd/PowerShell).
macOS/Linux: Run chmod +x ./launch-chrome-debugging.sh && ./launch-chrome-debugging.sh.
Alternatively, launch manual instances: Windows (PowerShell):
& "C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir="$env:LOCALAPPDATA\boarderless-mcp-profile" https://boarderless.app/canvasmacOS (Terminal):
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir="$HOME/Library/Application Support/boarderless-mcp-profile" https://boarderless.app/canvasNote: Make sure to sign in/authenticate Google OAuth on the canvas page.
We provide pre-built install scripts that automatically check for Node.js (offering to install it if missing), install all package dependencies, write the Claude Desktop configuration, and offer to launch debugging:
Windows: Open PowerShell in this folder and run:
Set-ExecutionPolicy Bypass -Scope Process -Force; .\src\setup.ps1macOS & Linux (Ubuntu): Open Terminal in this folder and run:
chmod +x ./src/setup.sh && ./src/setup.shAlternatively, perform manual installation:
Run npm install.
Run npm run setup.
Verify your connection by running the test client, which queries the canvas state and moves the first element:
npm run exampleget_server_statusAlways call get_server_status first before attempting canvas operations.
It returns a structured JSON report with four health checks and actionable resolution steps for every failure:
{
"status": "ok",
"ready": true,
"summary": "All systems operational. Ready to control Boarderless.",
"checks": [
{ "check": "browser_port", "passed": true, "detail": "Chromium DevTools listening on http://127.0.0.1:9222" },
{ "check": "canvas_tab", "passed": true, "detail": "Active canvas tab: https://boarderless.app/canvas" },
{ "check": "mcp_bridge", "passed": true, "detail": "window.boarderlessMcp bridge is mounted and ready" },
{ "check": "authentication", "passed": true, "detail": "User is authenticated — canvas tools are available" }
],
"runtime": {
"platform": "win32",
"node_version": "v22.3.0",
"server_version": "0.1.28",
"app_url": "https://boarderless.app/canvas",
"browser_url": "http://127.0.0.1:9222",
"started_at": "2026-06-16T19:07:00.000Z",
"tool_calls": 1,
"tool_errors": {}
},
"next_steps": ["Call get_board_state to inspect the current canvas."]
}When something fails, each check includes a resolution field with exact fix steps:
{ "check": "authentication", "passed": false,
"resolution": "Sign in with Google at https://boarderless.app/canvas. Canvas tools require an active Boarderless session." }Every tool returns a structured JSON error object — never a raw exception string. Agents can parse error_code to decide next steps programmatically.
| Meaning | Resolution |
| No Chromium browser running on the debug port | Launch Chrome with |
| Canvas session not authenticated | Sign in at |
|
| Navigate to |
| Bridge removed mid-session | Refresh the browser tab |
| Export function not bound on page | Ensure a board is open and you're on |
| Export threw a runtime exception | Check plan tier — SVG/PDF require Pro |
| Workspace configuration was not an absolute path | Pass the agent's absolute project directory to |
| Canonical snapshot could not be written | Confirm workspace permissions and refresh the canvas persistence bridge |
| Workspace board file failed containment, schema, or browser import | Use a schema-v2 |
| Filesystem path argument doesn't exist | Use an absolute path to an existing directory |
| Required tool argument was omitted | Check the tool's input schema |
| Unhandled error in the tool silo | Check server stderr; open a GitHub issue |
Error shape:
{
"status": "error",
"error_code": "AUTH_REQUIRED",
"message": "You must be signed in to Boarderless to use canvas tools.",
"resolution": "1. Open https://boarderless.app/canvas ...\n2. Sign in...",
"server": "boarderless-mcp-bridge",
"version": "0.1.28",
"timestamp": "2026-06-16T19:07:00.000Z"
}All configuration uses environment variables — no hardcoded paths, no user-specific assumptions.
Variable | Default | Description |
|
| Canvas URL to connect to. Set to |
|
| Chrome DevTools URL. Change if you use a different debug port. |
| (auto-detected) | Full path to browser executable. Set if auto-detection misses your browser. |
| (OS-standard, see below) | Override the persistent browser profile directory. |
| MCP process working directory | Absolute directory where canonical |
Default profile directories (resolved from OS env vars, never hardcoded):
Windows: %LOCALAPPDATA%\boarderless-mcp-profile
macOS: ~/Library/Application Support/boarderless-mcp-profile
Linux: ~/.boarderless-mcp-profile
get_server_status (always call this first)Returns a full diagnostic report. Input: none. See Diagnosing Issues above.
get_board_stateReturns the canvas as a structured, render-ordered JSON ledger.
Input: None ({})
Output:
{
"schema": "boarderless.boardSnapshot.v1",
"generatedAt": "2026-06-16T19:00:00.000Z",
"objectCount": 3,
"objects": [
{
"id": "rect-1",
"objectKind": "shape",
"objectType": "rect",
"x": 20, "y": 20,
"rawWidth": 80, "rawHeight": 50,
"fill": "#ff0000", "stroke": "#ff0000",
"strokeWidth": 4, "opacity": 1, "rotation": 0
}
]
}mutate_objectModifies coordinates or style properties of a canvas object. Writes to the undo stack.
Required: id (string)
Optional mutable fields: x, y, width, height, rotation, opacity, fill, stroke, strokeWidth, text, fontSize, fontFamily, align, cornerRadius, edgeFeather, points, scaleX, scaleY
remix_styleApplies one canonical Boarderless palette to selected shape/text Objects—or explicitly to the whole board—as one undoable history step. Images remain unchanged.
Required: paletteId — "boarderless" | "midnight" | "sunroom" | "editorial" | "earthbound"
Optional: scope — "selection" (default) | "board"; ids — explicit selection-scope Object IDs
calculate_export_boundsReturns the collective bounding box of all active objects.
Input: None ({})
Output: { bounds: { x, y, width, height, left, top, right, bottom } }
create_objectCreate a new object (text or shape: rect, ellipse, triangle, arrow) on the canvas.
Required: type — "text" | "rect" | "ellipse" | "triangle" | "arrow"
Optional: x (number), y (number), width (number), height (number), text (string), fill (string), stroke (string), strokeWidth (number)
delete_objectsDelete one or more objects by their IDs from the canvas.
Required: ids (array of strings)
history_undoUndo the last action on the canvas.
Input: None ({})
history_redoRedo the next action in the history queue on the canvas.
Input: None ({})
group_objectsGroup multiple canvas objects under a unique groupId.
Required: ids (array of strings)
ungroup_objectsUngroup objects belonging to a specific groupId.
Required: groupId (string)
reorder_objectReorder z-index layering of an object (bring to front, send to back, forward, backward).
Required: id (string), action — "front" | "back" | "forward" | "backward"
get_board_workspaceReturns the active filesystem directory, autosave state, and filename pattern. Agents should call this before their first canvas mutation.
set_board_workspaceSets the absolute project directory used for board artifacts. The directory is created when necessary.
Required: directory (absolute path)
export_board_fileFlushes the browser's current board and atomically writes its complete schema-v2 snapshot, including JSON-safe image assets.
Optional: filename — a single filename ending in .bdrl.json; omitting it uses the stable autosave name.
import_board_fileReads, validates, imports, and opens a board from the configured workspace.
Required: filename — a single .bdrl.json filename in the workspace
export_boardExports the current canvas to PNG, PDF, or SVG.
Required: format — "png" | "pdf" | "svg"
Optional: mode — "canvas" (default) | "selection", filename — output name override
Note: SVG and PDF require a Pro plan. The error response will indicate this clearly.
graduation_rename_photosRenames photo files in a local directory to sequential format. No browser required.
Required: seniorsDir (absolute path), mode ("sequential" | "gap_fill")
graduation_standardize_imagesConverts progressive JPEGs and HEIC files to baseline RGB JPEGs. No browser required.
Required: seniorsDir (absolute path)
Add to %APPDATA%\Claude\claude_desktop_config.json (Windows) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS).
{
"mcpServers": {
"boarderless": {
"command": "node",
"args": ["/absolute/path/to/boarderless.app_MCP/src/mcp-stdio-server.js"],
"env": {
"BOARDERLESS_MCP_APP_URL": "https://boarderless.app/canvas",
"BOARDERLESS_MCP_BROWSER_URL": "http://127.0.0.1:9222",
"BOARDERLESS_WORKSPACE_DIR": "C:\\absolute\\path\\to\\your\\project"
}
}
}
}Running npm run setup will write this automatically.
Add to your openclaw.json under mcp.servers:
"mcp": {
"servers": {
"boarderless": {
"command": "node",
"args": ["/absolute/path/to/boarderless.app_MCP/src/mcp-stdio-server.js"],
"env": {
"BOARDERLESS_MCP_APP_URL": "https://boarderless.app/canvas",
"BOARDERLESS_MCP_BROWSER_URL": "http://127.0.0.1:9222",
"BOARDERLESS_WORKSPACE_DIR": "/absolute/path/to/your/project"
}
}
}
}See the mcp-config.json file generated by npm run setup for the exact config block to paste.
VS Code / GitHub Copilot can use Boarderless as a local stdio MCP server through .vscode/mcp.json.
Joel selected Option A: browser-mediated visible-session bridge for future remote readiness. Boarderless will not host user data or server-side boards; user data stays user-managed, user-owned, and user-controlled. See docs/remote_session_bridge_spec.md.
@boarderless/mcp-server v0.1.28 is not a hosted ChatGPT App or Microsoft Copilot Studio connector. npm distributes the local stdio connector only.
OpenAI outstanding: public HTTPS MCP resource server, OAuth 2.1 authorization-code flow with PKCE, protected-resource and authorization-server discovery metadata, ChatGPT client registration/callback, scoped token validation, and a secure relay from the hosted service to the user's visible Boarderless browser session.
Microsoft outstanding: public Streamable HTTP MCP endpoint, OAuth 2.0 through DCR/discovery or manual client registration, Copilot callback registration, scoped token validation/refresh/revocation, and the same secure remote-to-visible-canvas relay.
Shared outstanding: remote-safe tool policy, explicit controls for writes, rate limits, audit logging, privacy/retention rules, secret management, security review, end-to-end tests, and platform submission/review.
OAuth identifies and authorizes a user; it does not make a cloud service capable of reaching that user's localhost browser or Chrome DevTools port. The selected path is a user-approved outbound browser bridge bound to the visible tab/canvas, not a hidden cloud board. See the complete hosted-connector checklists, the docs-only remote adapter plan, the browser bridge spec, and the operator gates.
Boarderless MCP is a local connector. The full Boarderless privacy policy is published at https://boarderless.app/privacy (also declared in manifest.json privacy_policies).
Summary of how this MCP server handles data:
Data collection: The server itself collects no analytics and sends no telemetry. It reads canvas state from your own signed-in, human-visible Boarderless browser tab via the Chrome DevTools Protocol on 127.0.0.1:9222.
Usage and storage: Board snapshots (.bdrl.json) and exports are written only to the local workspace directory you configure. Nothing is uploaded to Boarderless servers by this MCP server.
Third-party sharing: None. The server communicates only with your local browser and the Boarderless canvas page you are signed into. It never inherits your Google identity or Google Drive access.
Data retention: Local board files remain on your machine under your control; delete them at any time. The server keeps no databases, queues, or server-side copies.
Contact: Questions or concerns — open an issue at https://github.com/CrackenReleased/boarderless.app_MCP/issues or use the contact channel listed at https://boarderless.app/privacy.
This MCP server is open source under the Apache 2.0 license. Contributions are welcome!
Bug reports: Open an issue describing the error_code you received and your get_server_status output.
New tools: Tools should be added as siloed handlers in mcp-stdio-server.js with structured makeError / makeSuccess responses. Every new tool must have a corresponding regression test.
Platform support: If your browser or OS isn't detected, open a PR adding its path to getBrowserCandidates() — all paths must use OS env vars, never hardcoded usernames.
After the initial npm publication is approved, every production MCP version must be delivered to both GitHub and npm under the same version number. A production release is not complete until npm test and npm publish --dry-run --access public pass, the Git commit is pushed, npm publish --access public succeeds, and npm view @boarderless/mcp-server version returns that exact version. Documentation-only commits that do not change the MCP package version do not require an npm publication.
Licensed under the Apache License, Version 2.0. See LICENSE for details.
Export the current Boarderless canvas to PNG, PDF, or SVG. Requires the user to be authenticated. Returns a structured error with resolution steps if export fails.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Export scope. Defaults to 'canvas'. | |
| format | Yes | Export format. | |
| filename | No | Optional output filename override. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a note about structured error resolution, but fails to clarify the destructive hint annotation (destructiveHint=true). Exporting typically implies no destruction, so the agent needs to know what side effects occur. The description does not disclose whether the canvas is modified or if a file is created/destroyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences efficiently convey purpose and a key requirement (authentication) and error behavior. No extraneous words. However, it could be slightly improved by front-loading the most critical info first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete given the presence of a destructiveHint annotation and no output schema. It does not explain return format (e.g., file URL, download), what 'destructive' means here, or when to use this over the sibling 'export_board_file'. The agent lacks enough context to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the schema (100% coverage). The description adds no additional meaning or context beyond the schema, which already defines format, mode, and filename with enum constraints. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export'), the specific resource ('current Boarderless canvas'), and the target formats (PNG, PDF, SVG). This provides a clear, specific purpose. However, it does not differentiate from the sibling 'export_board_file', which likely has a different export scope or resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions a prerequisite (authentication) but provides no guidance on when to use this tool vs. alternatives (e.g., 'export_board_file'). There is no mention of when-not-to-use or context for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Atomically save the current canonical schema-v2 Boarderless board as a .bdrl.json file inside the configured workspace. Without filename, uses a stable board-name-and-id autosave filename.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Optional single filename ending in .bdrl.json. Subdirectories and path traversal are rejected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds atomicity and workspace location details, which is useful but does not disclose overwrite behavior or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The primary action is front-loaded, and the default filename behavior is efficiently stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description adequately covers purpose, default behavior, and atomicity. It could mention success/failure indicators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds value by explaining the default behavior when no filename is provided, which goes beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves the current canonical schema-v2 Boarderless board as a .bdrl.json file in the configured workspace. It is specific but does not differentiate from the sibling 'export_board' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'export_board' or 'import_board_file'. The description lacks context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the local workspace directory where Boarderless MCP automatically saves canonical .bdrl.json files after every successful canvas mutation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds valuable behavioral context: that the workspace is used for automatic saving of .bdrl.json files after every successful canvas mutation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveying all necessary information, front-loaded with the main action. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully explains what the tool returns and its significance. Complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no parameter-specific info, which is fine since there are none. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the local workspace directory, specifying its role in saving canonical .bdrl.json files after mutations. This distinguishes it from sibling tools like set_board_workspace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use it (to get the workspace path), but does not explicitly say when not to use it or provide alternatives. However, the context of sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a full diagnostic status report for the Boarderless MCP server. Use this first to verify connectivity, authentication, and tool availability before attempting canvas operations. Includes browser connection state, authentication status, canvas bridge health, and per-tool error counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotation 'readOnlyHint: true', the description details the diagnostic information returned: browser connection state, authentication status, canvas bridge health, and per-tool error counts. This adds concrete behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second provides usage guidance and content. Front-loaded with key information, no redundant or extraneous text. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a diagnostic status tool with no parameters and no output schema, the description fully covers purpose, usage context, and return content. Leaves no ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description adds value by listing the components of the report, which compensates for the lack of parameter details. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns a 'full diagnostic status report' for the 'Boarderless MCP server'. The verb 'returns' and specific resource distinguish it from sibling tools like 'export_board' or 'render_board_in_blender', which focus on canvas operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool 'first to verify connectivity, authentication, and tool availability before attempting canvas operations'. Provides strong contextual guidance, though it does not specify when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename and number photo files inside a directory to a sequential format (e.g. seniorname_01.jpg). Operates on the local filesystem — no browser required. Returns a structured report of renamed files and any errors encountered.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | 'sequential' numbers files 01–XX strictly. 'gap_fill' preserves existing numbers and fills gaps. | |
| seniorsDir | Yes | Absolute path to the folder containing photos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false. The description adds that it renames files in place and returns a structured report, but does not clarify if original files are preserved (e.g., backup) or detail the renaming behavior beyond numbering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that directly state the tool's action, scope, and output. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description adequately explains the renaming process and return value (structured report). It lacks details on supported file types (implied .jpg) and error scenarios, but is generally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% with descriptions for both parameters. The description adds value by explaining the sequential format example and clarifying the two modes ('sequential' strict numbering, 'gap_fill' preserving existing numbers). This goes beyond the schema's enum description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly specify renaming and numbering photos in a directory with an example format (seniorname_01.jpg). It distinguishes from siblings like 'graduation_standardize_images' which likely handles image standardization, not renaming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it operates on the local filesystem with no browser required, implying when to use it (local batch renaming). However, it does not explicitly mention when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan and convert progressive JPEGs and HEIC files inside subdirectories into standard baseline RGB JPEGs. Operates on the local filesystem — no browser required. Returns a structured report of converted files and any errors encountered.
| Name | Required | Description | Default |
|---|---|---|---|
| seniorsDir | Yes | Absolute path to the folder containing photos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but the description only says 'convert' without clarifying whether original files are overwritten or new files are created. It does not add behavioral context beyond what annotations provide, and the ambiguity could mislead an agent about the impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with front-loaded action and resource. It covers input, operation, context, and output efficiently, though a slightly more structured format could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers input, action, output (structured report), and context (subdirectories, local filesystem). It lacks details like handling of other formats or error scenarios, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter already has a clear description ('Absolute path to the folder containing photos'). The tool description adds no additional meaning, so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans and converts progressive JPEGs and HEIC files into standard baseline RGB JPEGs. The verb 'scan and convert' is specific, and the resource (images in subdirectories) is well-defined. It distinguishes from sibling tools like graduation_rename_photos which focuses on renaming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'operates on the local filesystem — no browser required,' providing context for when to use it (local automation vs. browser-based tools). However, it does not explicitly state when not to use it or mention alternatives, leaving usage guidance somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a canonical schema-v2 .bdrl.json file from the configured workspace, import it into Boarderless, switch the live canvas to it, and refresh its automatic local snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Single .bdrl.json filename inside the configured workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description discloses additional behavioral traits: the live canvas is switched and the automatic snapshot is refreshed. This goes beyond the annotations, but does not fully cover side effects like previous canvas state or undo behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence listing multiple sequential actions (read, import, switch, refresh), which is slightly cluttered. While it is not overly verbose, front-loading the key action and breaking into clearer steps would improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter and no output schema, the description covers the main effects but omits error cases, file existence checks, and return value details. It assumes the workspace is configured, which is mentioned but not elaborated. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'filename', describing it as a .bdrl.json filename in the configured workspace. The description adds 'canonical schema-v2' specificity, but this is a minor enhancement. Baseline 3 is appropriate since the schema already carries the primary semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a specific file format (.bdrl.json, schema-v2) from the configured workspace, imports it, switches the live canvas, and refreshes the snapshot. The verb 'import' and resource 'board file' are explicit, and the tool is easily distinguished from siblings like 'export_board_file' and 'set_board_workspace'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for importing board files but does not explicitly state when to use this tool versus alternatives. No when-not guidelines or references to sibling tools are provided, so the agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 3D studio render of the current canvas using Blender. Automatically captures the board snapshot, decodes base64 assets, builds a 3D scene with lighting/camera alignment, and exports a finished PNG image. Requires Blender to be installed and available on the system environment path.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | Blender render engine. BLENDER_EEVEE is fast; CYCLES is high-fidelity path tracing. Defaults to BLENDER_EEVEE. | |
| filename | No | Optional output render filename (e.g. render.png). Saved to the active project workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds process details (capture snapshot, decode assets, build scene, export PNG) and the requirement for Blender. However, annotations indicate readOnlyHint=false, suggesting potential modification, while the description implies read-only behavior ('captures' without mention of mutation). This mild contradiction reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The first sentence states purpose, the second elaborates process and requirement. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional params, no output schema), the description covers the main purpose, process, and a key requirement (Blender). Missing details on output resolution and potential side effects, but adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description provides no additional meaning for the two parameters (engine, filename). Baseline 3 is appropriate since the schema is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generate a 3D studio render' and the resource 'current canvas'. It distinguishes from sibling tools like export_board and export_board_file by specifying the use of Blender for 3D rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for 3D rendering of the canvas, but it does not explicitly state when to use this tool over siblings (e.g., export_board for flat exports). It mentions the Blender requirement but lacks when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the absolute local workspace directory used for automatic and explicit .bdrl.json board files. Call this once at the beginning of work when the MCP process was not launched from the intended project directory.
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | Absolute path to the agent's current project/workspace directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true; description reinforces it's a setter that changes state. Adds timing advice but doesn't elaborate on what is destroyed. Adequate given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded purpose, no extraneous words. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one parameter and no output schema. Covers purpose, parameter, and usage timing. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides a good description for the single parameter. Description does not add new semantics beyond reinforcing 'absolute local workspace directory'. Baseline 3 for 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'set' and resource 'absolute local workspace directory'. Distinguishes from sibling 'get_board_workspace'. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'call this once at the beginning of work when the MCP process was not launched from the intended project directory', providing clear context. Implies when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.28export_boardexport_board_fileget_board_workspaceget_server_statusgraduation_rename_photosgraduation_standardize_imagesimport_board_filerender_board_in_blenderset_board_workspaceScored across 9 tools
Each tool has a distinct purpose: board export/import, workspace management, diagnostics, file renaming, image standardization, and Blender rendering. No tools overlap in functionality.
Most tools use a consistent verb_noun pattern (export_board, get_board_workspace, set_board_workspace, etc.). Two tools have a 'graduation_' prefix, which slightly deviates from the pattern but remains consistent within their own subset.
With 9 tools covering board operations, workspace management, diagnostics, and file processing, the count is well-scoped for the server's purpose. No tools appear superfluous.
The tool set focuses on export, import, and workspace management but lacks board creation, editing, and deletion tools. This is a notable gap for a board server, as agents cannot manipulate canvas content directly.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create, read and live-edit visual boards, Kanban plans, Gantt timelines and diagrams with AI agents.
Create and edit architecture diagrams from your AI agent; get an SVG and a live editable canvas.
Company brain for AI agents — temporal knowledge graph search, exploration, and durable memory.
Persistent docs and memory for AI agents — read, write, organize & search a shared workspace.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CrackenReleased/boarderless.app_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
