Skip to main content
Glama
Sign In

Moltline Studio

by com.moltlinestudio
OverviewDiscussionsAdmin

Get Full Persona

get_full_persona
Read-onlyIdempotent

Load a product's complete persona definition. PREMIUM (license).

Typical input {"slug": "inbox-commander"} returns {"slug": ..., "persona": ""}.

Returns the persona text alone, with no skill bodies. Use when the caller needs the product's voice and operating rules only. Not when skills are also wanted - get_full_product returns persona and every skill in one call. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "unknown slug ''"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

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": {
      "slug": "<slug>"
    },
    "name": "get_full_persona"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesProduct slug exactly as returned by search_catalog.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent and non-destructive, but the description adds material context beyond them: the PREMIUM license requirement, and a clear error contract stating it never raises a protocol error and instead returns an {'error': ...} object with a fix hint. It also tells the caller it is always safe to retry after correcting input, which is actionable behavior not present in the annotations.

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 purpose, then return shape, then usage routing, then error contract — a sensible order with little waste. Minor deductions for the clipped 'PREMIUM (license).' fragment and for restating read-only/idempotent which the annotations already carry.

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?

Covers everything needed for a one-parameter read tool: what it returns, what it omits, the license gate, the alternative tool, and the exact error semantics including retry safety. With an output schema present, return values need no further explanation, so nothing material is missing.

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?

Schema coverage is 100% and the slug property already points to search_catalog as the source. The description adds a concrete example input ({'slug': 'inbox-commander'}) showing the slug shape, plus the error form for an unknown slug, which slightly extends the schema's meaning. The gain is real but modest, so it sits just above baseline.

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 ('Load a product's complete persona definition') and immediately scopes the output ('Returns the persona text alone, with no skill bodies'). It explicitly distinguishes itself from get_full_product, which returns persona plus every skill, so an agent can choose without opening either schema.

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

Usage Guidelines5/5

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

Gives both the positive case ('Use when the caller needs the product's voice and operating rules only') and the negative case ('Not when skills are also wanted'), naming get_full_product as the alternative with the reason. Nothing is left to inference about when to route elsewhere.

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

All Moltline Studio toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources