Skip to main content
Glama

create_request_page

Create a file request (a request page in these tools): either 'send me files' or a form asking for typed answers (mode=form with fields, e.g. username, password, hostname). Private by default: senders need an access code, which send_request emails with the link. What senders enter is encrypted in their browser to the page's key. By default only the account owner's browser can read it; set readable_by_assistant=true only when the human asked you to read the answers back, and say so.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>"
    },
    "name": "create_request_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNo"form" to ask for typed answers (give `fields`), "files" (default) for uploads.
itemsNoFiles pages only: a checklist of what to send, one drop zone each; the sender says which item each upload is. Use for KYC and onboarding: passport, proof of address, a signed letter.
titleYes
fieldsNoThe questions on a form page, 1 to 20.
single_useNoClose the page after the first answer or upload. Defaults true: a request answers once. Pass false to keep the page open for repeated submissions.
visibilityNo"private" (default): senders need an access code, which send_request emails them. "public": anyone with the link.
expiry_daysNo
instructionsNoShown to the sender above the form or file picker.
max_file_bytesNoFiles pages only: the largest file a sender may upload, in bytes. Defaults to a tenth of the plan's storage; clamped down to what the plan allows.
remind_every_daysNoRemind the people send_request emails every N days (1 to 30) until they have sent every required item. Absent or 0: no reminders.
close_when_completeNoClose the page once everyone it was sent to has sent every required item. Defaults to true when `items` are given.
readable_by_assistantNoForm pages only. false (default): answers seal to the workspace key and only browsers given access can read them; you can see that answers arrived, never their content. true: answers seal to a key the service holds, so list_request_entries returns them to you. The sender is told either way. Use only when the human asked you to read the answers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly=false, destructive=false): it discloses that pages are private by default, that senders need an emailed access code, that input is encrypted in-browser to a page key, and the precise difference in who can read answers under readable_by_assistant. That is exactly the consequence-level detail an agent needs before creating a page.

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 compact sentences, front-loaded with what gets created and the default privacy posture. Slight redundancy in the parenthetical '(a request page in these tools)', but no sentence is wasted.

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?

For a 12-parameter, no-output-schema creation tool, the description covers the defaults, privacy model, and the one dangerous flag. It omits what identifier/link is returned, though it implies the link is distributed via send_request, which mostly covers that gap.

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 already high (83%), so the baseline is 3; the description adds meaning by explaining the visibility/access-code tie and the readable_by_assistant trade-off in plain terms. It does not restate expiry_days, remind_every_days, or max_file_bytes, but those are already schema-documented.

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+resource ('Create a file request') and spells out the two modes (files vs. form), so the agent knows exactly what is produced. It also clarifies the relationship with send_request (which emails the link), but never contrasts this with the other creation siblings such as create_upload_handoff or create_secret_handoff.

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

Usage Guidelines4/5

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

Gives clear conditional guidance for the risky knob: set readable_by_assistant=true 'only when the human asked you to read the answers back, and say so.' Mode selection and the KYC/onboarding use case give context, but there is no explicit when-not / alternative-sibling routing.

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