GetMattered

Update Application Profile

getmattered_update_application_profile

DestructiveIdempotent

Save your answers to employer application questions in your GetMattered profile. Only the fields you state are updated; null clears one.

Instructions

Save answers in the user's application profile, the answers GetMattered types into employer application forms. Pass at least one field, and only fields the user stated in this conversation: only those change, every other saved answer stays as it is, and null clears one. Never infer or guess a value, and never fill a field from the resume, a name or a photo unless the user said it. Fields: phone, address, city, state, zip code, country, LinkedIn, portfolio and GitHub links, current employer, date of birth, work authorization, relocation, start date, notice period, travel, security clearance, education, years of experience, a short personal note, five legal declarations, and the voluntary self-identification (EEO) answers. The EEO answers (gender, ethnicity, veteran_status, disability_status, sexual_orientation, pronouns) are optional and sensitive: save one only when the user gives it; they are used only to answer the voluntary self-identification questions on employer forms, and each accepts prefer_not_to_say. A saved answer replaces the previous one, which is not kept; to undo, save the earlier value again. Nothing is sent to any employer and nothing is spent. Returns the profile after the change and the questions still open. Do not use it to read the profile; use getmattered_get_application_profile. Next: getmattered_get_matches or getmattered_apply.

Input Schema

Name	Required	Description
`city`	No	City.
`phone`	No	Phone number, as the user gave it, for example +1 555 123 4567.
`state`	No	State, province or region.
`gender`	No	Optional and sensitive. Gender, for the voluntary self-identification questions on employer forms. prefer_not_to_say declines to answer.
`country`	No	Country.
`pronouns`	No	Optional and sensitive. Pronouns in the user's own words, for example she/her. Never infer them.
`zip_code`	No	ZIP or postal code.
`ethnicity`	No	Optional and sensitive. Ethnicity, for the voluntary self-identification questions on employer forms. prefer_not_to_say declines to answer.
`github_url`	No	GitHub profile URL.
`linkedin_url`	No	LinkedIn profile URL.
`address_line1`	No	Street address, line 1.
`address_line2`	No	Street address, line 2, such as an apartment or suite.
`date_of_birth`	No	Date of birth as YYYY-MM-DD. Only when the user gives it; few employer forms ask for it.
`notice_period`	No	Notice period before the user can start.
`portfolio_url`	No	Portfolio or personal website URL.
`veteran_status`	No	Optional and sensitive. Veteran status, for the voluntary self-identification questions on employer forms. prefer_not_to_say declines to answer.
`current_employer`	No	Current employer.
`disability_status`	No	Optional and sensitive. Disability status, for the voluntary self-identification questions on employer forms. prefer_not_to_say declines to answer.
`highest_education`	No	Highest education level completed.
`personal_narrative`	No	A short note, up to 500 characters, on career gaps, changes or short stints. Used for interview preparation.
`security_clearance`	No	Security clearance level. prefer_not_to_say declines to answer.
`sexual_orientation`	No	Optional and sensitive. Sexual orientation, for the voluntary self-identification questions on employer forms. prefer_not_to_say declines to answer.
`travel_willingness`	No	How much work travel the user accepts.
`work_authorization`	No	Work authorization status.
`willing_to_relocate`	No	Whether the user is willing to relocate for a job.
`years_of_experience`	No	Total years of professional experience.
`available_start_date`	No	Earliest start date as YYYY-MM-DD.
`relocation_locations`	No	Places the user would relocate to, as "City, Country" or "Country".
`criminal_record_status`	No	Whether the user has a conviction they are legally required to disclose. prefer_not_to_say declines to answer.
`background_check_consent`	No	Whether the user consents to a background check where a role requires one. prefer_not_to_say declines to answer.
`export_control_us_person`	No	Whether the user is a U.S. person for export-control (ITAR or EAR) purposes. prefer_not_to_say declines to answer.
`related_to_employee_status`	No	Whether the user is related to an employee of a company they apply to. prefer_not_to_say declines to answer.
`restrictive_covenant_status`	No	Whether the user is bound by a non-compete or non-solicit agreement with a former employer. prefer_not_to_say declines to answer.

Output Schema

Name	Required	Description
`changed`	Yes	The input fields this call saved. Empty from getmattered_get_application_profile, which only reads.
`profile`	Yes	The saved answers employer forms are filled from, after this call. Field names are the API's camelCase twins of the inputs.
`openQuestions`	Yes	Details GetMattered guessed because the user never gave them. Null when they could not be read.
`missingRequiredForApply`	Yes	Fields employer forms require that are still empty. Ask the user; never guess.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.10.2Oct 25, 2026

changedOutput schema / properties / changed / description

Previous value: -"The input fields this call saved. Empty when it only read."New value: +"The input fields this call saved. Empty from getmattered_get_application_profile, which only reads."

Addedv1.9.1Oct 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations it explains merge semantics ('only those change, every other saved answer stays as it is'), the null-clears convention, irreversibility ('the previous one, which is not kept; to undo, save the earlier value again'), and safety boundaries ('Nothing is sent to any employer and nothing is spent'). The destructiveHint=true annotation is consistent with the disclosed overwrite-on-save behavior rather than contradicted by it.

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 critical constraint (only user-stated fields, no inference) is front-loaded and the ordering is logical: rules, then field inventory, then sensitive-data carve-out, then return/next steps. It runs long, and the laundry-list of ~30 field names restates what the schema already documents.

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 33-parameter mutation with sensitive data, the description covers everything an agent must know: partial-update semantics, null semantics, undo path, the sensitive EEO subset with prefer_not_to_say, privacy guarantees, and what is returned ('the profile after the change and the questions still open'). The output schema handles the shape of the return.

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 is 3; the description earns above that by adding rules the schema can't express — never infer values, never pull from resume/name/photo, and for the six EEO fields save only when the user volunteers them. It also enumerates the field families, which is somewhat redundant with the schema.

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 concrete verb+resource ('Save answers in the user's application profile') and immediately explains what those answers are for ('the answers GetMattered types into employer application forms'). It explicitly contrasts itself with getmattered_get_application_profile, so the agent can distinguish this from its read-only sibling without opening either schema.

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 states the call precondition ('Pass at least one field'), the sourcing rule ('only fields the user stated in this conversation'), and an explicit exclusion with the named alternative ('Do not use it to read the profile; use getmattered_get_application_profile'). It also routes forward to the logical next tools (get_matches, apply).

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

Deploy Server