Skip to main content
Glama
Sign In

Skeletable

by io.github.eftpmc
OverviewDiscussionsAdmin

fill_cells

Set up to 200 cells of a table you run. Usually a cell gives value and origin (entered, imported with a note like the file or email it came from, link with its source, or generated). Left out, the origin is link when there's a source and generated when there isn't. These can go into a published table too, and never replace a quoted value. A date is written YYYY-MM-DD, and a column with choices takes only one of them. In a table that requires proof, a cell instead gives value, source and quote, word for word from the source; each page is opened before it's saved, so send at most 25 of these at once, and only into a draft. If no acceptable source states it, give checked with the pages you read, and none_stated only if you read the whole source and it has no such value. The reply counts what saved and lists only the cells that didn't, with a reason, and unchecked names quoted values whose page couldn't be read. Needs a token.

Input Schema

NameRequiredDescriptionDefault
slugYesFrom create_table or list_tables
cellsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / cells / items / properties / value / anyOf
      Added value: +[
+  {
+    "maxLength": 2000,
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  }
+]
    • removedInput schema / properties / cells / items / properties / value / maxLength
      Removed value: -2000
    • removedInput schema / properties / cells / items / properties / value / type
      Removed value: -"string"
  2. Changed4 schema fields changed
    • addedInput schema / properties / cells / items / properties / note
      Added value: +{
+  "description": "How a value without a quote was made, such as the prompt that generated it",
+  "maxLength": 500,
+  "type": "string"
+}
    • addedInput schema / properties / cells / items / properties / origin
      Added value: +{
+  "description": "Where a value without a quote came from. Only in a table whose proof is optional",
+  "enum": [
+    "link",
+    "generated",
+    "entered",
+    "imported"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / cells / items / properties / value / maxLength
      Previous value: -300New value: +2000
    • changedInput schema / properties / cells / maxItems
      Previous value: -25New value: +200
  3. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Adds a lot beyond the annotations: quoted values are never replaced, proof-table writes only land in a draft, each cited page is opened before saving (so batches are capped at 25), and a token is required. It also discloses the response shape ('counts what saved and lists only the cells that didn't, with a reason') and the `unchecked` failure mode, which annotations alone (destructiveHint=false, idempotentHint=false) could not convey.

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?

Front-loaded with the action, the 200-cell cap, and the default origin rule before the mode-specific branches. It is dense and slightly tangled as it hops between the proof-optional and proof-required modes, but every sentence carries an actionable constraint, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter but structurally rich nested-cell payload with no output schema, the description covers value formats, provenance modes, batch caps, draft restriction, auth, and the return summary. The main remaining hole is how `row` is addressed (id vs label) and how partial failures interact with retries, given idempotentHint=false.

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 only 50%, and the description compensates well: it defines the `origin` enum members and the defaulting rule (`link` with a source, otherwise `generated`), the date format YYYY-MM-DD, single-choice column constraint, the `quote` word-for-word requirement, and the `checked`/`none_stated` distinction. It leaves `row` and `column` addressing unexplained (the schema only says column id from get_table), so the gap is narrowed rather than closed.

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?

Opens with a specific verb and resource plus a hard scope limit ('Set up to 200 cells of a table you run'), which tells the agent exactly what the call writes and how much. It implicitly contrasts with fill_ai_cells by describing human-supplied values, but never names that sibling, so the agent must infer the split between manual and AI cell filling.

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?

Gives detailed conditional routing: use `origin` in tables where proof is optional, use `value`/`source`/`quote` where proof is required, use `checked` when no acceptable source states it, and `none_stated` only after reading the whole source. That is strong when-to-use guidance, but no sibling is named (e.g. fill_ai_cells vs this tool), so the top-level choice between tools is left implicit.

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

All Skeletable toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources