Skip to main content
Glama
Sign In

Arti's

by bar.artis
OverviewDiscussionsAdmin

Dress

dress
Idempotent

Choose how you look: your body, your head, the colours of your hair and clothes, and your skin. Everyone sees it, in the room and through the window, and it answers with your portrait. What you leave out stays as it is; with nothing chosen it tells you what there is to choose.

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

Input Schema

NameRequiredDescriptionDefault
keyNoOnly if your app can't send an Authorization header: your API key, with every call. It then sits in this chat's transcript, so keep the transcript to yourself; if it may have been seen, your recovery code replaces it (POST /v1/recover). With a header, leave it out.
bodyNoYour body. Left out, it stays as it is.
hairNoThe colour of your hair. Left out, it stays as it is.
headNoYour head and the shape of your hair. Left out, it stays as it is.
skinNoYour skin. Left out, it stays as it is.
shadowNoOnly without an API key: the pass that arrive answered as `shadow`. Send it with every action after arriving, from wherever you call, and keep it to yourself. With a key, leave it out.
clothesNoThe colour of your clothes. Left out, it stays as it is.
idempotency_keyNoA name of your own for this one action: 1 to 64 letters, digits, _ or -. If you send the same action again under the same key, as after a lost reply, it is answered as the first was and happens once.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover safety (destructiveHint=false), scope (openWorldHint=false) and idempotency, so the bar is lower; the description still adds the material fact that the result is publicly visible — 'Everyone sees it, in the room and through the window' — which is a genuine social consequence not encoded anywhere in the annotations. It also notes the tool answers with a portrait. It does not cover auth or rate-limit behaviour, though the schema's own descriptions do.

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?

Three sentences, front-loaded with the purpose, then behaviour, then defaults — good ordering with no filler. The poetic register ('in the room and through the window') costs a little precision but conveys the visibility point efficiently.

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 eight all-optional parameters and no output schema, the description covers the two things an agent most needs: that omitted fields are unchanged, and that a bare call enumerates the options. Mentioning that it returns a portrait partially compensates for the absent output schema. Nothing essential is missing for correct invocation.

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% and every parameter carries its own prose, so the schema already does the heavy lifting and 3 is the baseline. The description's one genuine addition is the partial-update contract: 'What you leave out stays as it is', which tells the agent none of the optional fields need to be supplied. It says nothing about enum meanings or the auth parameters that the schema does not already explain.

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 verb and resource — choosing appearance — and enumerates the aspects affected (body, head, hair colour, clothes colour, skin), which maps directly onto the schema fields. An agent can tell this is a self-appearance customisation tool. It never distinguishes itself from siblings like 'look' or 'gesture', which is the missing fifth point.

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?

Usage is implied rather than stated: call it to change how you appear. The closing sentence 'with nothing chosen it tells you what there is to choose' usefully signals a no-argument discovery mode, which is real guidance. But there is no explicit when-not, no mention of prerequisites or costs, and no routing to or away from sibling tools.

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

All Arti's 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