Skip to main content
Glama
logisky

logisheets-mcp

by logisky

goal_seek

Read-only

Determine the input cell value that drives a target output to a desired number. Runs a bisection search without modifying the workbook, returning the solution or a clear non-answer.

Instructions

Find the input value that makes a chosen output equal a target — "what discount rate gives a value per share of 30".

Runs entirely on the engine's temp branch, so the workbook is never modified: this is a question, not an edit. The search happens inside the engine rather than as a conversation, so it costs one tool call instead of one per iteration.

Name both cells semantically as (block, row_key, field) or by coordinate as (row, col). Give between when you know a bracket; otherwise it expands outward from the current input value to find one.

Bisection, so it needs the output to move monotonically between the bracket ends and it finds one crossing. If the bracket does not straddle the target it says so rather than returning a number — a non-answer you can act on beats a plausible one you cannot.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesThe value `target` should reach.
setYesThe input cell to vary.
targetYesThe output cell to drive to `to`.
betweenNoSearch bracket [low, high]. Omit to expand outward from the current input value.
toleranceNoHow close to `to` counts as solved. Default 1e-6 relative.
max_iterationsNo
Behavior5/5

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

The description adds significant behavioral detail beyond the readOnlyHint and destructiveHint annotations: it explains the temp-branch execution, the bisection algorithm, the monotonicity requirement, and the behavior when the bracket does not straddle (returns a non-answer). This is exactly the kind of context that helps an agent predict outcomes.

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 compact and well-structured: it starts with a clear purpose, then a short note on safety, then usage details, then algorithm behavior. Every sentence earns its place without fluff or repetition.

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 (goal seek with bisection, optional bracket, monotonicity assumption) and lack of an output schema, the description covers all essential aspects: purpose, non-destructive nature, cell naming, bracket behavior, monotonicity requirement, and failure handling. It is fully sufficient for correct invocation.

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 high (83%), so the baseline is 3. The description goes further by explaining the semantics of the `between` parameter (optional, expand outward if omitted) and how to name cells (semantic vs. coordinate). It clarifies the search process and the meaning of the bracket, adding value beyond the schema's short descriptions.

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 states the tool's purpose precisely: 'Find the input value that makes a chosen output equal a target' with a concrete example. It distinguishes itself from sibling tools by framing it as a question rather than an edit, which is unique among the listed mutation/set tools.

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?

Provides clear guidance on when to supply a bracket ('Give `between` when you know a bracket') and how to reference cells. It also explains why to use this over iterative conversation (one call vs. many). However, it does not explicitly name alternative tools or state when NOT to use this tool, so it falls short of a 5.

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