Skip to main content
Glama

Show the stored profile

profile_get

Get the stored profile in JSON format, providing the exact data used for creating resumes, cover letters, and tailoring to jobs.

Instructions

Return the stored profile as JSON, exactly as it will be used by resume_create, cover_letter_create and tailor_to_job.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
variantNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.20.0

TDQS

B3.1/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the return format (JSON) and that the result is the exact representation used by downstream tools, which is useful. It does not mention behavior around the optional variant parameter, missing profiles, or error cases, but for a simple getter this is a moderate gap.

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 a single, front-loaded sentence. It states the core action and format first, then adds the important downstream-use context. Every phrase earns its place and there is no redundant filler.

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

Completeness2/5

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

For a tool with one optional parameter and no output schema, the description should at least mention the variant parameter and its implications. It also does not clarify whether the profile can be empty or what happens if no profile is stored. The downstream-consumer note helps, but the missing parameter guidance leaves the description incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain the 'variant' parameter at all. The schema only says it is an optional string, with no enum or further guidance. This parameter semantics are entirely absent from both schema and description, so an agent cannot know what values are valid or what effect variant has on the returned profile.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return'), identifies the resource ('the stored profile'), and specifies the output format ('as JSON'). It also clarifies that the returned value is the exact canonical profile used by downstream tools like resume_create. It does not explicitly differentiate from profile_set, but the read intent is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool should be used when an agent needs to see the exact profile data that will feed resume, cover letter, or tailoring operations. However, it does not explicitly state when not to use it or mention alternatives such as profile_set for modifying the profile.

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

Install Server

Other Tools