Skip to main content
Glama

index

Destructive

Prepare .fig files and build local searchable workspaces for coding agents, with source management, refresh, change tracking, semantic embeddings, and visual rendering.

Instructions

Local workspace indexes for search: prepare registers a .fig (file) in its own workspace, or in a project workspace (workspace: a project directory), and with scope starts a background build of exactly that stored scope; status reports sources, indexed scopes and storage; add, remove and relocate change the registered sources (remove withdraws their indexes; add of a directory registers up to 10 .fig files under it in one step, in path order, never through a link leading out of it, and replies directory {added, existing, skipped, notFig, truncated, nextCursor}; pass nextCursor as cursor to add the next 10; a repeat adds nothing, and a moved file is a new source unless relocated); refresh rebuilds changed scopes and rebuild every indexed scope even when unchanged (sourceId and scope narrow both), while the previous index keeps serving; track starts recording one scope's changes, read with the changes tool, with a baseline build, and untrack stops it, keeping its history; embed runs the configured local model (models tool) over published scopes for semantic search, as jobs beside the text builds (mode_unavailable without a profile), and a text build this server runs queues it after publishing; visual (scope required, never widened to the whole file) renders that published scope's screens and components, and the scope node below a page, for image search, and embeds them when a vision profile is configured (hash-only otherwise), as a job on the model lane beside text builds; called again it resumes a partial layer, retrying units that failed; a scope that had a visual layer is rendered again after a text build this server runs republishes it, and no other scope is rendered implicitly; a reply that could not admit every job has admission partial and deferred items, each with the nextStep that builds it later; clear_cache deletes only what a build can recreate; reset deletes this workspace's database after the user confirmed it, keeping every .fig and export. Builds run as jobs: the reply has job {jobId, state}; poll the jobs tool, cancel there. Nothing is built implicitly: connecting, listing, find, inspect and file search create no database. Errors carry _meta.figlens.recovery with only the actions that apply; recreate_elsewhere and reset need the user's confirmation.

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": {
      "action": "<action>"
    },
    "name": "index"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileNoa local .fig: the source to prepare, add or relocate to (add also takes a directory under the roots, or without --root a gs://bucket/object, downloaded pinned to its generation); also selects its source-scoped workspace
scopeNostored node id to index (prepare), refresh, rebuild, track, untrack, embed or visual (required); 0:0 is the whole file
actionYesprepare, status, add, remove, relocate, refresh, rebuild, track, untrack, embed, visual, clear_cache or reset
cursorNoadd of a directory only: directory.nextCursor of the previous add of it; a cursor of another directory is cursor_stale
storageNoabsolute custom storage directory, only for a workspace kept outside the default storage; must be under the server's --storage-root
sourceIdNoa registered source, for remove, relocate, refresh, rebuild, track, untrack, embed and visual
requestIdNoan idempotency key: repeating a prepare, refresh, rebuild, track, embed or visual of one source and scope with it returns the same job; one first used for another request (track is its own) is refused
workspaceNoa project directory: selects or prepares that project's workspace
workspaceIdNows_... from a previous index reply
replaceUnavailableNoprepare only, after the user confirmed: recreate a workspace whose storage is unavailable, denied or unreadable in storage, knowing only file; the old files stay untouched

Output Schema

NameRequiredDescriptionDefault
jobNothe build prepare started or joined: jobId, state, stage, progress
jobsNorefresh, rebuild, track, embed and visual: one job per admitted source and scope, each with joined
pathsNoworkspace, database and lock paths (the lock sits beside the workspace directory); null when the workspace does not exist
stateYesinitialized, ready, absent or reset
partialNoclear_cache: true when a source left this caller's view meanwhile and kept its data; retry later
sourcesNovisible sources: sourceId, path, present and indexed scopes with snapshotId, records, complete and current; a gs:// source adds remote {uri, generation its download was pinned to}, not proof the object is unchanged
storageNo
coverageNoprepare without scope: text and relations not_requested
deferredNopartial admission: sourceId, scope and the nextStep index call that builds it later
admissionNorefresh and rebuild: complete, or partial when some jobs were not admitted
directoryNoadd of a directory: path, added and existing [{sourceId, path}], skipped [{path relative to it, reason escaping_link, linked_directory, unreadable, inside_storage or outside_roots}], notFig count, truncated null or {reason source_cap or entry_budget, limit}, nextCursor for the next 10 or null
nextStepsNo
incarnationNochanges when the database is recreated; cached results of another incarnation are void
workspaceIdYes
schemaVersionNo
deferredBecauseNopartial admission: the error that stopped admission, {code, message}

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.3

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations (which only say non-readonly, destructive, non-idempotent) by naming exactly what destruction means: clear_cache 'deletes only what a build can recreate', reset deletes the database only after explicit user confirmation while keeping every .fig and export. It also discloses the async job model (reply has job {jobId, state}), the availability of the previous index during rebuild, admission-partial/deferred replies, idempotency semantics, and the _meta.figlens.recovery error payload.

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

Conciseness3/5

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

Almost every clause carries real information, so it is dense rather than padded, but it is delivered as one monolithic sentence chain with no grouping, repetition of the job/lane concept ('as jobs beside the text builds' vs 'as a job on the model lane beside text builds'), and no front-loaded summary of the action set. For a 13-action tool a structured action list would be far more scannable.

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?

Given 10 parameters, 13 actions, an output schema and destructive annotations, the description covers the gaps that matter: the job polling contract, what is never built implicitly, what each destructive action removes, profile prerequisites for embed/visual, and the recovery payload. An agent has enough to pick an action and predict its side effects without trial and error.

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 coverage is 100%, so the baseline is 3. The description adds a little beyond the schema (add of a directory admits at most 10 .fig files, stops at links leaving the directory, is idempotent on repeat, and a moved file becomes a new source unless relocated), but most parameter meaning (cursor, requestId, replaceUnavailable, storage, workspaceId) is already spelled out in the schema and largely restated.

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

Purpose4/5

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

The opening clause states a specific resource and domain ('Local workspace indexes for search') and each of the 13 actions gets a verb-level gloss (prepare registers, status reports, add/remove/relocate change sources, refresh/rebuild rebuild). It also implicitly separates itself from siblings ('connecting, listing, find, inspect and file search create no database'), but it never states positively what distinguishes index from search/find/tree beyond the no-implicit-build rule.

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

Usage Guidelines4/5

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

Guidance is given per action and conditionally: refresh rebuilds changed scopes, rebuild rebuilds even unchanged ones, visual requires a scope and is 'never widened to the whole file', embed needs a configured profile else mode_unavailable. It also routes to sibling tools ('poll the jobs tool', 'read with the changes tool', 'models tool'). What is missing is any when-not-to-use framing or a decision rule for choosing among prepare/add/relocate when a file is new.

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