Skip to main content
Glama

Ask a human

createRequest

Collect answers from people outside this chat by link: an open form, survey, poll or sign-up sheet anyone can fill (one link to share anywhere), a form for specific named people (details, intake, availability), or an approval or sign-off from named people (human in the loop). Returns one url (open audience) or one link per named recipient. sendEmail: true emails each named recipient that has an email their link; links[].email is "sent", "failed", "limit", "no address" or "off" for each. Links that were not emailed are in the result for the user to pass on. mode "form" takes a JSON Schema (type object; fields of type string with format email|date|time|date-time|tel|uri|duration, number, integer, boolean, enum, array of primitives; no nested objects (except the location widget), oneOf, anyOf, allOf or $ref; at most 40 fields). Widgets via x-runitby.widget: textarea, radio, select, slider, rating, chips, slots (array of date-time enum), daterange (two dates), location (object, returns latitude/longitude/accuracy), color, country, language, timezone, yesno, rank (array of enum); money is a number with x-runitby.currency; boolean with const true is a required consent box. audience "named" gives each of 1 to 50 people their own link (attributed answers, reminders); "open" gives one link anyone can answer, for surveys, polls and sign-ups, capped by maxSubmissions. mode "approval" takes approval.reason and named recipients, and resolves with a verdict once approval.policy is met; set approval.verify "email" for money, access or deletion. Answers arrive at webhookUrl, by email to your user with notifyEmail, or through getStatus (with wait to block until someone answers); combine them freely. Each call counts as one request against the plan (250 a month on Free); past the limit it fails with a clear error and links already sent keep working.

Input Schema

NameRequiredDescriptionDefault
modeYes
themeNoColours, font and layout: https://runitby.app/llms.txt ("Theme").
titleYes
localeNoLanguage of the hosted page and its emails, optionally with a region for dates, like "es-AR". Write the title and questions in the same language.
schemaNoJSON Schema (type object) for forms. Supported types, formats, widgets and limits: https://runitby.app/llms.txt ("Schema subset").
approvalNo
audienceYes
metadataNoReturned untouched in every webhook and getStatus.
sectionsNo
expiresInNoDefault 7d, at most 90d.
requesterNoHow your agent introduces itself, e.g. "Ava (the Acme refunds agent)".
sendEmailNoEmail each named recipient that has an email their link now. Off by default: then you deliver the links yourself.
webhookUrlNo
notifyEmailNoEmail the account owner (your user) a summary and a dashboard link: "each" on every answer (until the plan's email limits, then only the end), "complete" once when the request completes or expires. Left out: the account's default from the dashboard ("off" unless changed).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations (not read-only, open world, non-destructive), the description discloses quota behavior (one request per call, 250/month Free), the failure mode past the limit, and that already-sent links keep working. It also specifies email delivery semantics, the meaning of links[].email statuses, that non-emailed links are returned for the user to pass on, approval resolution via policy, and answer delivery channels (webhookUrl, notifyEmail, getStatus with wait).

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?

The single dense block is front-loaded with purpose, then modes, audience, schema subset, delivery and quota; nearly every sentence carries operational information. It is appropriately sized for a 14-parameter tool, though the lack of any paragraph or list structure makes it harder to scan than it could be.

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?

With no output schema, the description still explains the return shape (one url for open audience, one link per named recipient, links[].email statuses). Combined with quota, failure behavior, expiry, delivery channels and approval semantics, an agent has essentially everything needed to call this correctly.

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 only 57% and there are 14 parameters with nested objects, so the description carries real weight: it explains mode/audience semantics, the schema subset and field limits (40 fields, no nested objects, allowed formats/widgets), sendEmail behavior, approval.verify and approval.policy resolution, and notifyEmail. Some parameters (sections, webhookUrl, theme) are left to the schema or undocumented, so it is not fully compensating.

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?

The description opens with a specific verb and resource: collect answers from people outside the chat via link, and enumerates the concrete shapes (form/survey/poll/sign-up, named intake form, approval). It distinguishes its modes and audiences well, but does not explicitly position itself against siblings like previewRequest or updateRequest, so an agent must infer that this is the creation step.

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?

It gives clear conditional guidance: audience 'open' is for surveys/polls/sign-ups and 'named' gives attributed links with reminders, approval.verify 'email' for money/access/deletion, and getStatus with wait if you want to block. Alternatives and exclusions versus previewRequest, updateRequest or closeRequest are not stated, which keeps it from a 5.

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