Skip to main content
Glama

updateScreeningQuestion

Edits a screening form question: its text, description, answer type, content, or whether it is required. Pass only the fields to change, except that changing type also requires the matching content for the new type (unless the new type takes none). Only usable before the form is live; live forms are edited from the Stomio dashboard. Each question carries ready: false means it fails authoring validation (a choice question with no options, say) and blocks publishScreeningForm until fixed. ready is input for your reasoning, not for users: when everything passes, do not mention it; when something fails, say what is missing in plain words instead of quoting the flag.

Input Schema

NameRequiredDescriptionDefault
textNoThe question shown to applicants.
typeNoThe new answer type.
contentNoThe step configuration, shaped by type: for MultipleChoices/SingleChoice an array of at least 2 { choice } options with non-empty texts, optionally plus ONE final { choice: "Other", other: true } option that lets the tester type a free answer (its label is fixed: choice must be the literal text "Other", any other wording is rejected); for Rate an object { scale (number, 3 or more), symbol ("Thumb", "Star" or "Square"), lowerText?, higherText? (labels for the scale ends, up to 20 characters, default empty) }; for Ranking an array of at least 2 items { id (a v4 UUID you generate), text } with unique ids and unique texts; for TriggeredEmail an object { to, subject, message, cc? } where to is { allManagers?: boolean, allTesters?: boolean, tagsIds?: string[], personFieldIds?: string[] } and names at least one audience, subject is plain text of at most 128 characters and takes no variables (nothing replaces them there, so the recipient would read the braces), message is the email body as basic HTML reading at most 4096 characters of text, and cc is a list of Person custom field ids. Any other key of the email object or of to is rejected rather than dropped, so bcc and to.emails are not accepted: nothing would send to them. tagsIds are tester tag ids from listTesterTags, and ONLY the entries it marks assignable: a computed smart tag is rejected because a triggered email cannot be sent to one. personFieldIds and cc are ids of Person-type fields from listCustomFields; a personFieldIds field routes the email to the manager-persons that tester recorded in it, cc puts them in copy. The email goes out the first time a tester answers or skips the step before it (skipping a whole optional task sends nothing), one email per tester, and the audiences reach: allTesters ONLY that tester, never every tester in the beta project; tagsIds that same tester, only if they carry one of the tags (tester tags never reach managers, and beta labels are not tags); allManagers every manager on the beta project. To notify a manager when a tester finishes a task, make this the task's last step and use allManagers or personFieldIds. message may use these tester variables: {{USERNAME}}, {{FULL_NAME}}, {{ADDRESS}}, {{EMAIL}}, {{PHONE}}, {{PROJECT_NAME}}, {{WORKSPACE}}, {{REMAINING_PROJECT_DAYS}}, {{CURRENT_WEEK_DAY}}. The {{MANAGER_*}} ones belong to invitations and are rejected here. On an SDK beta project the audience must be managers only (allManagers), because its testers are not workspace testers and every other audience would reach nobody. REQUIRED for MultipleChoices, SingleChoice, Rate, Ranking and TriggeredEmail; omitting it is rejected. Must be OMITTED for FreeText, Instructions and File; passing one is rejected. Omit it for YesNo too (its answers are fixed to Yes / No, set automatically); passing that exact pair back is accepted, anything else is rejected. Pass the array or object value itself, not a JSON-encoded string. Call getBetaTasks to see the current shape of existing steps.
requiredNoWhether the applicant must answer.
productIdYesID of the beta project to query. Get valid IDs from the listProducts tool.
questionIdYesThe questionId of a screening form question, from getScreeningSetup. Never invent ids.
descriptionNoSupporting detail shown under the question (basic HTML allowed).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare the write, non-destructive profile; the description adds real behavioral context beyond that: the pre-live-only window, the type/content coupling, partial-update semantics, and the existence of a `ready` validation flag that blocks publishScreeningForm. It stops short of saying what the mutation returns or what error surfaces on a rejected content payload, so a 5 is not warranted.

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 verb, resource, and editable fields; the pre-live restriction follows before the validation discussion. The final paragraph about how to phrase the `ready` flag for users is materially longer than the rest and is presentation guidance rather than tool behavior, which slightly dilutes the structure.

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 7-parameter mutation tool with full schema coverage and no output schema, the description covers the gaps that matter: when the operation is legal, how partial updates behave, the type/content dependency, and the validation state an agent must reason about after the call. An agent can call this correctly and interpret the result without further context.

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 schema already documents each field and its constraints, setting a baseline of 3. The description still adds cross-parameter meaning the schema does not: that omitted fields are left untouched and that `type` and `content` must be supplied together for content-bearing types, which is decision-relevant semantics.

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 ('Edits a screening form question') and enumerates exactly which attributes are editable (text, description, answer type, content, required). The phrase 'screening form question' plus the reference to publishScreeningForm / live forms distinguishes it from the task-step editing siblings like updateStep.

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 an explicit when-not constraint ('Only usable before the form is live; live forms are edited from the Stomio dashboard') and a partial-update rule ('Pass only the fields to change'), plus the conditional requirement that a type change needs matching content. It does not name sibling tools such as addScreeningQuestion, deleteScreeningQuestion, or configureScreening as the alternatives, so routing is implied rather than stated.

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