Skip to main content
Glama

get_profile

Read-only

Retrieve a user's coding-platform standing—level, solved and unsolved counts per tag, and recent submissions—to track progress.

Instructions

The user's standing on one platform: level, solved and unsolved counts per tag, and their most recent submissions.

Input Schema

NameRequiredDescriptionDefault
handleYes
platformYes
recent_submissionsNo

Output Schema

NameRequiredDescriptionDefault
handleYes
platformYes
solved_idsNo
limitationsNo
submissionsNo
level_summaryNo
solved_by_tagNo
unsolved_attempts_by_tagNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile and external-dependency nature are covered. The description adds useful scope information (what data categories are returned) but says nothing about failure behavior for unknown handles/platforms or responsiveness for large profiles.

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?

A single front-loaded sentence that leads with the resource and then lists contents in a natural reading order. Efficient with no filler, though 'standing' is slightly vague phrasing.

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

Completeness3/5

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

An output schema exists, so the description need not explain return shape. However, for a 3-parameter tool with zero schema coverage, the missing handle format and platform enumeration leave a real gap that a single clause about list_platforms would have closed.

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

Parameters2/5

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

Schema description coverage is 0% across 3 parameters, so the description must compensate, and it only partially does: 'one platform' hints at the platform argument and 'most recent submissions' hints at recent_submissions. The handle parameter and the acceptable platform values (no enum present) remain entirely undocumented.

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 names the resource (a user's profile on one platform) and enumerates the returned content: level, per-tag solved/unsolved counts, and recent submissions. That distinguishes it from siblings like search_problems or list_mistakes, though it never states an explicit retrieval verb.

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

Usage Guidelines2/5

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

There is no guidance on when to call this versus alternatives, no mention of list_platforms as the way to discover valid platform values, and no note that both platform and handle are required inputs. The agent must infer usage entirely from the description's content list.

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