Skip to main content
Glama
logisky

logisheets-mcp

by logisky
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

convert_to_block

Turn an existing spreadsheet table into a named block with fields and row keys, keeping values intact, so formulas can reference it by name instead of cell coordinates.

Instructions

Turn a table that already exists in ordinary cells into a block, in place, without touching its values.

This is how you adopt a workbook someone hands you. create_block is for new tables and refuses to write over existing data; this one takes the data as it stands and gives it a name, fields and row keys, so you can address it as (block, row_key, field) and reference it from formulas by name instead of by coordinate.

Give position and the counts for the DATA only, leaving out any header row. Field names come from the header row — pass header_row, or leave it out and the row directly above the data is used when it looks like titles. fields states them outright instead.

The row key is inferred: the first column whose values are all present and all different. Pass key_field to choose. Whatever is inferred is reported back, so check it — the key is how formulas and later edits name a row.

Converting is a one-time cost: the block and its schema survive saving and reloading, and afterwards the region behaves exactly like one created as a block.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesRef name for the new block — BLOCKREF's first argument. Must be unique.
sheetYesSheet the table is on.
fieldsNoField names, when there is no header row. Length must equal col_count.
positionYesTop-left cell of the data, excluding the header row.
col_countYesNumber of columns.
key_fieldNoWhich field identifies a row. Omit and the first column whose values are all present and all different is used.
row_countYesNumber of data rows.
header_rowNoRow holding the column titles; field names are read from it. Omit it and the row directly above `position` is used when it looks like a header — all text, over data that is not.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.1
    • changedInput schema / properties / header_row / description
      Previous value: -"Row holding the column titles; field names are read from it. Usually one row above `position`."New value: +"Row holding the column titles; field names are read from it. Omit it and the row directly above `position` is used when it looks like a header — all text, over data that is not."
    • addedInput schema / properties / key_field
      Added value: +{
+  "description": "Which field identifies a row. Omit and the first column whose values are all present and all different is used.",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context: it is in-place, does not alter values, the conversion is a one-time cost, the schema persists, and the row key inference is reported back. It does not mention potential error conditions or reversibility, but given the annotation coverage, it is adequate.

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?

The description is well-structured and front-loaded with the core purpose. It is somewhat lengthy but every sentence adds meaningful information about usage, parameter relationships, or persistence. It could be trimmed slightly, but it remains focused and organized.

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 complexity (8 parameters, nested objects, no output schema), the description is thorough. It covers the main use case, parameter semantics, inference behavior, and the fact that the inferred key is reported back. No critical information for invoking the tool correctly is missing.

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?

Even though the schema covers all parameters (100% coverage), the description adds substantial semantic value beyond the schema. It clarifies that position and counts refer to data only, explains the relationship between header_row and fields, and details how key_field inference works. This goes beyond simple parameter descriptions to explain how to use them together effectively.

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 action: turning an existing table into a block in place without altering values. It distinguishes itself from the sibling create_block by explicitly noting that create_block is for new tables and refuses to overwrite existing data, making the purpose unambiguous.

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?

It provides explicit guidance on when to use this tool versus create_block: 'This is how you adopt a workbook someone hands you. create_block is for new tables and refuses to write over existing data.' It also explains the context of adopting existing data and how this tool fits the workflow.

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

Deploy Server

Other Tools