Skip to main content
Glama
LogicStamp

logicstamp-mcp

Official
by LogicStamp

logicstamp_read_bundle

Reads bundle files to extract component contracts and dependency graphs. Use for project overview or detailed component analysis from context files.

Instructions

⚠️ CRITICAL: Do NOT use sleep() delays before calling this tool. When watch mode is active, bundles are already fresh - call this tool directly without any waiting. Reads bundle/index file to get component contracts and dependency graphs. Reads context_main.json (project overview) or folder context.json (component contracts). These are pre-parsed summaries optimized for AI - PREFER over raw .ts/.tsx files. ROOT vs DEPENDENCY: Root components have their own bundles (use rootComponent param). Dependencies appear in bundle.graph.nodes[] of the root that imports them. If a component isn't found as root, it's a dependency - read bundles that might import it and check bundle.graph.nodes[] for the dependency contract. Bundle contains: entryId, graph.nodes[] (UIFContract for root + dependencies), graph.edges[] (dependencies), meta.missing[] (unresolved). UIFContract: kind, description, props, emits, state, exports, semanticHash, optional style metadata. Watch mode: Use projectPath directly (no snapshotId needed). Use bundlePath="context_main.json" for overview, or folder paths from list_bundles for details. The tool handles race conditions internally with retry logic (200-500ms delays + exponential backoff built-in). No external sleep() delays needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
snapshotIdNoSnapshot ID from logicstamp_refresh_snapshot. Optional if watch mode is active - use projectPath instead for direct access.
projectPathNoAbsolute path to project root. Use this instead of snapshotId when watch mode is active for instant access to fresh context.
bundlePathYesRelative path to context.json file or context_main.json from project root. Use "context_main.json" for project overview, or folder paths like "src/components/context.json" for component bundles.
rootComponentNoSpecific ROOT component name to filter within the bundle file (optional). Only works for root components (listed in list_bundles). If omitted, returns the first bundle. Note: Dependencies appear in bundle.graph.nodes[] of the root that imports them, not as separate root bundles.
Behavior5/5

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

With no annotations provided, the description carries full burden and delivers: it discloses internal retry logic, race condition handling, and the pre-parsed nature of the data. It clearly indicates a read-only operation without mutating state, meeting transparency needs.

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?

While lengthy, the description is well-structured with a critical warning upfront, followed by operational details. Every sentence adds unique value, though it could be slightly condensed without losing substance.

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 4 parameters, no output schema, and moderate complexity, the description covers all essential aspects: usage scenarios, parameter relationships, output structure details (graph, edges, meta, UIFContract), and special behaviors. It is fully actionable for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing baseline of 3. Description adds significant value by explaining the interplay between snapshotId and projectPath, how bundlePath relates to context files, and the rootComponent constraint. This goes well beyond the schema descriptions.

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 description clearly states it reads bundle/index files for component contracts and dependency graphs, and differentiates between root and dependency components. Although it doesn't explicitly contrast with sibling tools, the purpose is specific and well-defined.

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?

Excellent guidance: explicitly warns against using sleep delays, explains when to use snapshotId vs projectPath, distinguishes root vs dependency lookup, and describes internal retry logic. This fully informs the agent about when and how to use the tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LogicStamp/logicstamp-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server