figjam-context-mcp
The figjam-context-mcp server transforms FigJam/Figma boards into queryable, LLM-ready context by reading board content directly via the Figma REST API — no manual export needed. It exposes three tools:
ingest_board: Fetches a FigJam/Figma file, spatially clusters its content (stickies, shapes, screenshots, etc.) using geometry and a vision model, labels each cluster, and caches the result under aboardId. An optionaldocStructureHintcan guide how the board's structure is interpreted.get_board_context: Returns a compact, token-efficient context block plus the underlying labeled clusters for a previously ingested board. Supports optional topic scoping to filter the most relevant clusters — ideal for pasting into documentation or chat sessions.answer_from_board: Accepts a free-form natural language question about an ingested board and returns a direct answer, citing the specific clusters it was derived from.
Provides tools to ingest FigJam boards, retrieve context summaries and clusters, and answer questions about board content.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@figjam-context-mcpWhat are the main action items from the FigJam board?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
figjam-context-mcp

Illustrative overview of the ingest pipeline — not a screen recording.
MCP server that turns a FigJam board into queryable context for LLMs — read directly via the Figma REST API, no manual PDF-export detour. It exposes five tools over a local stdio connection (Node.js 22.12+):
ingest_board — reads a FigJam/Figma file, clusters its content spatially, verifies and labels each cluster with a vision model, extracts connector arrows as cluster-to-cluster relations, and caches the result under a
boardId(= the Figma file key).get_board_context — returns a compact, paste-ready context block (clusters + connector relations) for an ingested board, optionally scoped to a topic.
answer_from_board — answers a free-form question about an ingested board, citing the clusters the answer was derived from.
diff_board — compares two ingest snapshots of the same board and reports what changed: new/removed/modified clusters, edited nodes, and connector changes ("what came in since the last workshop?").
diagnose_llm_config — runs small text + vision JSON checks against the active model setup and reports actionable failures.
Ingested boards survive server restarts: get_board_context and
answer_from_board transparently restore the last finished ingest from
the private per-user cache when the in-memory store is empty. See
cache and migration for locations and upgrade behavior.
Re-ingests are incremental: every cluster's member content is hashed, and
successful interpretations are reused when their content and configuration
still match. New or edited clusters and eligible unfinished vision work are
processed within the remaining budget. Model, provider and prompt changes
automatically invalidate derived results; they do not require a forced ingest.
Figma is still checked for changes. Use forceFullIngest: true only for a
deliberate complete rebuild: it skips successful cached interpretations too.
How it works
FigJam boards are spatially chaotic: rotated stickies, overlapping shapes, embedded screenshots, no reading order. The pipeline therefore combines geometry with vision:
fetchFileTree+flattenNodeTree— pull the raw node tree and flatten it into normalized nodes (position, size, rotation, text, image refs, connector endpoints), dropping empty structural noise.geometricPreCluster— rotation-aware distance clustering into coarse groups. Neighbor search runs over a spatial grid (near-linear instead of O(n²)), and the gap threshold adapts to the board's density (median nearest-neighbor gap) so dense and airy boards both cluster sensibly. Huge footprints use a bounded overflow path, and connected components over 250 nodes are spatially bisected before reaching an LLM.extractConnectorEdges+buildClusterRelations— connector arrows are excluded from geometric clustering (they deliberately span groups) but captured as a graph: "cluster A → cluster B (label)". These relations are included inget_board_contextoutput and theanswer_from_boardprompt — arrows are the board's semantic structure.refineClusterWithVision— per cluster, node screenshots + extracted text go to a vision model in one request; it confirms which nodes belong together, labels the group, describes embedded images, and writes a 3–5 sentence summary. Clusters are refined concurrently (INGEST_BOARD_VISION_CONCURRENCY, default 3) within the vision budget.mapClustersToPhases(optional) — assigns each cluster to a phase of the chosen framework:double_diamond,lean_canvas,retro,user_journey, or a free-formcustomPhaseslist (or "unclear").Results are cached in-memory AND persisted per file key;
get_board_contextandanswer_from_boardread from the cache and restore from disk after a restart.
Related MCP server: Miro MCP Server
Setup
Requires Node.js 22.12+; CI is configured for Node 22 and 24 LTS.
Install a release candidate for normal use
Install the approved local tarball into a dedicated runtime directory. This does not require TypeScript, a source checkout or development dependencies:
mkdir figjam-runtime
cd figjam-runtime
npm init -y
npm install --omit=dev /absolute/path/to/figjam-context-mcp-0.4.0.tgz
cp node_modules/figjam-context-mcp/.env.example .env
node node_modules/figjam-context-mcp/dist/index.js --versionConfigure the keys below, then point your MCP client at the absolute installed
entry point: /absolute/path/to/figjam-runtime/node_modules/figjam-context-mcp/dist/index.js.
Set its working directory to figjam-runtime when using that .env, or supply
the keys in the MCP client's environment. The candidate is local and unpublished;
installing figjam-context-mcp@0.4.0 from npm is only possible after publication.
Build from source
For development and the Inspector configuration in this repository:
git clone https://github.com/ecestnrkl/figjam-mcp.git
cd figjam-mcp
npm ci
cp .env.example .env
npm run buildOn Windows PowerShell use Copy-Item .env.example .env. Run commands from the
repository directory when relying on .env, or pass environment variables from
your MCP client's settings. This checkout prepares version 0.4.0; a checked-in
version or registry metadata file does not mean it has been published to npm.
Fill in .env:
FIGMA_ACCESS_TOKEN — log in at figma.com, go
to Settings → Security → Personal access tokens, generate a token with
file_content:read and access to the board. Scopes do not override file
permissions (Figma scope documentation).
Keep it in the environment. The optional figmaAccessToken tool input remains
compatible, but client tool-call logs can expose argument values.
LLM_BASE_URL / LLM_API_KEY / LLM_MODEL_PRESET — any
OpenAI-compatible endpoint. The bundled preset targets OpenRouter. Provider options:
OpenRouter (default in
.env.example): get a key at openrouter.ai/keys. The defaultstudent-freepreset uses explicit free models for each role:google/gemma-4-26b-a4b-it:freefor vision andqwen/qwen3-next-80b-a3b-instruct:freeplusnvidia/nemotron-nano-9b-v2:freefor text/Q&A.openrouter/freeremains a last-resort fallback, not the primary model.GitHub Models: free with any GitHub account — create a token at github.com/marketplace/models, set
LLM_BASE_URL=https://models.github.ai/inference.
Optional overrides:
LLM_MODEL_PRESET— currently supported:student-free.LLM_VISION_MODELS— comma-separated vision model candidates.LLM_TEXT_MODELS— comma-separated text/Q&A candidates.LLM_FAST_TEXT_MODELS— comma-separated small/fast text candidates.Legacy
LLM_VISION_MODEL/LLM_TEXT_MODELstill work as first-candidate overrides.
Model availability, free quotas and pricing can change. Override the role model
lists for your provider and run diagnose_llm_config to verify JSON and vision
support. The student-free preset is a convenience configuration, not a service
availability or zero-cost guarantee. max_speed ingestion and get_board_context
work without an LLM key; answers, diagnostics and vision require one.
If the diagnostic reports LLM_API_KEY is not set, set the model provider's
key in the MCP client's server environment and restart that connection. A Figma
access token does not replace the model provider key. A project .env is only
loaded automatically when the server starts from that directory. Missing model
configuration is detected before vision screenshots are downloaded; original
texts and table cells remain available for local search.
Run
Use the compiled entry point for a normal MCP connection:
node /absolute/path/to/figjam-mcp/dist/index.jsFor clients accepting a standard mcpServers configuration, substitute your
absolute path and configure secrets in the client's protected environment settings:
{
"mcpServers": {
"figjam-context": {
"command": "node",
"args": ["/absolute/path/to/figjam-mcp/dist/index.js"],
"env": {
"FIGMA_ACCESS_TOKEN": "YOUR_FIGMA_TOKEN",
"LLM_BASE_URL": "https://openrouter.ai/api/v1",
"LLM_API_KEY": "YOUR_PROVIDER_KEY"
}
}
}
}On Windows, use an absolute path with forward slashes. If a GUI cannot find Node,
set command to its absolute executable path. This server is local stdio only;
it does not provide a public HTTP URL or hosted authentication service.
For development with automatic restart:
npm run devThis starts the MCP server over stdio using tsx watch. To try the tools
interactively, run from this repository's root after installing dependencies:
npx @modelcontextprotocol/inspector --config inspector.config.jsonThe Inspector v2 config starts the local source with a three-minute request
timeout and loads .env from the project directory. It contains no credentials.
Restart this Inspector connection after source or environment changes.
Note: don't pass plain
npm run devto the Inspector (or any MCP client) — npm prints a lifecycle banner to stdout before the server starts, which corrupts the JSON-RPC stream the client expects there. Either invoketsxdirectly as above, or add--silent:npx @modelcontextprotocol/inspector npm run dev --silent.
MCP UI timeouts
ingest_board can be slow because it calls Figma and a vision LLM for board
clusters. If the MCP UI shows MCP error -32001: Request timed out, a client or
relay deadline expired before it received the final result. The server may still
be working, or the result may already be saved while delivery is delayed.
INGEST_BOARD_VISION_BUDGET_MS limits only the vision phase, not the complete
ingest. Metadata checks, the full file download when needed, grouping and saving
add to its duration; a 60-second client timeout can therefore expire before a
valid ingest finishes. The supplied inspector.config.json sets
requestTimeout: 180000 (milliseconds) for local testing. Inspector v2 defines
this per-server request timeout;
it does not increase the server's vision budget or enable additional models.
If a request has timed out and remains unanswered, disconnect the old connection
before retrying so another ingest does not wait behind unfinished work.
Inspector 2.10.1's web relay also has independent 60-second response watchdogs
that are not controlled by this setting. During a local Safari test, an ingest
saved its result and reported complete, but its final response appeared only
after a later context request. Increasing requestTimeout alone does not resolve
that observed delivery issue. If the web UI stalls after completion, the Inspector
CLI uses the direct stdio path and avoids that browser relay:
npx @modelcontextprotocol/inspector --cli --config inspector.config.json \
--server figjam-local --method tools/call --tool-name ingest_board \
--tool-arg figmaFileUrl=https://www.figma.com/board/YOUR_FILE_KEY \
ingestMode=max_quality forceFullIngest=false --format jsonReplace YOUR_FILE_KEY with your file key. Keep forceFullIngest=false to retain
successful interpretations while retrying unfinished work. A forced full ingest
deliberately skips reuse and does not remove the vision phase's time budget.
See the local delivery investigation
for the observed behavior and limits of the diagnosis.
Restarting the server does not require re-ingestion of a successfully persisted
v4 snapshot. Call get_board_context or answer_from_board with the same
boardId; they load the snapshot from disk. A fresh Inspector session may no
longer display earlier tool results, but that is separate from the server cache.
Keep the same user and FIGJAM_MCP_CACHE_DIR. Re-ingest to refresh board content,
retry incomplete vision, migrate v3, or recover an ingest that was not persisted.
The server now keeps provider calls bounded by default:
FIGMA_REQUEST_TIMEOUT_MS=15000FIGMA_FILE_REQUEST_TIMEOUT_MS=60000LLM_REQUEST_TIMEOUT_MS=20000LLM_RATE_LIMIT_RETRIES=1LLM_ANSWER_MAX_OUTPUT_TOKENS=2048(includes any provider reasoning tokens)LLM_VISION_MAX_OUTPUT_TOKENS=4096LLM_ANSWER_TOP_K=6LLM_ANSWER_PROMPT_MAX_CHARS=24000INGEST_BOARD_VISION_BUDGET_MS=35000INGEST_BOARD_VISION_CONCURRENCY=3FIGMA_SCREENSHOT_DOWNLOAD_CONCURRENCY=3FIGJAM_MCP_MEMORY_CACHE_MAX_BOARDS=10
ingest_board defaults to ingestMode: "balanced": text-rich clusters use
deterministic summaries, while image-heavy or low-text clusters use vision
within the budget. max_speed skips vision; max_quality attempts vision for
every cluster. Finished ingests persist immutable source snapshots separately
from provider-dependent interpretation, with identities covering file content,
model/provider configuration, extraction/prompt version, phase hint and ingest mode.
Vision candidates are prioritized by information gain rather than canvas
position. Each request has bounded node/text inventory, and the phase returns
at its configured deadline even if a provider stalls. answer_from_board
retrieves the most relevant clusters plus direct connector neighbours and keeps
the complete prompt under its configured character budget. The in-memory cache
uses LRU eviction; persisted history keeps 20 states and removes snapshots that
become safely unreferenced. Client cancellation reaches provider calls and ingest
work; clients requesting progress receive phase updates. Network work is bounded
by a 64 MiB file response, 100,000 traversed nodes, 8 MiB per image and 64 MiB
of screenshot downloads per ingest. Oversized files fail with an actionable error.
Run diagnose_llm_config after changing model env vars. It verifies structured
text replies with small arithmetic challenges and checks actual image
understanding with a known color image, without ingesting a board.
Usage example
Paste in a Figma board link and ingest it:
// tool: ingest_board
{
"figmaFileUrl": "https://www.figma.com/board/AbC123XyZ456/Semester-Project-Research",
"docStructureHint": "double_diamond"
}
// → { "boardId": "AbC123XyZ456", "clusterCount": 5, "relationCount": 3,
// "summary": "Ingested board AbC123XyZ456: 5 clusters — \"User interview quotes\", \"Problem framing\", …" }Instead of a built-in framework (double_diamond, lean_canvas, retro,
user_journey) you can pass your own phase names — clusters are then mapped
onto them by keyword match:
{ "figmaFileUrl": "…", "customPhases": ["Ideen", "Feedback", "Offene Fragen"] }The boardId is the file key itself — re-running ingest_board on the same
file refreshes the cache entry. Then pull context, optionally scoped to a
topic:
// tool: get_board_context
{ "boardId": "AbC123XyZ456", "topic": "user research" }
// → contextText:
// FigJam board AbC123XyZ456 — 2 of 5 clusters (topic: user research):
//
// ## User interview quotes [discover]
// Sticky notes with verbatim quotes from six student interviews about exam
// stress. Two embedded screenshots show survey results (bar charts of study
// habits). Main pain points: unclear requirements and late feedback. …
//
// ## Connections between clusters (from connector arrows)
// - "User interview quotes" → "Problem framing" — "informs"The contextText block is deliberately token-lean — paste it straight into
a documentation-writing chat (e.g. for a semester report). Or ask directly:
// tool: answer_from_board
{ "boardId": "AbC123XyZ456", "question": "What were the main user pain points?" }
// → { "answer": "Unclear requirements and late feedback …",
// "citedClusters": ["User interview quotes", "Problem framing"] }After the board evolved (say, workshop 2), ingest again — unchanged clusters are reused, so this is fast — and diff the snapshots:
// tool: diff_board
{ "boardId": "AbC123XyZ456" }
// → summaryText:
// FigJam board AbC123XyZ456 — changes from 2026-07-03T14:02:11Z to 2026-07-10T09:41:52Z:
//
// New clusters (1):
// - "Feedback round 2": Sticky notes with feedback from the second usability test.
// Modified clusters (1):
// - "User interview quotes": +3 nodes, 1 edited
// Connections: +1 / -0
// - new: "Feedback round 2" → "Problem framing" — "confirms"
// Nodes: +9 added / -0 removed / 1 edited.
// Unchanged clusters: 4.compareTo selects an older baseline (2 = two ingests back, …); the history
keeps the last 20 distinct board states per file.
Bounded context and source citations
get_board_context adds snapshotId, evidence, connections, totalMatched,
truncated, explicit truncation counts and optional nextCursor. The existing contextText, clusters and
relations remain available. Use limit (default 20, maximum 100) and maxChars
(default 12,000, maximum 24,000) to control a page. To continue, send nextCursor
back as cursor with the same query and budgets. Cursors bind the snapshot so a
later ingest cannot silently change the next page. Exact nodeIds lookups can
retrieve original text/table cells (up to 50 IDs); topic and nodeIds are mutually exclusive.
The complete readable and structured result is limited to 128 KiB. A page never
silently skips a partially returned source chunk; increase maxChars if one
chunk cannot fit. Cursors also reject changed interpretation results.
Without search parameters the tool returns a bounded overview across clusters. Topic search uses Unicode-aware local BM25 over original text, table cells and descriptive names, supplemented by direct graph neighbors and up to six related table-cell excerpts. Cells in the matching row take priority when row positions are available; missing positions are never inferred. Names and available table positions remain visible in the source metadata. A topic with no matches now returns empty results, instead of falling back to the entire board.
Structured cluster summaries carry summarySource and modelDerived alongside
the original evidence. They are derived context, not verbatim quotations;
unknown or cache-only origins are conservatively marked as potentially model
derived. sourceNodeIds identifies the source nodes displayed on that page and
does not validate every claim in the cluster summary.
// tool: get_board_context
{ "boardId": "AbC123XyZ456", "topic": "research", "limit": 10, "maxChars": 6000 }
// Next page: same arguments, plus "cursor": "<nextCursor from previous result>".answer_from_board retains answer and citedClusters and adds snapshotId
and citations containing source node IDs, exact evidence quotes and Figma links.
Original board text/table cells are distinguished from model interpretations.
Answers are instructed to distinguish explicit status statements from open tasks
and proposals. For example, “clarify room availability” does not establish either
“booked” or “not booked”; the booking status remains unconfirmed by that excerpt.
An uncertainty explanation may cite the open task without claiming its outcome.
A quote matching a source does not guarantee the model's inference is correct;
use the source links to verify important conclusions. The tool reports insufficient
evidence when it cannot return a supported answer.
Cache and migration
Version 0.4.0 uses cache format v4, stored beneath a private per-user root:
Platform | Default root |
macOS |
|
Windows |
|
Linux |
|
Set FIGJAM_MCP_CACHE_DIR to use another dedicated private directory. Current
files live in its v4/ subdirectory. The cache contains board text, node metadata,
interpretations and retained snapshots. Unix files/directories use owner-only
permissions; Windows relies on the user's profile/directory access controls.
The server/client must be trusted to access this user's cache.
Legacy v3 files in .cache/figjam-mcp/ are preserved. They cannot supply the
complete provenance required by v4: run ingest_board again after upgrading.
No silent destructive conversion runs. To remove retained data, stop the server
and delete its dedicated cache root; cached context and history then disappear.
When using a custom location, remove only the directory you configured for this
server. Clearing the cache does not remove provider-side request logs.
If a writer crashes and leaves v4/.write-lock, future writes fail closed rather
than stealing the lock. Stop all instances of this server using that cache,
then remove only v4/.write-lock and restart. Never remove the lock while a
writer may still be running. Existing committed snapshots remain readable.
Source snapshot IDs depend on captured board content, not the model. Refinements
use separate immutable revisions, committed together with history through an
atomic manifest replacement. A model change does not create a board-content diff.
Failed vision work remains marked incomplete and is retried on a later ingest;
successful refinements are reused. Provider Retry-After delays are respected.
Ingest results include the actual ingestMode and qualityReport.fallbackReasons.
These distinguish unstarted work deferred by the time budget from rendering,
model, configuration, authorization, rate-limit, response-format, timeout and
download-budget failures. Older generic cache reasons remain explicitly unknown.
qualityReport.nextRetryAt records the earliest pending cooldown when present.
Fix missing credentials or authorization before retrying; increasing the time
budget cannot repair these failures. Work deferred by the time budget is given
priority over repeatedly failing clusters on the next ingest. Switching to
max_speed intentionally uses text without inheriting a failed vision status.
Repeated ingestion first checks Figma's metadata version when possible. Tokens
without metadata access fall back to a complete file read; other metadata errors
do not claim that the cached board is current. forceFullIngest bypasses both
metadata reuse and refinement reuse. Downloads are bounded to 64 MiB per file
tree, 8 MiB per image and 64 MiB of image downloads per ingest. Extraction allows
100,000 nodes and 1,024 nesting levels; dense geometry and metadata have additional
work limits with actionable errors. Cancellation stops later phases and network
work before publication; completed source publication is the operation's commit point.
Data handling
The server reads Figma and never changes the board. Balanced/quality ingestion
can send board text and screenshots to the configured LLM provider; Q&A sends
selected evidence and your question. Synthetic diagnostic requests also use the
provider. Costs, model availability and retention are controlled by that provider.
For local deterministic retrieval, use ingestMode: "max_speed" followed by
get_board_context. Review sensitive content before enabling external model calls.
Tokens belong in environment settings, never in issue reports or committed files.
License and maintenance
MIT, copyright 2026 ecestnrkl. See CONTRIBUTING.md, SECURITY.md and CHANGELOG.md. Dependency updates are proposed weekly for review. CI is configured to verify the package on Node 22/24 across Linux, macOS and Windows. The manual Release candidate workflow produces an artifact; a maintainer approves publication separately.
glama.json identifies the maintainer, and server.json prepares MCP Registry
metadata for all five capabilities. Neither file publishes the project. After a
real release, refresh the Glama inspection so its tool schema matches the current
version. Maintenance ratings depend on actual maintenance activity over time.
Scripts
npm run dev— run the server withtsx watch(auto-restart on change).npm run build— clean and compile TypeScript todist/, preserving an executable CLI.npm start— run the compiled server fromdist/.npm test— run the Vitest test suite.npm run typecheck— type-check both source and tests without emitting files.npm run check— type-check, test, build, and validate the package metadata/binary.npm run package:smoke— install the tarball with production dependencies only and exercise its CLI, five MCP tools, context/diff results and errors.npm run package:smoke -- --long— additionally wait through a synthetic 65-second ingest in the installed server and verify that its final response and saved sources arrive after completion progress. No real Figma or model requests are made by these fixtures.npm run security:check— audit runtime and development dependencies.npm run eval:retrieval— evaluate the 20 synthetic source/change fixtures locally; no provider calls.npm run eval:retrieval -- --with-llm— explicitly opt into model evaluation using the configured provider, with measured requests, reported token usage and source checks. Includes separate status-question cases for human review. May incur charges.npm run eval:retrieval -- --with-llm --grounding-only— call the provider only for the five status-question cases, each with a 45-second deadline; keep the retrieval/change checks offline. ProvideLLM_BASE_URLandLLM_API_KEYin the environment; source users can preload their project.envwithnode --import dotenv/config --import tsx scripts/evaluate-retrieval.mjs --with-llm --grounding-only.
Publishing runs the same checks automatically through prepack; CI is configured to exercise
that complete package path on Node 22 and 24 across Linux, macOS and Windows.
The synthetic evaluator reports lexical retrieval and source traceability, not
general reasoning quality or real-world workshop accuracy. Its historical
summary-visibility comparison is a proxy, not a measured run of the old release.
Missing provider usage and monetary cost are reported as unmeasured.
The status-question cases distinguish unknown, confirmed, explicitly negative,
proposed and conflicting statuses. Their generated answers require human review;
the evaluator does not award a semantic pass based on a citation ID or a mocked
provider response. Offline runs do not measure model compliance with these rules.
Project layout
src/
├── index.ts # stdio entrypoint
├── server.ts # McpServer setup + tool registration
├── tools/ # tool handlers (ingest pipeline, context, Q&A)
├── schemas/ # Zod input/output schemas per tool
├── lib/ # Figma API, node tree, clustering, vision, LLM, cache
└── types.ts # shared domain typesAvailable Tools
3 toolsanswer_from_boardAnswer From BoardA
Answers a free-form question about a previously ingested board, citing the clusters the answer was derived from.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | ||
| question | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| answer | Yes | |
| citedClusters | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool cites clusters and requires a previously ingested board, but does not cover permissions, rate limits, or mutability.
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 concise sentence with no wasted words. However, it could be slightly more structured by including usage hints.
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 only 2 parameters and an output schema (not shown), the description covers the basic purpose, but lacks details on how citations are delivered or any edge cases. It is adequate but not comprehensive.
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 coverage is 0%, so the description should add meaning beyond parameter names. It only says the tool answers a question about a board, but does not clarify that boardId refers to a valid board from a prior ingest or that question is free-form text. The names are self-explanatory but the description adds minimal value.
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 answers a free-form question about a previously ingested board and cites clusters, distinguishing it from siblings like get_board_context (which likely provides raw context) and ingest_board (which is for ingestion).
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 implies the board must be previously ingested, but does not explicitly state when to use this tool vs alternatives, nor does it provide exclusions or prerequisites beyond 'previously ingested'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_board_contextGet Board ContextA
Returns a text summary plus the underlying clusters for a previously ingested board, optionally scoped to a topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional topic to focus the context on | |
| boardId | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| clusters | Yes | |
| contextText | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It discloses that the operation returns text and clusters and requires a previously ingested board, but omits details on error handling, rate limits, or required permissions. It is adequate but not comprehensive.
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, well-structured sentence that places the key action and outputs first. Every word adds value, and there is no superfluous information.
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's simplicity (2 parameters, no annotations), the description is sufficiently complete. It explains the return type (text summary + clusters) and the optional scoping. The presence of an output schema further reduces the need for detail in the description.
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 coverage is 50% (only topic has a description). The description adds the phrase 'optionally scoped to a topic,' which clarifies the topic parameter's purpose. However, boardId lacks any description beyond being required, so the additional value is limited.
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 returns a text summary and clusters for a previously ingested board, with optional topic scoping. It effectively distinguishes from sibling tools like answer_from_board and ingest_board by specifying the output type and prerequisite.
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 implies the tool should be used after a board has been ingested, but it does not explicitly state when to use this versus alternatives like answer_from_board. No direct guidance on prerequisites or context for selection is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ingest_boardIngest FigJam BoardA
Reads a FigJam/Figma file, clusters its content, and caches it under a boardId for later get_board_context / answer_from_board calls.
| Name | Required | Description | Default |
|---|---|---|---|
| figmaFileUrl | Yes | URL of the FigJam/Figma file to ingest | |
| docStructureHint | No | How to interpret the board's structure when mapping clusters to phases | freeform |
| figmaAccessToken | No | Figma personal access token; falls back to FIGMA_ACCESS_TOKEN env var if omitted |
Output Schema
| Name | Required | Description |
|---|---|---|
| boardId | Yes | |
| summary | Yes | |
| clusterCount | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains that the tool reads, clusters, and caches data, but lacks details on side effects (e.g., is caching persistent? can it be redone?), authorization beyond token handling, or potential performance implications.
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, moderately long sentence that efficiently conveys the core functionality. It avoids unnecessary words but could be slightly more structured (e.g., separate sentences for purpose vs. usage linkage).
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 presence of an output schema (not shown but declared), the description does not need to detail return values. It covers the essential steps (read, cluster, cache) and links to sibling tools. Some missing detail on clustering meaning, but overall sufficient.
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 itself provides full parameter descriptions (100% coverage). The tool description adds context about clustering and caching but does not enhance the meaning of individual parameters beyond what the schema already offers.
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 uses specific verbs ('reads', 'clusters', 'caches') and clearly identifies the resource ('FigJam/Figma file'). It explicitly distinguishes from sibling tools by stating that the output is used for later 'get_board_context' and 'answer_from_board' calls.
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 clearly indicates when to use this tool (as a prerequisite for the two sibling tools), providing clear context. However, it does not explicitly state when not to use it or mention alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
answer_from_board - First observed
get_board_context - First observed
ingest_board
TDQS
Scored across 3 tools
Each tool has a distinct and non-overlapping purpose: ingest_board adds a board, get_board_context retrieves its context, and answer_from_board answers questions. No ambiguity in intent.
All tool names follow a consistent verb_noun pattern with snake_case: 'ingest_board', 'get_board_context', 'answer_from_board'. The naming pattern is uniform and predictable.
With only 3 tools, the server is tightly scoped to a specific workflow (ingest, context, answer). Each tool serves a necessary step without unnecessary bloat.
The server covers the core workflow of ingesting a board, retrieving context, and answering questions. A minor gap is the lack of a tool to list or delete ingested boards, but this may be out of scope.
Maintenance
Related MCP Connectors
Access Pollinations models and API capabilities through agent tools.
Bounded tools for rendering, extraction, RAG, enrichment, local discovery and review analysis.
Astra DB tools for agents: schema, find, vector search, guarded writes, and interactive views.
Enterprise memory, search, and context for frontier AI. 38 tools for business intelligence.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables MCP-compatible LLMs to interact with Miro whiteboards to manage boards, create and manipulate shapes, and organize content through grouping tools.-
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to programmatically interact with a Miro board through the Miro API, supporting operations like creating items, updating positions, and managing connectors.16-
- FlicenseBqualityDmaintenanceEnables AI agents to read, inspect, and export Figma designs programmatically. Provides tools for listing components, styles, and exporting assets in various formats.51-
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to visualize tasks on a collaborative Sketchbord whiteboard by composing content into diagrams, editing them incrementally, and reading back the board including user-drawn additions.MIT