Skip to main content
Glama
SVerITG

Metis

by SVerITG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Metis — Get User Profile

get_user_profile

Retrieve the user's identity, interests, communication style, and model preference at the start of a personalized run so topics, briefings, and responses match their needs.

Instructions

Return the user's identity, interests, style, and model preference.

Call this at the start of any personalised run to understand the user's
topics, news signals, and communication preferences.

Returns JSON with:
- display_name: user's display name (set via /metis_config)
- role: professional role (e.g. "Senior researcher")
- news_interests: what they want to know is HAPPENING — drives the News
  surface and the briefings. May include things outside their work.
- library_interests: what they want a scientific BACKGROUND on — drives
  literature collection and the knowledge layer. Also may sit outside their
  current projects.
- has_declared_interests: False if neither list is set. A new user may have
  no projects, articles or interests yet; that is a normal starting point,
  and `start_interest_interview()` is how to fill it in.
- interests: DEPRECATED — the union of both lists, kept for older callers
- news_topics: DEPRECATED — mirrors news_interests
- active_model: current default model slug (haiku / sonnet / opus)
- style: dict of communication preferences:
    - response_length: "concise" | "moderate" | "detailed"
    - feedback_style: "gentle" | "direct" | "challenging"
    - challenge_level: "supportive" | "balanced" | "rigorous"
    - warmth: "warm" | "neutral" | "formal" (default: "warm")
    - detail_level: "brief" | "balanced" | "thorough" (default: "balanced")
    - routing_verbosity: "silent" | "natural" | "detailed" (default: "natural")

Usage pattern:
  profile = json.loads((await get_user_profile())[0].text)
  interests = profile['interests']
  style = profile['style']  # → {"response_length": "concise", "warmth": "warm", ...}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the disclosure burden and does so well: it documents field-level semantics, marks deprecated fields (interests, news_topics) so callers aren't misled, and states defaults for warmth, detail_level and routing_verbosity. It omits anything about permissions, caching, or cost, but for a zero-argument read this is close to sufficient.

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?

Front-loaded and organized, but it is long for a nullary tool and much of the return-field enumeration duplicates the existing output schema — including the full enum lists and defaults. The end-of-description code snippet adds little for a call with no arguments, so not every line earns its place.

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 zero parameters, an output schema, and no annotations, the description covers everything an agent needs: when to call it, what the fields mean operationally (news_interests drives News, library_interests drives literature), how to detect an unconfigured user, and how to remedy that.

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 the baseline is 4. The description does not waste effort inventing parameter semantics and instead spends its budget on return-value semantics and a concrete call pattern.

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?

States a specific verb and resource ('Return the user's identity, interests, style, and model preference') and enumerates the exact contents, so an agent knows precisely what it gets. It does not, however, distinguish itself from close siblings like get_user_topics or get_user_config, which overlap in subject matter.

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?

Gives a clear triggering condition ('Call this at the start of any personalised run') and names the follow-up tool start_interest_interview() for the empty-profile case, which is genuinely actionable guidance. There is no explicit when-not guidance relative to get_user_config or get_user_topics.

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

Deploy Server

Other Tools