Skip to main content
Glama
bim-ba

ycli

by bim-ba
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Get Forms fillable form

forms_filling_get
Read-onlyIdempotent

Retrieves a form's fillable structure—pages, questions, submit conditions, and values—so you can discover how to submit a response.

Instructions

The form's fill-time settings — the pages/questions to fill, submit conditions, and values.

Use this to discover a form's fillable structure: pages[].items[] are the questions (each a polymorphic question schema) and their id values are the slug keys a response is posted under. Complements surveys_get (admin settings) and questions_list (authoring view). Post a response with filling_submit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNoPersonal-link fill key, when the form uses one.
survey_idYesForm id, its slug, or an id+verification-key combination.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.122.1
    • removedInput schema / properties / survey
      Removed value: -{
-  "description": "Form id, its slug, or an id+verification-key combination.",
-  "type": "string"
-}
    • addedInput schema / properties / survey_id
      Added value: +{
+  "description": "Form id, its slug, or an id+verification-key combination.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "survey"
-]New value: +[
+  "survey_id"
+]
  2. First observedv0.67.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: the fill-time nature of the data, that pages[].items[] are polymorphic question schemas, and that item ids are the slug keys a response is posted under. No auth or rate-limit notes, but the disclosure is richer than the annotations alone.

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-loads what the tool returns, then the usage directive, then sibling routing — a sensible order with no filler. Slightly dense with backticked field paths, but every sentence carries information.

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?

There is no output schema, so the description compensates by describing the return structure (pages[].items[], id-as-slug-key) that an agent needs to consume the result, plus the downstream call to filling_submit. Nothing essential is missing for a read-only getter.

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 coverage is 100% for the two parameters (survey_id, key), so the schema already documents them fully. The description adds no param-specific guidance (e.g. how key interacts with personal-link forms), so the baseline 3 applies.

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 ('The form's fill-time settings') and immediately scopes it to pages/questions, submit conditions, and values. It explicitly distinguishes itself from surveys_get (admin settings) and questions_list (authoring view), so an agent can tell them apart without opening schemas.

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?

Gives an explicit use directive ('Use this to discover a form's fillable structure'), names the two sibling alternatives with the aspect each covers, and routes the follow-up action to filling_submit. When-to-use and the correct alternative are both stated.

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