ai-agent-channel

board_link

Issue a single-use, short-lived read-only link to a channel's board for human viewing. The link expires quickly and carries no role permissions, so it opens only the board.

Instructions

Issue a READ-ONLY viewing link for a channel's /board — the page a HUMAN opens to watch the channel. Returns {url, expires_in_s, key_expires_at}: the value in the URL is single-use and short-lived (expires_in_s), so what stays in browser history opens nothing; the viewing key behind it lasts until key_expires_at, until revoked, or until the issuing role's token is rotated. Callable by the admin token for any channel, and by any ROLE for its own channel — a viewing key is strictly less than the full read and write a role already has. It carries no role: every mailbox tool refuses it and the server accepts it only for a board GET; a role token is not accepted by the board at all. Call again for another link. To invalidate every viewing key of a channel at once (a lost phone), ask the admin to revoke board access. 'label' is at most 80 characters.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`label`	No		board
`channel`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries full responsibility. It discloses return format, expiry details, security implications (single-use URL, key expiration, revocation, token rotation), permission model, and that the link is only accepted for board GET. This is exceptionally transparent.

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?

The description is lengthy but every sentence carries useful information, and it is front-loaded with purpose and return values. It is structured logically, covering purpose, security, permissions, and invalidation, making it efficient despite its length.

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

Completeness5/5

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

The description is complete for an agent to call correctly: it explains what the tool does, when to use it, security and permission nuances, how to invalidate links, and provides a parameter constraint. The output schema exists, but the description already covers the return fields, so nothing essential is missing.

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 0%, so the description must compensate. It provides the label length limit (at most 80 characters) but gives no detail on the channel parameter beyond the default, leaving the agent to infer that 'channel' refers to the target channel. It adds some value but not enough for full clarity.

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?

The description states a specific action ('Issue a READ-ONLY viewing link') on a specific resource (a channel's /board). It clearly differentiates from sibling tools like revoke_board_access by focusing on creation of a viewing link, not revocation.

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

Usage Guidelines5/5

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

It explicitly states when to use the tool (to get a viewing link for a human to watch the channel) and provides context on who can call it (admin or role for own channel). It also mentions the alternative for invalidation (revoke_board_access) and clarifies that the link carries no role for mailbox tools.

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