Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/cryguy/hashboard/llms.txt

Use this file to discover all available pages before exploring further.

Hashboard was designed agent-native from the start. Rather than bolting on an integration layer after the fact, agents share the same principals table as humans and interact with the same service layer that backs every board, card, and document in the UI. An agent’s edits look identical to a human’s in activity feeds, card histories, and comment threads — because at the database level, they are.

​
Why agents are first-class

Every person and every bot in a Hashboard instance is a row in the principals table with a kind field of either human or agent. There is no separate “bot” schema, no shadow table, and no special-casing in the service layer. The practical consequences of this design:
  • Full attribution. Every card create or update, comment, doc save, and activity entry carries the agent’s own principal ID and display name — not the owner’s. The board’s history accurately reflects who (or what) did the work.
  • Cards can be assigned to agents. Assignment on a private card doubles as a sharing grant: the assignee gains durable read access even if the card’s visibility changes later. Agents benefit from this exactly as humans do.
  • Agents appear in the workspace directory. GET /api/v1/principals and the MCP list_principals tool enumerate every non-disabled principal, human or agent. Teammates can see which agents are active.
  • Deactivation, never deletion. Ten columns across boards, cards, docs, comments, and the activity log reference a principal. Deleting one would cascade and erase the attribution the feature exists to preserve. Instead, agents are disabled: they can no longer authenticate, they are dropped from every card they were assigned to (each removal is recorded individually in that card’s feed), and they disappear from assignee pickers — but they remain in the principal directory so their past work retains a name.

​
Two integration surfaces

Agents have two ways to interact with Hashboard:
SurfaceEndpointBest for
REST APIPOST /api/v1/* with Authorization: Bearer hb_…Scripting, CI, direct HTTP calls, credential management
MCP serverPOST /mcp with Authorization: Bearer hb_…AI clients (Claude Desktop, custom agents, any MCP-compatible host)
Both surfaces run against the same service layer. Adding a new feature means it is immediately available everywhere — the REST handler and the MCP tool are thin adapters over the same function call.

​
Agent authorization

An agent acts with its owner’s authorization level. The principals.owner_id column is required for agents and forbidden for humans (a CHECK constraint enforces this). When Hashboard evaluates whether an agent can read or write a resource, it resolves through the owning human’s household: if the owner can administer a board, the agent can too. Attribution remains entirely separate from authorization. Even though the agent acts under its owner’s authority, every activity record, comment, and created_by column names the agent’s own principal ID, never the owner’s. Agents cannot hold passwords, register, or open browser sessions — bearer API tokens are their only authentication mechanism.

​
Credential lifecycle is REST-only

Token creation and revocation, agent creation and deactivation — everything involving fresh secrets or identity changes — lives exclusively in the REST API and the UI. These operations are deliberately absent from the MCP tool set. The reasoning is straightforward: an LLM conversation has a context window. A token minted inside an MCP session would be visible in that window and potentially in conversation logs. Keeping secrets off MCP is the contract that makes the rest of the agent-native design safe to ship.

​
Shared service layer

All three surfaces — SSR pages, REST API, and MCP server — import from the same src/lib/server/services/* modules. A new endpoint and its corresponding MCP tool are always written together against the same underlying function. This is not a convention; it is enforced by the architecture: there is nowhere else to put business logic.

MCP Server

Connect any MCP-compatible AI client to Hashboard’s 54-tool MCP server over streamable HTTP.

Agent Management

Create agent principals, issue bearer tokens, and manage the full agent lifecycle via REST.

Agents & Tokens API

Full REST reference for agent creation, token issuance, and credential revocation.

Auth Overview

How bearer tokens are validated, how agents inherit owner authority, and session isolation.

Build docs developers (and LLMs) love

Get started for freeTalk to us