Playbook

Get board

get_board

Read-only

Get details of a specific board by its token. Returns the board's title, description, asset count, parent board, and child board count. published_page says whether the board's public page is live (active), its url (null unless live) and the template its page design uses (can be set on a page that is not live). asset_count covers the board AND every board nested under it (each group/stack counted once); list_assets on a board returns only assets sitting directly on it unless you pass nested_assets: true, so compare the count against that, not the plain listing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "token": "<token>"
    },
    "name": "get_board"
  }
}

Input Schema

Name	Required	Description	Default
`token`	Yes	Board token, as returned by list_boards, list_board_children or ai_search — the parameter name is `token`, not `board_token`. The id in a share link (`/s/{workspace}/{id}`) is NOT a board token: pass the link to resolve_share_link, which returns the board. Nothing converts a published page URL: look that board up by title with list_boards `query` or ai_search instead of taking an id out of a URL, a spreadsheet or an earlier session.
`organization`	No	Workspace slug, as returned by list_organizations. Omit it when the account has a single workspace — it is then resolved from your token. Pass it only when the account has several, or when you mean a workspace other than the obvious one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```

Changed1 schema field changedOct 7, 2026

changedInput schema / properties / token / description

Previous value: -"Board token, as returned by list_boards, list_board_children or ai_search — the parameter name is `token`, not `board_token`. The id in a shared board link or a published page URL is NOT a board token and nothing converts one: look the board up by title with list_boards `query` or ai_search instead of taking an id out of a URL, a spreadsheet or an earlier session."New value: +"Board token, as returned by list_boards, list_board_children or ai_search — the parameter name is `token`, not `board_token`. The id in a share link (`/s/{workspace}/{id}`) is NOT a board token: pass the link to resolve_share_link, which returns the board. Nothing converts a published page URL: look that board up by title with list_boards `query` or ai_search instead of taking an id out of a URL, a spreadsheet or an earlier session."

Changed3 schema fields changedOct 5, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / context

Removed value: -{
-  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "token",
-  "context"
-]New value: +[
+  "token"
+]

First observedOct 2, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and destructiveHint=false, so safety is covered. The description nevertheless adds non-obvious behavior: asset_count aggregates descendants while list_assets only lists direct assets, and published_page.url is null unless live while template can be set on a non-live page. Those are genuine semantic quirks an agent could not infer from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, followed by return-field detail and one behavioral caveat. The final sentence is long and clause-heavy but every clause carries a distinct warning about misreading asset_count, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description usefully enumerates the returned fields and their edge cases, which is exactly what is needed for a single-object read. It stops short of covering error conditions, such as what happens with an invalid or unknown token, but the shape of the response is clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameter descriptions are exceptionally detailed, so the baseline is 3. The description only restates 'by its token' and adds no format or resolution detail for token or organization beyond what the schema already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Get details of a specific board by its token.' It then enumerates exactly which fields come back (title, description, asset count, parent board, child board count), which lets an agent separate this from list_boards, list_board_children or list_board_descendants.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives real guidance on how to interpret the result against list_assets, telling the agent to compare asset_count with a nested_assets:true listing rather than the plain one. However, it never states when to call get_board instead of the sibling list tools, and the routing to resolve_share_link / list_boards lives in the token schema field rather than the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Playbook tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?