Skip to main content
Glama

Create the first resume profile

create_profile

Create the first resume of an account that has no profile yet, either from the text of the user's resume (resume_text) or from five answers about their work (guided: role, years of experience, education, skills, last job). Exactly one of the two is passed. It works before setup is finished and completes setup once the resume is saved. Runs asynchronously — returns a task_id immediately; get_task_status(task_id) reports progress and, when done, the new resume_id. Consumes one resume generation from the user's plan; on the free plan this is the month's only resume generation. Once the resume is saved, the job radar's automatic search is turned on and its first scan runs, built from the resume and the account's country; the account's first scan is not counted against the radar quota. get_radar_status shows the search, and set_radar_auto_search turns it off. The profile's name is the account's name. Guided answers without last_job leave the experience section empty. language defaults to the account's language and is one of: en_EN, ru_RU, es_ES, pt_BR, de_DE, fr_FR, it_IT, tr_TR, hi_IN, uk_UA, id_ID, ja_JP. Returns 'already_set_up' if the account already has a profile, 'limit_exceeded' if the plan quota is reached, and 'invalid_payload' when both or neither input is given or the language code is unknown.

Input Schema

NameRequiredDescriptionDefault
inputYes

Output Schema

NameRequiredDescriptionDefault
statusYes'processing' — the generation has started; 'already_processing' — one was already running and this is its task.
task_idYesBackground task id; get_task_status reports the new resume_id when it is done.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / $defs / CreateProfileInput / properties / language / description
      Previous value: -"Locale code of the language the profile is written in, e.g. 'en_EN', 'de_DE'. Defaults to the user's language."New value: +"The language the profile is written in: a locale code ('de_DE'), a language code ('de', 'en_US') or its English name ('German'). Defaults to the user's language."
    • changedInput schema / $defs / GuidedProfileInput / properties / role / description
      Previous value: -"The job the user does or is looking for, in their own words."New value: +"The job the user does now or did last, in their own words — not the one they are looking for."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes far beyond annotations: discloses asynchronous behavior (returns task_id immediately), quota consumption ('one resume generation from the user's plan', free-plan limit), side effects (turns on radar auto-search and runs first scan), return tokens ('already_set_up', 'limit_exceeded', 'invalid_payload'), and edge cases like guided answers without last_job. This is exactly what behavioral transparency should look like.

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 description is a single dense paragraph packed with semicolons and run-on clauses. While most information earns its place, the lack of structure (no bullets, no clear separation of concerns) makes it harder to parse than necessary for an agent.

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 the tool's complexity (async, quota, side effects, error states) and the presence of an output schema, the description is remarkably complete. It covers inputs, defaults, side effects, error semantics, and async follow-up, leaving no critical gap for correct invocation.

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 description coverage is reported as 0%, so the description carries the burden and does so well: it clarifies that exactly one of resume_text or guided is passed, lists the guided fields, notes the effect of missing last_job, and enumerates allowed language codes. It omits field_of_study from the guided list, but otherwise adds substantial semantic value beyond 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?

States a specific verb and resource: 'Create the first resume of an account that has no profile yet', clearly distinguishing it from siblings like create_resume_version or update_resume_section. The scope condition ('no profile yet') is front-loaded and unambiguous.

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?

Explicitly states the precondition (account with no profile), the two mutually exclusive input modes (resume_text vs guided), and that exactly one must be passed. It also notes it works before setup is finished. It does not name alternative tools for related tasks, but the context is clear enough for selection.

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.