Loading ToolBench
MCP server that bridges MarkLayer annotations to AI coding agents.
MarkLayer MCP has significant definition quality gaps. Tool names follow verb_noun conventions and are clear (marklayer_connect_room, marklayer_list_annotations), but parameter schemas are incomplete or missing. Most critically, input schemas visible in the tool list show only partial schema information, parameter types for 'target' objects in create_annotation and suggest_edit are declared as generic 'object' with no nested field documentation. Parameter descriptions exist but are minimal (10-40 chars, below the 72-char baseline for production tools). The server lacks structured output documentation, there is no visible schema for what tools return, forcing LLMs to guess result structure. Error handling is not documented. The server's focus on integration with MarkLayer rather than general-purpose agent patterns limits applicability.
Connect to a MarkLayer room using a room reference (URL or bare id). Accepts formats like 'abc123', 'https://marklayer.app/s/abc123', or 'https://marklayer.app/s/abc123?something'.
Create a new annotation on the page. Use this when auditing, reviewing, or providing feedback on the page.
Dismiss an annotation that cannot be acted on, with a reason the human can read.
Get details of a specific annotation, including replies and attachments.
List all annotations in the connected room.
Resolve an annotation with a summary after making requested code changes.
Suggest an exact text edit instead of a comment, providing a diff for the human to accept rather than prose describing the change.
No output schemas documented. LLMs cannot infer the structure or fields of responses from any tool. This violates the pattern:tool and pattern:response-shaper requirements and forces agents to guess at result structure.
Parameter descriptions are minimal (10-40 chars, well below the 72-char production baseline). 'List all annotations in the connected room' lacks context on what fields are returned or when to call it. Descriptions should answer WHAT the tool does, WHEN to use it, and key result structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
Watch for new annotations in the connected room in a loop.
Complex parameters ('target' object in marklayer_create_annotation and marklayer_suggest_edit) are typed as 'object' with no nested field documentation. 'Element selector and markdown context' is not specific enough for LLMs to construct valid objects. Need explicit nested schema with field names, types, and descriptions.
No error handling documentation. Tools like marklayer_connect_room (which connects to external rooms) and marklayer_watch_annotations (which polls) could fail in multiple ways (network, invalid room ID, permission denied). No guidance on retryability, user-fixable errors, or recovery steps.
marklayer_watch_annotations is described as 'Watch for new annotations in the connected room in a loop.' This suggests a polling behavior that may not be compatible with stateless MCP request-response semantics. Clarify whether this is a long-lived connection (not standard for MCP) or a single request that returns current annotations.
Tool descriptions do not indicate side effects or state changes. marklayer_resolve_annotation, marklayer_dismiss_annotation, and marklayer_create_annotation modify state, but descriptions do not explicitly say 'This creates/modifies/resolves an annotation.' Agents need to know which calls have irreversible consequences.