Taste Profile

Describe the shared style

describe_style

Read-onlyIdempotent

Describe the shared style. Use this when the user asks what their references have in common or wants rules to design by, such as "what is my taste?". Pass the profile_key and optionally ref_ids to use only some references. Returns concrete rules for layout, type, texture and hierarchy, a palette of hex colors with how many references use each, and the most common style tags. The rules are suggestions to confirm with the user, then keep with save_profile.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

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

Input Schema

Name	Required	Description	Default
`ref_ids`	No	Only use these references; leave out to use all of them.
`profile_key`	Yes	The profile_key that add_refs returned. Keep it: it is the only way back to this profile and it is not recoverable.

Output Schema

Name	Required	Description
`tags`	Yes
`type`	Yes
`as_of`	Yes	UTC date of this answer.
`layout`	Yes
`notice`	Yes
`source`	Yes
`status`	Yes
`palette`	Yes
`texture`	Yes
`based_on`	Yes
`hierarchy`	Yes
`refs_total`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

addedInput schema / examples

Added value: +[
+  {
+    "profile_key": "tp_604a48a85c9a4da5a2a15ba7b4198f1b"
+  }
+]

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare the tool is read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context beyond that: it summarizes what is returned and notes the rules are 'suggestions to confirm with the user, then keep with save_profile,' which tells the agent not to treat output as final. It does not cover auth or rate limits, but those are less critical for a read-only, local tool.

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?

The description is front-loaded with purpose and usage, then moves through parameters, return content, and next action. It is generally efficient, but the opening sentence 'Describe the shared style' essentially repeats the tool title before adding value, costing a small amount of conciseness.

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?

Although an output schema exists, the description still gives a helpful summary of the return surface (rules, palette, tags) and clarifies the intended follow-up with save_profile. Combined with annotations covering safety and a 100% described schema, an agent has everything needed to call this tool correctly and interpret its role.

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 both parameters are already well documented in the schema. The description restates that profile_key is required and ref_ids optionally limits the references, but adds no syntax, format, or behavioral detail beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 uses a specific verb (Describe) and resource (shared style), and enumerates the concrete outputs: rules for layout, type, texture, hierarchy, a hex palette, and common tags. It does not explicitly distinguish itself from siblings like get_profile or search_refs, but the purpose is otherwise clear and concrete.

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 a clear when-to-use cue ('when the user asks what their references have in common or wants rules to design by') and includes an example ('what is my taste?'). It also names save_profile as the follow-up action, though it stops short of stating when not to use this tool or explicitly comparing it with alternatives.

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

All Taste Profile tools Inspect

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.