Skip to main content
Glama
Sign In

Echo UI

by com.echo-ui
OverviewDiscussionsAdmin

Wear a style

wear_style
Read-only

What a style gives a project: a link that makes the whole Echo site wear its colours, the commands that put it in a project, and, for a project without a terminal, its theme CSS and a DESIGN.md with its rules. One of Echo's styles by name, or the builder's own style.json. A style the slop police stops isn't worn; the answer says what to ask the builder.

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": "wear_style"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoOne of Echo's styles, e.g. "echo".
filesNoInclude the theme CSS and DESIGN.md (the default). False when the builder will run the command in a project, which writes both itself.
styleNoThe builder's own style.json, as a JSON object.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already establish this as a safe read (readOnlyHint true, destructiveHint false, openWorldHint false). The description adds genuine context beyond that: what the payload contains (link, commands, CSS, DESIGN.md) and what happens when a style is rejected by the "slop police", namely that the answer explains what to ask the builder. The failure semantics are still fuzzy because "isn't worn" does not say whether that is an error or a partial result.

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?

It is only two sentences, but they are dense with figurative language ("wear its colours", "slop police stops") that costs the reader interpretation time. The output inventory is front-loaded, which is good, yet the phrasing trades precision for style in a place where precision aids tool selection.

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

Completeness3/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 must carry the return values, and it does enumerate them (link, commands, theme CSS, DESIGN.md). It falls short on edge cases: what happens when neither name nor style is supplied, whether the two are mutually exclusive, and the precise shape of a rejected-style response. Adequate for a three-parameter retrieval tool, but not airtight.

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%, so the baseline would be 3, but the description adds meaning the schema does not: that "name" and "style" are alternative ways of specifying the same thing (a named Echo style or the builder's own style.json). It also frames the files flag as "for a project without a terminal", giving the intent behind the boolean. That is real value over the schema, though mutual exclusivity is only implied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys that the tool returns a style's install link, setup commands, theme CSS and DESIGN.md, which distinguishes it from list_styles or check_style. However, the core action is buried in metaphor ("wear its colours", "the whole Echo site wear its colours"), and there is no clean verb+resource statement of what the tool actually does. An agent can guess this is a retrieve-a-style tool but must parse imagery to get there.

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?

"One of Echo's styles by name, or the builder's own style.json" indicates the two input routes, and "for a project without a terminal" implies a usage condition. What is missing is explicit routing against the siblings: nothing says when to call wear_style versus check_style, fit_styles, or list_styles. Usage is implied rather than stated.

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

All Echo UI 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