GetMattered

Get Account

getmattered_get_account

Read-onlyIdempotent

Reads your GetMattered account summary: plan, token balance, application usage and reset, resume and setup readiness, saved resumes, and connected email or Indeed accounts. Read-only.

Instructions

Read the user's GetMattered account summary. It returns the plan name, tier, status and renewal or end date; the AI token balance; the applications used and left in the current 30-day window and when it resets, plus the free allowance on a free account; the job preferences matches are found against (target roles, locations, remote); readiness: whether a resume is on file, whether account setup is finished, and the names of the profile fields employer forms require that are still empty; the saved resumes (id, title, base flag, last update); the default apply mode and whether Auto Apply is on; and whether Gmail, Outlook and Indeed are connected, with the connected address. It never returns passwords, access tokens, payment card details or the answers saved in the application profile. Read-only: it changes nothing and spends no credits. Call it before applying to several jobs, or when the user asks what they have left. Do not use it to change anything; use getmattered_update_job_preferences, getmattered_update_application_profile, getmattered_set_resume or getmattered_update_automatic_apply_settings. Next: getmattered_set_resume when no resume is on file, otherwise getmattered_get_matches.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`plan`	Yes
`resumes`	Yes
`autopilot`	Yes	Whether GetMattered applies on its own. Read only.
`readiness`	Yes
`billingUrl`	Yes
`preferences`	Yes
`applications`	Yes
`integrations`	Yes	Which outside accounts are connected. Null when it could not be read.
`tokenBalance`	Yes
`defaultApplyMode`	Yes	What getmattered_apply does when mode is omitted. Read only.
`freeApplications`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.9.1Oct 25, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description still adds genuinely non-obvious context: it spends no credits and never returns passwords, access tokens, payment card details or saved profile answers. That is real added value beyond annotations, but behavioral disclosure stops there (no rate limits, no staleness/refresh behavior).

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

Conciseness3/5

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

The behavioral and routing sentences are front-loaded and earn their place, but the long mid-section enumerating every returned field (plan, tier, balance, window, readiness, resumes, apply mode, connections) duplicates a rich output schema and could be compressed to a short capability summary without losing decision value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations, zero params and a full output schema, the definition covers everything an agent needs to select and call it, including post-call routing. The redundancy with the output schema is excess rather than a gap, so completeness is strong but not maximally efficient.

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 per the baseline this scores 4. The description correctly implies no input is needed, and nothing in it misleads about arguments.

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?

Opens with a specific verb+resource ("Read the user's GetMattered account summary") and enumerates what that summary contains, so an agent can tell it apart from get_application_profile and get_matches. The scope (account-level state: plan, credits, usage window, readiness, connections) is unambiguous.

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?

States explicit triggers ("Call it before applying to several jobs, or when the user asks what they have left"), an explicit exclusion ("Do not use it to change anything"), and names the exact mutating siblings to use instead, plus a next-step routing recommendation.

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

Deploy Server