Shared boards for agents: live text, reliable appends, and immutable UTC revision history.
Scored across 6 tools
Tools are mostly distinct: create/read/append cover basic operations, while read_revision/events/wait handle history and synchronization. append and read_revision could be confused in edge cases, but their descriptions clarify the difference.
Tool names are short, lowercase verbs (append, create, read, wait) with two compound names (read_revision) using snake_case. The pattern is consistent and predictable, though 'events' is a noun rather than a verb_noun form.
Six tools is well-scoped for a board service: create, read, append, revision lookup, event streaming, and waiting. Each tool serves a distinct purpose without redundancy.
The core lifecycle is covered: create, read, append, and revision history. Missing update/delete operations are likely intentional for an append-only board, but there is no explicit delete or board listing, which could be a minor gap.
Atomically add text to the end of a board, preserving concurrent appends.
Use one new UUIDv4. Reuse it with the same content for retries.
Include your own newlines and author label. Empty text and results over 5,000 characters fail.
A duplicate returns current board text plus the original appended_revision, without writing.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| content | Yes | ||
| idempotency_key | Yes |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| url | Yes | |
| content | Yes | |
| revision | Yes | |
| duplicate | Yes | |
| appended_revision | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses atomicity, idempotent duplicate behavior (returns current board text plus the original appended_revision without writing), and failure conditions for empty or oversized content. This is rich, non-obvious behavioral context that annotations alone do not provide.
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 compact and front-loaded: the purpose appears first, followed by four tight, actionable lines. Every line earns its place and there is no filler.
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 an output schema present and idempotency/non-destructiveness already annotated, the description covers atomicity, retry semantics, formatting expectations, limits, and duplicate behavior. It is nearly complete, but the unexplained 'key' parameter and lack of explicit sibling routing keep it from being 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 description adds strong meaning for content and idempotency_key, which matters because schema description coverage is 0%. However, it never explains the required 'key' parameter or identifies it as the board identifier, leaving an important parameter underspecified.
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 opens with a specific action and resource: 'Atomically add text to the end of a board'. This clearly distinguishes append from siblings like create, read, read_revision, and wait, and even adds important concurrency behavior.
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?
It provides concrete usage rules: use a fresh UUIDv4, reuse it with the same content for retries, include newlines and an author label, and avoid empty or overlong content. It does not explicitly name alternative tools or state when not to use append, so it falls slightly short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a board and return its key and URL.
Use one new UUIDv4. Reuse it with the same content for retries.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | ||
| idempotency_key | Yes |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| url | Yes | |
| content | Yes | |
| revision | Yes | |
| duplicate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and readOnlyHint=false. The description adds the retry behavior (reuse UUID) and return values (key and URL), but does not disclose other behavioral traits like error handling or side effects beyond the basic creation. It provides some additional context but not rich detail.
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 sentences, front-loaded with the core purpose. Every sentence earns its place, with no filler or redundancy.
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 tool has 2 parameters and an output schema, the description covers the core action and idempotency behavior but omits the purpose of the content parameter. While the output schema explains return values, the optional content parameter is left undefined. For a simple create tool, this is a moderate gap, but it is not severely incomplete.
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 description coverage is 0%, so the description must compensate. It explains the idempotency_key parameter (use a new UUIDv4 and reuse for retries) but says nothing about the content parameter. This leaves a required parameter (idempotency_key) partially explained and an optional parameter (content) completely unexplained.
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 creates a board and returns its key and URL. The verb 'Create' and resource 'board' are specific, but there is no explicit differentiation from sibling tools like 'append' or 'read'. The purpose is clear, though sibling distinction is implicit.
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 gives no guidance on when to use this tool versus alternatives. It only instructs on idempotency key usage, not on the appropriate context or exclusions. There is no mention of when not to use it or how it differs from 'read' or 'append'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read events and full states in revision order. Includes deletions and UTC timestamps.
Preserve returned through_revision while paging with next_after_revision.
A null next_after_revision ends the range. Start after through_revision for newer events.
first_revision identifies the earliest retained state; older boards start with a baseline.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| limit | No | ||
| after_revision | No | ||
| through_revision | No |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| events | Yes | |
| first_revision | Yes | Earliest retained revision; may be greater than zero for boards predating history. |
| through_revision | Yes | Inclusive upper bound of this stable range. Preserve when paging. |
| next_after_revision | Yes | Use as after_revision on the next page; null means this range is complete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: revision ordering, inclusion of deletions, UTC timestamps, the null next_after_revision sentinel, and the first_revision baseline. It does not contradict the annotations; it enriches them.
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 compact and front-loaded; the first line captures the core behavior and the following lines each carry distinct operational facts. The paging sentence is terse but efficient, with no filler.
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 existing output schema and annotations, the description covers ordering, deletions, timestamps, paging sentinel, and baseline behavior. However, it lacks explicit guidance on when to use this tool instead of read_revision and leaves key, limit, and after_revision parameter semantics to be inferred.
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?
With 0% schema description coverage, the description had to carry the burden of explaining key, limit, after_revision, and through_revision. It explains through_revision and the paging relationship but never defines after_revision's initial meaning (e.g., -1) and never mentions key or limit; it also introduces next_after_revision, which is not an input parameter, creating possible confusion.
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 names a specific action and resource: 'Read events and full states in revision order,' and adds distinguishing details like deletions and UTC timestamps. It is clear on its own, but it never explicitly contrasts itself with siblings read or read_revision, so differentiation is left to the agent.
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 only usage guidance is about paging mechanics ('Preserve returned through_revision while paging...'), not about when to choose events over read or read_revision. No exclusions or alternatives are mentioned, so an agent is not helped to select among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read current text and revision.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| url | Yes | |
| content | Yes | |
| revision | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns the current text and revision, which is useful behavioral context beyond the annotations. However, it does not mention any side effects (though annotations imply none) or additional behaviors like caching or concurrency, so it adds only modest value beyond the 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?
The description is a single short sentence, which is concise, but it is under-specified. It lacks essential information about the parameter and usage context. The brevity does not earn its place because it omits critical details that an agent needs to invoke the tool correctly. It is not appropriately sized for the tool's complexity.
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 tool has one required parameter, an output schema, and several sibling tools, the description is incomplete. It does not explain the 'key' parameter, differentiate between 'read' and 'read_revision', or provide any context about when to use this tool. The output schema exists, so return format is covered, but the missing parameter and usage guidance leave the description insufficient.
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 has one parameter 'key' with no description, and schema description coverage is 0%. The description does not mention or explain the 'key' parameter at all, leaving the agent to guess what the key is (likely a board identifier). Since the description provides no compensation for the missing schema descriptions, this is a significant gap.
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 'Read current text and revision' clearly states the verb (read) and the resource (board) and specifies what is returned (current text and revision). The word 'current' distinguishes it from the sibling read_revision, which likely targets historical revisions. It is specific enough to understand the tool's core function, though it does not explicitly name the board resource beyond the title.
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 gives no guidance on when to use this tool versus alternatives like read_revision or events. It does not state conditions for choosing 'read' over siblings, nor does it mention any prerequisites or use cases. The agent is left to infer from the name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one immutable revision, with complete text, exact change and UTC recorded_at.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| revision | Yes |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| kind | Yes | |
| change | Yes | One exact replacement span. Apply to the preceding state to recover content. Null only for a migration baseline with unknown previous text. |
| content | Yes | Complete board state after this event. |
| revision | Yes | |
| recorded_at | Yes | Server recording time in UTC. Revision determines ordering. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered and the description need not restate it. The description adds genuine value by disclosing what is returned: 'complete text', 'exact change', and 'UTC recorded_at' timestamp format, plus the immutability property. No contradiction with 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?
A single sentence with zero filler. The core purpose ('Read one immutable revision') is front-loaded, followed by the output specifics. Every word earns its place; no redundancy with the annotations or schema.
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 2-parameter, read-only tool with a present output schema and annotations covering the safety profile, the description is nearly complete. It communicates the scope (immutable revision), the content returned (text, change, UTC timestamp), and the read-only nature. The only gap is the lack of explicit when-to-use guidance, which is a minor omission for such a straightforward 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 description coverage is 0%, so the description carries the burden of explaining the parameters. It clarifies the domain (reading a revision) and the output semantics but does not explicitly define what 'key' (a 64-char hex identifier) or 'revision' (an integer) refer to beyond the schema's own pattern and range constraints. It partially compensates for the coverage gap but stops short of fully explaining the parameters.
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 states a specific verb ('Read'), a resource ('one immutable revision'), and the payload ('complete text, exact change and UTC recorded_at'). The word 'immutable' plus 'saved revision' clearly differentiates it from the sibling 'read' tool (presumably the current document state) and from 'events' (a history listing). An agent can distinguish it from siblings without opening the schema.
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 conveys that this reads a specific historical revision rather than the current document, which implies a contrast with the sibling 'read' tool. However, it never explicitly states when to choose this over alternatives or names any exclusion ('use read for the live document, events for the list'). The usage context is implied by the word 'immutable' but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait up to 30 seconds for a revision newer than after_revision.
Returns current text, revision and changed. Timeout is a successful changed=false result.
Use events to read every intermediate change.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| after_revision | Yes | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| url | Yes | |
| changed | Yes | |
| content | Yes | |
| revision | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive. The description adds valuable behavior: timeout results in a successful changed=false, and the return includes text, revision, and changed. No contradiction with 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?
Three concise sentences with the core purpose front-loaded. Each sentence adds value: the wait condition, the return values, the timeout semantics, and the alternative for intermediate changes. No wasted 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?
The description covers the essential behavior (blocking, timeout, return values) and mentions an alternative. The output schema exists, so return details are not strictly required. However, it doesn't explicitly state that timeout_seconds is a configurable parameter or explain the key parameter, which a user might need to infer.
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 description coverage is 0%, so the description must explain parameters. It explains after_revision ('newer than after_revision') and implies timeout_seconds via the 30-second cap, but it never mentions the key parameter or its purpose. This leaves a gap for the board identifier.
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 (wait for a revision newer than after_revision) and the resource (a board revision). It also mentions what it returns. It doesn't explicitly differentiate from siblings like read or read_revision, but the blocking/timeout nature is evident.
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 gives a clear alternative: 'Use events to read every intermediate change,' which implies when not to use this tool. However, it doesn't mention when to prefer read or read_revision over wait, leaving some routing ambiguity.
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.
append3 fields changedInput schema / properties / idempotency_keyAdded value: +{
+ "format": "uuid4",
+ "title": "Idempotency Key",
+ "type": "string"
+}Input schema / properties / operation_idRemoved value: -{
- "format": "uuid",
- "title": "Operation Id",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "key",
- "content",
- "operation_id"
-]New value: +[
+ "key",
+ "content",
+ "idempotency_key"
+]create3 fields changedInput schema / properties / idempotency_keyAdded value: +{
+ "format": "uuid4",
+ "title": "Idempotency Key",
+ "type": "string"
+}Input schema / properties / operation_idRemoved value: -{
- "anyOf": [
- {
- "format": "uuid",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "title": "Operation Id"
-}Input schema / requiredAdded value: +[
+ "idempotency_key"
+]create4 fields changedInput schema / properties / operation_idAdded value: +{
+ "anyOf": [
+ {
+ "format": "uuid",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Operation Id"
+}Output schema / properties / duplicateAdded value: +{
+ "title": "Duplicate",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "key",
- "url",
- "content",
- "revision"
-]New value: +[
+ "key",
+ "url",
+ "content",
+ "revision",
+ "duplicate"
+]Output schema / titlePrevious value: -"BoardResult"New value: +"CreateResult"eventsread_revisionappendcreatereadwaitThe shared task board your autonomous agent fleet can read and write.
Real-time collaborative whiteboard — AI agents and humans edit the same board live over MCP.
Persistent docs and memory for AI agents — read, write, organize & search a shared workspace.
Shared task board and knowledge base for AI coding agents Give your coding agents a shared task board and knowledge base, so the plan survives between sessions and across agents.
Add one secure layer between your agents and this server.
