GetMattered

Get Applications

getmattered_get_applications

Read-onlyIdempotent

List job applications by status—including those waiting for your review—or read one by ID to inspect its resume, cover letter, screening answers, stop reason, queue position, and employer confirmation.

Instructions

List the user's applications and where each one stands, or read one by application_id to see what will be or was sent: the tailored resume, the cover letter, the screening answers, why it stopped, and its place in the queue, plus the employer's confirmation page as an image when that page is the proof. Use this to check progress, to find applications waiting for the user's approval (status "waiting_for_review"), or to see whether an employer confirmed a submission. An application is reported as employer-confirmed only when the employer sent a receipt or showed its confirmation page. Other status filters: queued_to_apply, submitted, verified, not_landed, taken_down. Returns 20 per page. Read-only: it spends no credits and changes nothing. Do not use it to act on an application; use getmattered_approve_applications or getmattered_reject_applications. Next: getmattered_approve_applications or getmattered_reject_applications for what is waiting.

Input Schema

Name	Required	Description
`page`	No	Page number, starting at 1 (e.g. 2 for the next page)
`status`	No	Filter the list: waiting_for_review (the review queue), queued_to_apply, submitted, verified, not_landed or taken_down. Omit for all.
`application_id`	No	Read one application by its id (e.g. 1550). Omit to list applications.

Output Schema

Name	Required	Description
`page`	Yes
`detail`	Yes	Filled when one application_id was read: what will be or was sent.
`totalPages`	Yes
`applications`	Yes
`totalApplications`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.10.2Oct 25, 2026

changedOutput schema / properties / applications / items / properties / applicationId / description

Previous value: -"Pass to getmattered_review_application or back to getmattered_get_applications."New value: +"Pass to getmattered_approve_applications, getmattered_reject_applications or back to getmattered_get_applications."

Addedv1.9.1Oct 25, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond those: it spends no credits, changes nothing, returns 20 per page, and defines what 'employer-confirmed' means and why an application might appear in that state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary list/read distinction, then moves through status semantics, confirmation meaning, pagination, safety, and alternatives. Despite its length, every section provides substantive routing or behavioral information, and there is no 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?

Given that an output schema exists, the description does not need to enumerate return fields. It still provides enough context about filtering, single-application reads, confirmation semantics, pagination, safety, and alternatives for an agent to call the tool 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 100%, so the baseline is 3, but the description adds meaning by explaining that application_id switches from listing to reading a single application and by describing the detail that will be returned. It also clarifies that 'waiting_for_review' corresponds to the review queue and that page size is 20, though some status-list details are repeated from 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 specific verb and resource: 'List the user's applications' and 'read one by application_id', and distinguishes the two modes clearly. It also names sibling tools for taking action, so an agent can differentiate it from getmattered_approve_applications and getmattered_reject_applications.

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 gives explicit use cases: checking progress, finding applications waiting for approval, and verifying employer confirmation. It also states an explicit exclusion: 'Do not use it to act on an application' and names the correct alternatives for acting on applications.

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

Deploy Server