The server is a read-only MCP interface to a local vault of normalized Figma designs, letting agents inspect designs offline without Figma tokens or rate limits.
List designs: vault_list returns all exported documents with metadata (docId, names, export time, node count).
Read whole design: vault_get_doc returns the normalized node tree with optional depth limiting and hidden-node inclusion; tokens are included.
Read a subtree: vault_get_node fetches a specific node and its descendants, useful for targeted inspection.
Search the design: vault_search finds nodes by name or text content, with case-insensitive substring matching and result limits.
Get design tokens: vault_get_tokens returns colors, text styles, and effects referenced by nodes.
Fetch assets: vault_get_asset retrieves images (raster or SVG source) and the frame screenshot by path.
Pulls Figma designs into a local vault and provides read-only MCP tools for accessing the normalized node tree, assets, icons, tokens, and design metadata without further Figma API calls.
English · Русский
Pull a Figma frame once. Then Claude Code, Codex or any MCP agent reads it as often as it likes: offline, with no Figma token and no rate limits.
3 Figma requests per screen, spent once when you pull it. After that it's zero, however many times the agent looks.
Icons cost nothing. A real screen had 141 icons, and they took no extra requests.
Commit the vault and the team needs no Figma access. No licence, no token.
Try it in 30 seconds. You don't need a Figma token for this:
npm i -g figma-vault
figma-vault init && figma-vault demo && figma-vault checkHow it works: the pull normalizes the frame and writes it to disk. The agent then reads it over MCP.
one developer: figma-vault add <link> → vault → git commit
the rest of the team: the agent reads it over MCP, no Figma token neededFigma's MCP server and REST API are rate-limited, and on some seats the limit is tiny. While building a UI, an agent goes back to the design all the time to check a margin, a colour or a font size. That can mean dozens of calls in one session. You hit the limit fast and the work stops.
With figma-vault, the number of Figma calls doesn't depend on what the agent does. Each design costs a fixed number of calls, spent once when you pull it.
Figma Dev Mode MCP | figma-vault | |
who calls Figma | the agent, while it works | the CLI, once |
how many calls | grows with the agent's work | fixed per design |
does every reader need a token | yes | no |
works offline | no | yes |
There's a side effect: the design becomes a file in your repository. A developer without access to the Figma file (no licence, no permissions, no token) still gets the whole design.
Other projects work on the same problem. The Framelink Exporter plugin exports a design to a zip for offline use, and there are caching forks of Framelink's Figma MCP. figma-vault takes a different approach:
The vault is meant to be committed. One person pulls a design and the whole team reads it from git. Nobody else needs Figma access.
Icons cost zero requests. Vector paths come with the node tree, and the SVGs are built locally. Rendering them through Figma would eat the image-render limit.
The format is fixed and validated. doc.json follows a written contract,
and a strict validator checks every file.
Related MCP server: ai-ready-ds-auditor
Requires Node.js 22+.
npm i -g figma-vaultfigma-vault initThis creates .figma-vault/, registers the server in the project's .mcp.json (other
entries are left alone), adds .env to .gitignore and installs a /figma slash command
for Claude Code.
Use --no-command to skip the /figma command, so the agent gets only the read-only
vault_* tools.
figma-vault init --globalThe vault lives in ~/.figma-vault/ and the server is registered in the agent's user
config. The project repository never learns the tool exists. Use this when you can't add
config or dependencies to the project.
figma-vault add "https://figma.com/design/KEY/Project?node-id=127-4532"To get the link, right-click a frame in Figma and choose Copy link to selection.
figma-vault limits "<link>" # check your Figma rate limits BEFORE pulling
figma-vault list # what has been pulled so far
figma-vault check # verify the whole chain works
figma-vault demo # add a demo design, no token neededCLI output, errors and the MCP tool descriptions are in English by default; the /figma
command it installs is in English too. README.ru.md is a translation of
the documentation only.
After init, Claude Code has one command:
/figma <frame link>It pulls the design, reads it over MCP and builds the UI following the project's conventions.
REST API limits depend on the token, the plan and the seat type, and you can't look them
up in advance. Run figma-vault limits "<link>" before your first pull. It makes the same
two requests a pull would and tells you whether the pull will go through.
A full pull of one screen costs three requests. We measured this on a real design with 332 nodes:
requests | |
node tree ( | 1 |
frame screenshot ( | 1 |
raster images ( | 1 per 40 images |
icons and vectors | 0 |
On that design, the 141 icons cost zero requests. So the cost of a pull doesn't depend on how many icons the design has. After the pull, the agent never calls Figma again.
figma-vault verify compares the page the agent built with the design. The package ships
no browser: the snapshot is taken with whatever the project already uses (Playwright,
DevTools, the agent's browser tool).
Mark the root element of the page with data-figma-node-id="<root node id>", and the
main blocks with the ids of their nodes.
figma-vault verify <docId> --snippet prints a script. Run it on the page and save
what it returns to a file.
figma-vault verify <docId> --snapshot <file> checks it:
texts: every visible text of the design must be on the page;
geometry: each marked block must match the design's position and size, within
2 px by default (--tolerance).
The result is PASS (exit code 0), FAIL (1, with a list of what is off) or
INCOMPLETE (2, when nothing is marked and geometry can't be checked). The /figma
command runs this step itself when the project has a browser.
You only need a token to pull new designs. Reading works without one, which is the normal setup for everyone except the person who pulls. So you can test the whole install without creating a token:
figma-vault init && figma-vault demo && figma-vault checkcheck starts the real MCP server as a child process and talks to it over the protocol.
It exits with code 1 when something is actually broken, so you can use it in CI.
In Figma, go to Settings → Security → Personal access tokens → Generate new token. The token needs only one scope: File content → Read-only.
Put it in a .env file in the directory you run the CLI from, as a line
FIGMA_TOKEN=figd_..., or set it as an environment variable. If both are set,
the environment variable wins.
The MCP server exposes six read-only tools:
tool | returns |
| the designs in the vault |
| a design's node tree; |
| the subtree of one node |
| nodes found by name or text |
| colours, typography, effects |
| an image or an icon |
The tree is normalized:
auto-layout becomes mode: row|column with gap and padding;
coordinates are relative to the parent;
styles, gradients and text come in one predictable shape, including differently
coloured fragments inside one text (text.runs);
nodes hidden in Figma are kept with hidden: true. By default the agent doesn't get
them, but a parent reports how many it has (hiddenOmitted). Pass includeHidden: true
when building a reusable component whose optional slots are switched off on this screen.
The raw Figma response is saved next to it in raw.json for debugging.
On a real design, normalization shrinks the tree about 7 times:
raw.json 1.9 MB raw Figma response
doc.json 256 KB what the agent readsThis saves more than disk space. An agent that reads 256 KB instead of 2 MB rebuilds the UI noticeably more accurately.
<vault>/
index.json list of designs
<docId>/
doc.json normalized tree, the main artifact
raw.json raw Figma response
screenshot.png render of the whole frame
assets/ icons and imagesThe figma-vault/doc@1 schema is described in docs/CONTRACT.md
(in Russian). A strict validator checks it. Vaults pulled with 0.1.0 (doc@0) are
still read as they are; there is no need to pull them again.
doc.json stands on its own: the MCP server never reads raw.json and never touches
the network.
This is an MVP. Here is what it can't do yet.
Image-render limit. Figma's /v1/images endpoint runs out sooner than tree
reads do, and the block can last for days. Icons no longer depend on it, but the frame
screenshot and raster images still do. The client retries up to three times,
following Retry-After, and never sleeps for more than a minute. If Figma asks it to
wait for days, the pull keeps the node tree, records the reason as a warning and
doesn't fail. Run figma-vault limits before pulling.
Only colour and weight are kept for fragments inside a text. A gradient, a different font or an underline on part of a text is lost.
Designs with many component variants make a large doc.json. Hidden slots are kept
now. On a 332-node screen that added 3,400 hidden nodes, and the file grew from 444 KB
to 5 MB. The agent still gets about 100 KB by default, but the file goes into your git.
The fixture in the repository is synthetic: 29 nodes, enough to install the tool and confirm the chain works without a Figma token.
We checked accuracy separately, on two real designs whose content isn't published here. Results on a product screen with 332 nodes, 15 levels deep:
check | result |
design texts present in the rebuilt markup | 41 of 41 |
icons | 15 of 15, 0 broken links |
placeholders needed | 1 (a raster avatar) |
Figma requests to pull | 3 |
| passes |
Not checked: pixel-perfect match. We compare with Figma's reference render by eye,
using npm run dev → /compare/<name>. figma-vault verify checks texts and the
geometry of marked blocks, but not colours, fonts or pixels.
It isn't a SaaS, a Figma replacement or a real-time sync. There is no auth, billing, teams or users, and no server side. The MCP server runs on the developer's machine as a child process of the agent and talks over stdio. There is nothing to deploy.
docs/INTEGRATION.md: rolling it out to a team, the no-trace mode, checking without a Figma token.
docs/ADAPT.md: adapting the tool to a project's design system.
npm install
npm test # 58 tests
npm run typecheck
npm run dev # local preview of rebuilt markup and comparison with the designTwo AI agents write this project in parallel, following the protocol in AGENTS.md: separate areas of the code, a task board and a shared log. Each commit is tagged with its author.
MIT
An image from the document by the path from node.asset.path (for example assets/logo.svg) or screenshot.png. Raster comes back as an image, svg as its source.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path inside the document directory, for example assets/hero.png | |
| docId | Yes | Document id as returned by vault_list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, and the description adds the useful behavioral distinction that raster files are returned as images while SVG files are returned as source. This goes beyond the annotation coverage without contradicting it.
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 contains no fluff; both sentences carry functional information. The opening is slightly awkward ('An image from the document by the path...') but remains quickly scannable.
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 two required parameters and no output schema, the description provides the key missing context: where paths originate and how the response differs by format. It could specify the exact response encoding or error handling, but for a simple read-only asset lookup the definition is largely 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?
Schema description coverage is 100%, so the baseline is 3, but the description enriches the path parameter by explaining that it comes from node.asset.path and that screenshot.png is a valid special value. This is practical information not present in the schema.
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 identifies the resource as an image asset in a document and indicates a path-based lookup, which separates it from sibling tools that return nodes, documents, tokens, or search results. It lacks an explicit retrieval verb like 'returns' or 'fetches,' but the behavior is clear enough from the examples and the raster/SVG contrast.
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 gives practical guidance on where to obtain the path (node.asset.path or screenshot.png), so an agent can infer the intended use when it needs an asset for a node. It does not explicitly state when not to use it or name alternatives, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalized design tree together with its tokens. maxDepth cuts the tree by depth (0 — the root only); truncated nodes get childrenOmitted. Hidden nodes are not returned without includeHidden.
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | Document id as returned by vault_list | |
| maxDepth | No | How many levels below the root to return. Omit for the whole tree. | |
| includeHidden | No | Also return nodes hidden in Figma (hidden: true) — optional component slots. Defaults to false: building the screen as it looks does not need them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, and the description adds valuable behavioral detail: maxDepth truncates with 'childrenOmitted' and hidden nodes are excluded unless includeHidden is set. This goes beyond the annotation and explains edge cases. No contradiction with readOnlyHint or openWorldHint.
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?
Two sentences with no filler. The core purpose is front-loaded, followed by concise behavior notes on maxDepth and hidden nodes. Every clause contributes meaning.
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 complex tree-returning tool with no output schema, the description gives a high-level view and notes a specific field ('childrenOmitted'), which hints at the return structure. It covers the key behaviors (depth, hidden nodes) but does not detail the full tree/token format. Given readOnlyHint and the sibling tool set, this is reasonably 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?
Schema coverage is 100%, but the description enriches parameter meaning: it explains maxDepth's depth semantics (0 = root only) and the effect on truncated nodes, and clarifies includeHidden's default and purpose. This adds value beyond the schema's field descriptions.
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 retrieves a 'Normalized design tree together with its tokens' – a specific verb and resource. It distinguishes itself from siblings like vault_get_node (single node) and vault_get_tokens (tokens only) by covering the whole tree. The mention of maxDepth and hidden nodes further clarifies scope.
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 when to use it (when you need the whole document tree and its tokens) but does not explicitly contrast with alternatives like vault_get_node or vault_get_tokens. It explains how maxDepth and includeHidden alter the result, giving context, but lacks explicit 'use this when' or 'prefer sibling X for Y' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A node by id with all of its descendants. Use it instead of pulling the whole document.
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | Document id as returned by vault_list | |
| nodeId | Yes | Node id in Figma format, for example 1:42 | |
| includeHidden | No | Also return nodes hidden in Figma (hidden: true) — optional component slots. Defaults to false: building the screen as it looks does not need them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context: it returns descendants, and the includeHidden parameter is explained with a practical default rationale ('building the screen as it looks does not need them'). This goes beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and the second sentence justifies usage. 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?
For a read-only subtree retrieval tool with 100% schema coverage and no output schema, the description is complete enough. It could mention pagination or response shape, but the readOnlyHint and clear parameter docs make it adequate.
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 100%, so the schema already documents all three parameters. The description adds a bit of context for includeHidden, but docId and nodeId are already well described in the schema. Baseline 3 is appropriate.
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 node by id with all descendants, and explicitly contrasts it with pulling the whole document. This distinguishes it from siblings like vault_get_doc and vault_search.
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 says to use it instead of pulling the whole document, which gives clear context for when it is appropriate. It does not explicitly name alternatives or exclusions, but the sibling list and the 'instead of pulling the whole document' guidance are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Colors, text styles and effects of the document. Nodes refer to them via text.token.
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | Document id as returned by vault_list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe read operation. The description adds the useful context that tokens are referenced by nodes via 'text.token', which helps the agent understand the data model. It doesn't describe return format or pagination, but for a read-only token lookup with annotations covering safety, a 3 is appropriate.
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?
Two short sentences with no waste. The first sentence states the resource and contents; the second explains the relationship to nodes, which is valuable context. Front-loaded and efficient.
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 read-only tool with one fully documented parameter and annotations covering safety, the description is nearly complete. It explains what tokens are and how they are referenced, which is enough for an agent to decide to call it. The only minor gap is not describing the return shape, but no output schema exists and the tool is simple enough that this is not critical.
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 100%, so the schema already documents the single docId parameter. The description does not add parameter-level detail beyond the schema, but with full coverage the baseline 3 is correct.
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 resource ('design system tokens') and clarifies what it contains ('colors, text styles and effects'), which distinguishes it from document content or assets. It doesn't explicitly name a sibling it is not, but the resource is specific enough that an agent can tell it apart from vault_get_doc, vault_get_node, and vault_get_asset.
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 usage context by explaining that nodes refer to tokens via 'text.token', which hints that this tool is for resolving token references. However, it does not explicitly state when to use this tool versus alternatives like vault_get_doc or vault_get_asset, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every exported document: docId, file and node name, export time, node count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds meaningful scope ('Every exported document') and the exact returned fields, which goes beyond the annotations. It does not mention ordering or pagination, but for a parameterless list operation the disclosed behavior is reasonably complete.
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 compact sentence that front-loads the scope ('Every exported document') and then lists the returned fields. Every word earns its place, with no filler or repetition.
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 zero-parameter, read-only list tool, the description is largely sufficient: it identifies the full scope and the fields returned. It could be more complete by stating ordering, result count, or list shape, but the annotations and field enumeration cover the main needs.
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 tool has zero parameters, and schema description coverage is effectively complete. There is no parameter semantics to add, so the baseline score of 4 applies.
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 ('List') and resource ('every exported document') and enumerates the returned fields (docId, file and node name, export time, node count), making the tool's purpose clear. However, it does not explicitly differentiate itself from sibling tools like vault_search or vault_get_doc, and the title 'List designs' introduces slight vocabulary ambiguity versus 'exported document'.
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?
No guidance is given for when to choose this tool over alternatives such as vault_search, vault_get_doc, or vault_get_node. The phrase 'Every exported document' implies a list-all role, but there are no explicit usage conditions, exclusions, or routing hints. An agent must infer when to use it from sibling names and the fields listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nodes whose name or text content contains the substring (case-insensitive). Returns id, type and the path from the root.
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | Document id as returned by vault_list | |
| limit | No | Maximum number of hits, 50 by default | |
| query | Yes | Substring to look for in name and text.content | |
| includeHidden | No | Also return nodes hidden in Figma (hidden: true) — optional component slots. Defaults to false: building the screen as it looks does not need them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description adds useful behavioral detail: case-insensitive substring matching, matching against both name and text content, and the returned id/type/path structure. This is valuable because no output schema exists to carry that information.
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, front-loaded sentence that states the matching behavior and the return fields without filler. Every word earns its place, and the tool's core behavior is immediately visible.
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 search tool with no output schema, the description covers the key context: what is searched, what matches, and what is returned. Minor details like result envelope shape or ordering are absent, but the parameters and defaults are already documented in the schema, so the agent has enough to call the tool correctly.
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 100%, so all four parameters are documented in the schema itself. The description adds no extra parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
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?
States a specific verb ('search' implied by name/title) and a precise resource: nodes whose name or text content contains a case-insensitive substring. It also names the return fields (id, type, path), which makes the tool's function unambiguous and distinguishable from sibling get/list tools.
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 when to use it: when you need to find nodes by substring matching. However, it gives no explicit when-not-to-use guidance or alternatives, such as using vault_get_node when an exact node id is already known, so routing decisions are left to inference.
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.
v0.1.0vault_get_assetvault_get_docvault_get_nodevault_get_tokensvault_listvault_searchScored across 6 tools
Each tool targets a distinct operation: listing exports, fetching docs, fetching nodes, fetching tokens, searching, and fetching assets. No two tools overlap in purpose, and the descriptions clearly differentiate them.
All tools follow a consistent 'vault_' prefix followed by a verb and optional noun (list, get_doc, get_node, get_tokens, search, get_asset). Slight deviation from a strict verb_noun pattern (e.g., 'vault_search' vs 'vault_get_*') but overall consistent and predictable.
With 6 tools, the server is well-scoped and focused on the core needs of browsing and retrieving design data. Each tool serves a distinct purpose and none feel redundant or excessive.
The set covers listing, fetching, searching, and asset retrieval, which are essential for design document access. Minor gaps include lacking update/create operations, but since this appears to be a read-only export vault, the surface is largely complete.
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
One shared context your team's AI tools read & write over MCP. No re-explaining. Free.
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
