@jam-jam/convert-mcp

Get a public profile card

jj_get_profile

Fetches a Jam Jam account's profile card by public @handle, showing display name, bio, avatar, visibility, follower/following counts, and the caller's relation to that account.

Instructions

Returns the profile card of a Jam Jam account designated by its public @handle, seen from the calling account: display name, bio, avatar, visibility (public/private), follower and following counts, and relation (none / following / follower / mutual / requested / self). A PRIVATE account the caller does not follow returns a closed card without bio or counts. An unknown handle returns not-found. Jam Jam is a host: this never ranks or recommends anyone, and never exposes somebody else's audience figures.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "handle": "<handle>"
    },
    "name": "jj_get_profile"
  }
}

Input Schema

Name	Required	Description	Default
`handle`	Yes	Public username of the account, with or without the leading "@".

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.2Nov 13, 2026

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 full burden, and it discloses the important conditional behaviors: a private account the caller doesn't follow returns a closed card without bio or counts, and an unknown handle returns not-found. It also states the scoping guarantee (never ranks, never exposes third-party audience figures). Missing are auth/caller-permission requirements and any error details beyond not-found.

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?

Front-loaded with the return payload, then edge cases (private/unknown), then scope disclaimers – a logical order for an agent reading it once. Four dense sentences with little waste; the final policy sentence is the only one a reader might trim, though it does aid routing.

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?

For a one-parameter read tool with no output schema, the description compensates by enumerating the returned fields and the enum of `relation` values, and by describing degenerate cases (closed private card, not-found). Nothing an agent needs in order to call this correctly is absent.

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

Parameters3/5

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

Schema coverage is 100% and the single parameter is fully documented there, including that the leading "@" is optional, so the baseline is 3. The description's "designated by its public @handle" restates the schema rather than adding format or edge-case meaning.

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 ("Returns the profile card of a Jam Jam account designated by its public @handle") and enumerates exactly what comes back: display name, bio, avatar, visibility, follower/following counts, and relation. The closing sentence about never ranking or recommending and never exposing others' audience figures cleanly separates it from recommendation/analytics-style siblings and from the profile listing tools.

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 lookup intent is implied by the single @handle parameter, but there is no explicit when-to-use statement, no named alternative, and no exclusion such as "use jj_list_followers instead if you need the follower list." Usage must be inferred from the purpose sentence.

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