Skip to main content
Glama
Sign In

framesail

by com.framesail
OverviewDiscussions(1)Admin

Read the channel style

style_read
Read-onlyIdempotent

get: the channel style: its references, its fields (art_style, narrative_style, director_style, text_style, any added; script_prompt on request), the summary analysis wrote for each, and templates, the character and environment template images (null: not rendered; a URL: it exists, so view_image it rather than render it again). inputs_stale: the references changed since the last analysis (offer style_generate action=analyze). templates_stale: the art style or its image references changed since the templates were rendered (offer to render them again).

presets: the preset catalog, one list per axis (art_style, narrative_style, director_style), with labels, descriptions and, for art presets, preview images. Let the user pick one per axis.

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": {
      "action": "<action>"
    },
    "name": "style_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesget: the channel style (channel_id or project_id); presets: the preset catalog
channel_idNoget: the channel (or pass project_id)
project_idNoProject id
include_script_promptNoget: include the long script_prompt

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds a lot beyond them: which fields come back, that script_prompt is long and only returned on request, that template values are null vs URL with a specific next action for each case, and what the two staleness flags mean and imply. This is exactly the behavioral context an agent needs post-call.

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?

It is front-loaded per action and every clause carries information — no filler. The run-on, line-broken layout makes it denser than necessary, and a bulleted structure for get/staleness/presets would scan better, but nothing is wasted.

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?

There is no output schema, so the description carries the full burden of describing returns, and it does so for both actions: field list, analyses, templates null/URL states, staleness flags, and the per-axis preset catalog. Only minor gaps remain, such as error/empty behavior when the channel has no style yet or when neither id is passed.

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 description coverage is 100%, so the schema already documents action, channel_id, project_id, and include_script_prompt. The description reinforces that channel_id and project_id are alternatives for 'get' and that script_prompt is long and opt-in, but adds no enum semantics or edge-case behavior (e.g. what happens if neither id is supplied). Baseline 3 is appropriate.

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 concrete resource (the channel style) and enumerates what each of the two actions returns — references, style fields, per-field summaries, template images, and the preset catalog. It also distinguishes itself from the write path by pointing at style_generate action=analyze. The dense formatting slightly blurs the top-level read purpose, but an agent can tell it apart from style_edit and style_generate.

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?

It gives explicit conditional guidance: when inputs_stale, offer style_generate action=analyze; when templates_stale, offer to render again; and if a template is a URL, view_image it rather than re-rendering. That is real when-to-use steering. It stops short of saying when to call style_read at all versus style_edit, but the read/write split is implied.

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

All framesail toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources