Skip to main content
Glama

Add application form field

add_screening_form_field

Add one field to the application form of a job position. Exactly one of two kinds per call:

  • preBuiltField: a field the product already knows how to ask (phoneNumber, linkedinUrl, resumeFile, selfiePhoto, neighborhoodLocation, birthday, sexAssignedAtBirth, pretendedSalary, currentSalary, willingToRelocate), with its label, widget and validation. Which ones a form accepts depends on how the position collects applications; the error lists them.

  • label + type: a custom question, with label as the candidate reads it. A select or multiselect takes at least 2 options.

The field's flags, unit and expected answer (required, isKnockout, expectedAnswer, currency/period) are set in the same call. A new field is required unless required is false. A knockout must be required and have a complete expected answer.

willingToRelocate is a yes/no question ("do you live in the job's area or are you willing to relocate there?"); once the form carries it, it replaces the automatic residence requirement derived from the position's location, and its expectedAnswer takes booleanValue. pretendedSalary collects an amount and takes currency and period together; its expectedAnswer uses operator/value or operator "between" with min and max. currentSalary also takes currency and period together, has no expected answer and cannot be a knockout.

The response reports criteriaVersionChanged: when true, the position's existing scores were computed against the previous form.

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": {
      "jobDescriptionId": "<jobDescriptionId>"
    },
    "name": "add_screening_form_field"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeNoType of the new custom field
labelNoThe question, as the candidate reads it. For a new custom field; requires type.
periodNoPeriod the amounts cover. Required together with currency.
optionsNoChoices for a select or multiselect field. At least 2 are required.
currencyNoISO currency code the amounts are expressed in (e.g. USD). Required together with period.
requiredNoWhether the candidate must answer this field
isKnockoutNoWhether an answer outside the expected one disqualifies the candidate automatically
maxDistanceKmNoMaximum commute distance in kilometres, for the "neighborhoodLocation" field only
preBuiltFieldNoName of a pre-built field to switch on. Mutually exclusive with label/type.
expectedAnswerNoThe expected answer. Setting it turns the expectation on. A knockout also needs the field to be required.
jobDescriptionIdYesThe job position ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description discloses real behavioral facts: exactly one kind per call, default required=true, a knockout must be required with a complete expected answer, currency/period must be supplied together, currentSalary cannot be a knockout. It also surfaces a side effect annotations do not capture — criteriaVersionChanged means existing scores were computed against the previous form.

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 constraint and organized into bullets by field kind, which suits an 11-parameter call with many conditional rules. The trailing prose paragraph on willingToRelocate/pretendedSalary/currentSalary is denser than needed and could be tightened, but every sentence carries a rule rather than filler.

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 non-idempotent mutation tool with a nested expectedAnswer object and no output schema, the description covers the conditional parameter rules, the validation constraints, and the one meaningful return field (criteriaVersionChanged). An agent has enough to construct a valid call without trial and error.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, yet the description still adds cross-parameter meaning the schema cannot express: mutual exclusivity of preBuiltField and label/type, the enumerated pre-built field names, 'at least 2 options' for select/multiselect, currency and period as a required pair, and which expectedAnswer shape goes with which field kind (booleanValue for willingToRelocate, min/max for 'between').

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 opening sentence names a specific verb and resource: 'Add one field to the application form of a job position.' The singular 'one field' plus the two-mutually-exclusive-kinds framing cleanly separates it from update_screening_form_field, remove_screening_form_field and reorder_screening_form_fields without needing to name them.

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 explicit selection guidance between the two modes ('preBuiltField' vs 'label' + 'type') and notes that acceptable pre-built fields depend on how the position collects applications, with the error listing them. What it never states is when to reach for a sibling instead (e.g. update_ to change an existing field), so routing among the form-mutation tools is left implicit.

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