Skip to main content
Glama
logisky

logisheets-mcp

by logisky

trace

Read-only

Trace spreadsheet cell dependencies using the engine's graph to identify what affects a number or what depends on it before changing assumptions.

Instructions

Follow a cell's dependencies, in either direction, using the engine's own dependency graph.

  • precedents — what this cell reads. Use it to audit a number: "why is value-per-share what it is".

  • dependents — what reads this cell, and through which reference. Use it before changing something: "what breaks if I edit this assumption".

Both by default. Name the cell semantically as (block, row_key, field), or by coordinate as (row, col) with an optional sheet_idx. Results come back named the same way whenever the cell sits inside a block, so you get "assumptions.wacc" rather than a coordinate to interpret.

This asks the engine rather than reading formula text, so it sees through BLOCKREF, ranges and whole-column references, and it answers the reverse direction — which formula strings cannot.

Granularity matters when blocks are involved. The engine tracks block dependencies per (block, field), not per row, so dependents of one block cell is everything reading that FIELD — the queried row among them. Each edge carries scope: "cell" is exact, "field" and "block" are over-approximations, and approximate: true is set on the result when any edge is wider than a cell. Treat a field-wide answer as "at least these", not "exactly these".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYesThe cell to trace. Either (block, row_key, field) or (row, col).
directionNoboth
Behavior5/5

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

Beyond the readOnly/destructive annotations, the description discloses critical behavior: it uses the engine's dependency graph, returns semantic names for block cells, and tracks dependencies per field rather than per row, causing over-approximation. It explicitly explains the 'scope' field and approximate flag, ensuring the agent understands the interpretive caveat.

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

Conciseness5/5

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

The description is well-structured: starts with purpose, then usage, then behavior, then granularity caveats. Every sentence adds value and is directly relevant to correct use. Despite its length, it is not redundant; it front-loads the essential purpose and usage, followed by necessary technical detail.

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 the tool's complexity (dependency tracing, block granularity, approximation), the description covers all key aspects: the two directions, naming, the engine's view through references, and the interpretation of field-wide results. It lacks an output schema, but the description suffices to understand what results will look like and how to use them.

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

Parameters5/5

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

The description adds substantial meaning beyond the schema: it explains the two naming conventions (semantic vs coordinate) for the target parameter, clarifies the default for direction ('Both by default'), and details how results are named. This compensates for the schema's partial coverage and adds practical guidance for parameter usage.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Follow a cell's dependencies, in either direction, using the engine's own dependency graph.' It specifies both directions (precedents/dependents) and gives concrete use cases, distinguishing it from sibling tools like eval_formula by mentioning it sees through BLOCKREF and ranges.

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?

Explicit guidance is given: use precedents for auditing a number and dependents before changing something. It also contrasts with formula-string reading and explains when to rely on the result granularity, including how to interpret approximate results. This gives clear when-to-use and what-to-expect context.

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/logisky/logisheets-mcp'

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