Skip to main content
Glama

Your filmmaker profile

get_filmmaker_profile
Read-onlyIdempotent

The user's filmmaker profile as the Profile page shows it: username (the public handle) and why it cannot go public yet, display name, bio, location, roles, website and social links, whether the profile is public and its public link, plus how many credits from other filmmakers await an answer. The avatar is managed in the Profile page.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_filmmaker_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that by describing non-obvious return contents (why the username cannot go public, the count of pending credits, the public link), but omits any note on auth scope or freshness.

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-loads the resource (the user's filmmaker profile) and packs the return fields into a single dense sentence with no filler. It is slightly long and run-on, but every enumerated field earns its place, and the closing note that the avatar lives in the Profile page prevents a likely wrong assumption.

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

Completeness4/5

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

With no output schema and no parameters, the description carries the burden of describing returns and does so by enumerating the fields an agent can expect. It is close to complete for a simple read tool, though it does not explain the relationship to the get_profile/get_account siblings.

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. There is nothing for the description to clarify on parameter semantics, and it correctly does not invent any.

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 resource (the user's filmmaker profile) and enumerates its contents in detail, so an agent knows exactly what it retrieves. However, it never distinguishes itself from the closely-named sibling get_profile or get_account, leaving ambiguity about which profile tool to pick.

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 explicit when-to-use guidance, no exclusions, and no mention of alternatives such as get_profile or get_account. The only usage signal is implicit in the field list, which is minimal guidance at best.

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.

Resources