Skip to main content
Glama

Insert file question

editor_insertFileQuestion

Insert a file upload question. Configure accepted file types and size limits.

Input Schema

NameRequiredDescriptionDefault
afterNoNodeId to insert after. Use $prev to chain. Omitting appends to end (usually wrong).
titleYesQuestion title
acceptNoAccepted file types, comma-separated. Extensions ".pdf,.jpg" or MIME types "image/*".
formIdYesForm ID to insert into
maxSizeNoMaximum file size in bytes (must be > 0)
isHiddenNoStart hidden (the target of a `show` rule).
maxFilesNoMaximum number of files
minFilesNoFewest files to upload
parentIdNoParent node ID to insert into (e.g., column1)
positionNoPosition among siblings: inside parentId when given, else at the top level ('first' = top of the form, e.g. a title). Not combinable with after.
requiredNoWhether question is required. Default: true. Pass false to make the field optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / minFiles
      Added value: +{
      +  "description": "Fewest files to upload",
      +  "maximum": 100,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  2. First observed

TDQS

C2.9/5.0
Behavior2/5

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation/safety profile is covered structurally, but the description adds no behavioral context at all. It omits the risks its own schema hints at, such as the default of required=true and that omitting 'after' appends to the end (called out as 'usually wrong').

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?

Two short sentences, front-loaded with the verb and resource, with no filler. It is efficient, though it restates the tool title almost verbatim rather than spending the words on something the agent lacks.

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 an 11-parameter mutation tool with no output schema, the description is thin: it never addresses placement semantics (after vs position vs parentId) or defaults, which is where an agent is most likely to err. Complete enough to invoke via the schema, but it does not cover the failure modes the schema itself flags.

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 every one of the 11 parameters is already documented, including the accept pattern and maxSize units. The description's mention of accepted file types and size limits merely paraphrases two schema fields and adds no syntax, default, or interaction detail beyond them.

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?

Names a specific verb and resource (insert a file upload question), which is enough to separate it from the many other editor_insert* question-type siblings. However, it does not explicitly contrast with adjacent question types such as picture choice or signature, so the differentiation rests on the noun alone.

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

Usage Guidelines2/5

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

No when-to-use, prerequisites, or alternatives are given. Nothing tells the agent whether a form must already exist, whether it should be called before or after other inserts, or which sibling to reach for when a non-file question is intended.

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.