Paperform

Authoring help

get_help

Read-onlyIdempotent

How to write Paperform source: the reference for form source and for Stepper workflow source (field types, frontmatter, layout grammar, the ops edit_source takes, and the rules a draft must pass). Pass exactly one of topic or query.

• topic — the reference for one surface. Read "markup-basics" before your first edit, then the topic for what you are editing ("forms" for a form, or "workflow" for a workflow). A reference that opens with a "## Sections" list leaves those sections out: before writing anything one covers, call again with topic and section. • section — with topic, one section from that list. • query — words to search every reference and section for, for a follow-up once you know the vocabulary.

Returns, for topic, { topic, reference } with the reference as markdown (also the text content), plus section when one was asked for; for query, { results: [{ topic, section, heading, excerpt }] } best match first, where section is a section id or "core:" for text the topic reference already includes.

Examples: get_help({ topic: "forms" }) → { "topic": "forms", "reference": "…" } get_help({ query: "conditional visibility" }) → { "results": [ { "topic": "forms", "section": "core:…", "heading": "…", "excerpt": "…" } ] }

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_help"
  }
}

Input Schema

Name	Required	Description
`query`	No	Words to search the references for.
`topic`	No	The reference to read in full: "markup-basics", "forms" or "workflow".
`section`	No	With topic: the id of one section from the "## Sections" list the topic reference opens with, or a section a query result named.

Output Schema

Name	Required	Description	Default
`topic`	No
`results`	No
`section`	No
`reference`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already establish this as a read-only, idempotent, non-destructive call, so the safety burden is light. The description still adds genuine behavioral detail beyond them: the 'pass exactly one of topic or query' constraint and the non-obvious gotcha that a topic reference opening with a "## Sections" list omits those sections until a second call is made. Return-format prose is partly redundant given the output schema exists.

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 the core purpose, then a compact bullet structure for each parameter, which is easy to scan. The closing examples largely restate return shapes already described a paragraph earlier, so they add some length without much new 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?

For a three-parameter documentation lookup with full schema coverage and an output schema, the description covers entry point, retrieval sequencing, parameter interaction, and the return contract. Nothing an agent needs in order to call it correctly on a first attempt is missing.

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 the baseline would be 3, but the description goes past the schema by defining the relationship between topic and section, naming the concrete topic values, and explaining that a section id can be either a listed id or the "core:<heading>" form surfaced by a query. The mutual-exclusivity rule for topic and query is not expressible in the supplied schema and is only stated here.

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?

The description opens with a specific verb and resource — the reference for writing Paperform form and Stepper workflow source — and enumerates the subject matter (field types, frontmatter, layout grammar, the ops edit_source takes, draft validation rules). That distinguishes it cleanly from siblings like edit_source, create, or search, which operate on documents rather than explaining how to write them.

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?

It prescribes sequencing explicitly: read "markup-basics" before the first edit, then the topic for what is being edited, and call again with topic plus section when a reference opens with a "## Sections" list. It also scopes query to follow-ups 'once you know the vocabulary', so the topic-vs-query choice is resolved rather than inferred.

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

All Paperform 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.

Resources

Need Help?