Skip to main content
Glama

Create collection row

create_collection_row

Create one row. data maps field key → value, validated against the schema. Plan-gated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoSite id.
dataYesField key → value.
slugYesCollection slug.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / id
      Added value: +{
      +  "description": "Site id.",
      +  "maxLength": 256,
      +  "type": "string"
      +}
    • removedInput schema / properties / site_id
      Removed value: -{
      -  "maxLength": 256,
      -  "type": "string"
      -}
    • addedInput schema / properties / slug / description
      Added value: +"Collection slug."
  2. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations declare readOnly=false, destructive=false, and idempotent=false, so the safety profile is partly covered. The description adds meaningful context beyond them: 'validated against the schema' and especially 'Plan-gated,' which signals a non-obvious precondition the annotations don't 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?

Three tight fragments, front-loaded with the core action, and every clause carries information (validation, plan-gating). No filler, though the fragmentary style is terse enough that structure is minimal.

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

Completeness3/5

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

For a 3-param mutation with a nested object and no output schema, the description covers the essentials and flags plan-gating, but omits what a successful create returns, how validation failures surface, and any required site/collection selection context. Minimum viable.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters, making the baseline 3. The description restates that `data` maps field key → value and adds the validation note, but adds little syntax or format detail beyond the schema.

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?

States a specific verb (Create) and resource (one row), which distinguishes it from the bulk sibling create_collection_rows and from update_collection_row. It doesn't name the sibling explicitly, but 'one row' clearly implies singular creation, so it's clear though not fully differentiated in prose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'Create one row' versus the plural create_collection_rows sibling, but there's no explicit when-to-use guidance, no prerequisite for selecting a site/collection first, and no routing to alternatives. Adequate but leaves inference to the agent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources