GetMattered

Get Application Profile

getmattered_get_application_profile

Read-onlyIdempotent

Retrieves your GetMattered application profile answers, including contact, work, legal and EEO details, plus any required fields still empty or guessed in recent applications, so you can fill the gaps before saving.

Instructions

Read the user's application profile: the answers GetMattered types into employer application forms. It returns contact details and links; work details (current employer, date of birth, work authorization, relocation, start date, notice period, travel, security clearance, education, years of experience and a short personal note); the five legal declarations; and the voluntary self-identification (EEO) answers. It also returns the open questions: required fields that are empty, and details recent applications had to guess because the user never gave them, each with the field that answers it. The EEO answers and the date of birth are sensitive: show them only to the user. Read-only: it changes nothing and spends no credits. Do not use it to save answers; use getmattered_update_application_profile. Next: ask the user for anything still open, then getmattered_update_application_profile.

Input Schema

Name	Required	Description	Default
No arguments

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.

Addedv1.10.2Oct 25, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes beyond the readOnly/idempotent annotations by disclosing that the call 'changes nothing and spends no credits' and flagging that EEO answers and date of birth are sensitive and should be shown only to the user. That credit-cost and sensitivity context is genuinely useful and not derivable from structured fields; a slight deduction only because return-shape detail overlaps with the output schema.

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 purpose, then contents, then safety, then next steps — a logical order with no filler sentences. It runs long, but every clause carries operational information about what is returned or how to use it.

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?

Given rich annotations, an output schema, and zero parameters, the description covers purpose, sensitivity handling, cost, and the next action. Nothing an agent needs to call it correctly is absent.

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?

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. No parameter guidance is missing.

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 ('Read the user's application profile') and enumerates exactly what comes back: contact details, work details, five legal declarations, EEO answers, and open questions. An agent can distinguish it from the save-oriented sibling without opening the 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?

Explicitly names the alternative and the exclusion: 'Do not use it to save answers; use getmattered_update_application_profile.' It also prescribes the follow-on sequence (ask the user about anything open, then update), leaving nothing to inference.

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

Deploy Server