Skeletable

create_table

Make a private draft table, ready to fill, for anything from a tracker to a dataset. Its values say where they came from unless you set proof to required. Only title, columns and rows are needed now, but give question, scope, and a rule for each column if you can: a person has to supply them before publishing. Returns the column ids fill_cells needs, and the sheet's link, so tell your person to open it and watch it fill. Needs a token.

Input Schema

Name	Required	Description
`rows`	No	Row names. To add rows with their values, use add_rows after
`owner`	No	A team you're on. Leave out for your own account
`proof`	No	`optional` (the default): each value says where it came from, like a person, a file, an email or a page. `required`: every value must quote a source word for word, for a table of public facts
`scope`	No	What belongs in the table and what doesn't
`title`	No	Needed unless you use a template
`topic`	No	A broad subject, like Law or Consumer tech
`columns`	No	Needed unless you use a template
`question`	No	The question the table answers
`template`	No	Start from a template, with its columns set up: `job-tracker` (Every application, where it stands and what's next, kept current from your email), `text-dataset` (Labeled examples to train or test a classifier, ready to load in a notebook), `reading-list` (What you want to read, what you're reading, and what you thought), `research-notes` (Sources and what each one says, with a topic your agent fills in). Then only `title` is optional

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 2, 2026

addedInput schema / properties / columns / description
```
Added value: +"Needed unless you use a template"
```

changedInput schema / properties / rows / description

Previous value: -"Row names. To add rows with their values, create the table with one row and use add_rows"New value: +"Row names. To add rows with their values, use add_rows after"

removedInput schema / properties / rows / minItems
```
Removed value: -1
```

addedInput schema / properties / template

Added value: +{
+  "description": "Start from a template, with its columns set up: `job-tracker` (Every application, where it stands and what's next, kept current from your email), `text-dataset` (Labeled examples to train or test a classifier, ready to load in a notebook), `reading-list` (What you want to read, what you're reading, and what you thought), `research-notes` (Sources and what each one says, with a topic your agent fills in). Then only `title` is optional",
+  "enum": [
+    "job-tracker",
+    "text-dataset",
+    "reading-list",
+    "research-notes"
+  ],
+  "type": "string"
+}

addedInput schema / properties / title / description
```
Added value: +"Needed unless you use a template"
```

removedInput schema / required

Removed value: -[
-  "title",
-  "columns",
-  "rows"
-]

Changed5 schema fields changedNov 2, 2026

changedInput schema / properties / columns / items / properties / choices / description

Previous value: -"For an AI text column, the only answers it takes"New value: +"For a text column, the only values it takes, like a status list. An AI column answers with one of them"

addedInput schema / properties / columns / items / properties / type / description
```
Added value: +"A date is written YYYY-MM-DD"
```

changedInput schema / properties / columns / items / properties / type / enum

Previous value: -[
-  "text",
-  "number",
-  "boolean"
-]New value: +[
+  "text",
+  "number",
+  "boolean",
+  "date"
+]

changedInput schema / properties / proof / description

Previous value: -"`required` (the default): every value needs a source and exact quote. `optional`: values can instead say where they came from, for working data like a training set"New value: +"`optional` (the default): each value says where it came from, like a person, a file, an email or a page. `required`: every value must quote a source word for word, for a table of public facts"

changedInput schema / properties / proof / enum

Previous value: -[
-  "required",
-  "optional"
-]New value: +[
+  "optional",
+  "required"
+]

Changed3 schema fields changedNov 2, 2026

addedInput schema / properties / columns / items / properties / choices

Added value: +{
+  "description": "For an AI text column, the only answers it takes",
+  "items": {
+    "maxLength": 80,
+    "type": "string"
+  },
+  "maxItems": 50,
+  "type": "array"
+}

addedInput schema / properties / columns / items / properties / instruction

Added value: +{
+  "description": "Makes it an AI column: what to work out for each row, naming other columns in braces, like \"Classify {Pitch} by genre\". Needs proof to be optional",
+  "maxLength": 1000,
+  "type": "string"
+}

addedInput schema / properties / rows / description

Added value: +"Row names. To add rows with their values, create the table with one row and use add_rows"

Changed2 schema fields changedNov 2, 2026

addedInput schema / properties / proof

Added value: +{
+  "description": "`required` (the default): every value needs a source and exact quote. `optional`: values can instead say where they came from, for working data like a training set",
+  "enum": [
+    "required",
+    "optional"
+  ],
+  "type": "string"
+}

changedInput schema / properties / rows / maxItems
```
Previous value: -200New value: +500
```

First observedNov 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial context beyond annotations: it discloses the token requirement (auth), that the table is a private draft, that a person must supply missing fields before publishing, and that it returns column ids and a link. With annotations covering safety, this is exactly the extra behavioral detail an agent 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?

Front-loaded with purpose and required-vs-optional params, then return values. Dense and mostly every sentence earns its place, though the 'tell your person to open it' aside is minor flourish.

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?

For a non-idempotent, open-world mutation tool with no output schema, the description covers creation semantics, auth, downstream prerequisites, and return contents. An agent has enough to call it and hand off correctly.

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%, so baseline is 3; the description adds real meaning on top by explaining proof's default and required-mode behavior and that template changes which fields are required. It reinforces rather than merely repeats the schema.

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?

States a specific verb and resource ('Make a private draft table') plus scope ('anything from a tracker to a dataset'), and distinguishes it from the fill/export/get siblings by framing it as the creation step. An agent can tell this apart from add_columns or fill_cells immediately.

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?

Explains which params are required now vs. optionally useful ('Only title, columns and rows are needed now, but give question, scope, and a rule if you can') and points forward to fill_cells for the next step. It does not give explicit when-not-to-use or alternative-route guidance, but the workflow context is clear.

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

All Skeletable tools Inspect

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.

create_table

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources