Skip to main content
Glama

Save a draft from a PDF

create_form_from_pdf

Fetch a PDF or page URL and save a draft form in the authenticated organization, the same way claiming a preview does. Requires an org API key with the forms:write scope. Uses the on-server parser only: Workers AI and other models stay off. Returns formId and editorUrl (/app/forms/{formId}). Does not publish the form. File contents are not logged.

Input Schema

NameRequiredDescriptionDefault
urlYeshttps URL of a blank volunteer PDF.
titleNoOptional title override.

Output Schema

NameRequiredDescriptionDefault
titleYes
formIdYesDraft form id.
parserYesOn-server parser. Workers AI stays off.
editorUrlYesEditor URL, /app/forms/{formId}.
fieldCountYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / properties / title / description
      Added value: +"Optional title override."
    • addedInput schema / properties / url / description
      Added value: +"https URL of a blank volunteer PDF."
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "editorUrl": {
      +      "description": "Editor URL, /app/forms/{formId}.",
      +      "format": "uri",
      +      "type": "string"
      +    },
      +    "fieldCount": {
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    "formId": {
      +      "description": "Draft form id.",
      +      "type": "string"
      +    },
      +    "parser": {
      +      "const": "heuristic",
      +      "description": "On-server parser. Workers AI stays off.",
      +      "type": "string"
      +    },
      +    "title": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "formId",
      +    "title",
      +    "fieldCount",
      +    "editorUrl",
      +    "parser"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only cover the read/write/destructive/open-world tri-state, but the description adds auth requirements (forms:write scope), a processing constraint (on-server parser only, Workers AI off), the side-effect boundary ('Does not publish the form'), and a data-handling guarantee ('File contents are not logged'). That is exactly the extra behavioral context annotations cannot carry.

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?

Five short sentences, front-loaded with the action and scope, with no filler. The only minor slack is restating the return values (formId, editorUrl) when an output schema already exists.

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?

Annotations cover safety, the output schema covers return shape, and the description covers auth, processing path, and side effects, so an agent has what it needs to invoke correctly. The remaining gap is sibling disambiguation, which is left to inference.

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% and both parameters are already documented in the schema, so the description neither needs to nor does add syntax or format detail. 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+resource pair ('fetch a PDF or page URL and save a draft form') plus scope ('in the authenticated organization'). It also orients the agent relative to siblings by likening the behavior to claim_preview and explicitly noting it does not publish, which separates it from publish_form.

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?

Provides real prerequisite context ('Requires an org API key with forms:write scope') and states the operation only creates a draft, but never names an alternative or exclusion condition. An agent choosing between this, create_form, preview_volunteer_form, and convert_pdf_preview gets no routing rule.

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