Skip to main content
Glama
Sign In
Crystalize

Crystalize

by Peyton-C
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

tag_songs

Assign and update song descriptors—energy, style, lyrics, and mood clash—for later search; provided fields replace existing tags, and clear removes them.

Instructions

Write down what songs are like to hear, for every later session to search: energy from 1, a still ballad, to 10, the hardest in the library; style in a few words; what the lyrics are about; and mood_clash when the sound and the words pull opposite ways. Fields given replace those there; clear removes a song's tags.

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": {
      "songs": "<songs>"
    },
    "name": "tag_songs"
  }
}

Input Schema

NameRequiredDescriptionDefault
songsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does disclose important mutation behavior: supplied fields overwrite existing tags and 'clear' removes a song's tags. However, it says nothing about permissions, error/partial-failure behavior, whether the operation is per-library or per-user, or what happens with unknown IDs.

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 purpose is front-loaded, then field semantics, then overwrite/clear behavior. It is a single dense but readable passage with little waste; the phrasing 'what songs are like to hear' is slightly ornate but functional.

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?

For a nested-array mutation tool with no annotations and no output schema, the description covers field meaning and overwrite/clear semantics but omits operational context: batching behavior, error handling, tag scope, and return values. It is adequate but not complete.

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 effectively 0% for the nested fields, and the description compensates well: it explains energy as a 1–10 scale anchored by 'still ballad' and 'hardest in the library', style as a few words, lyrics as subject matter, and mood_clash as sound/words opposition. It does not explain batching many songs in the array or reinforce the required id, but the field meaning gap is largely closed.

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 states a specific write operation and resource: recording perceptual attributes of songs so later sessions can search them. It is distinct from the read-side sibling search_songs, though it never names the sibling. The verb 'write down' is unusual but the intent is clear.

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

Usage Guidelines2/5

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

It hints that tags serve later search, but never says when to tag versus when to search, whether tagging happens after search_songs, or what preconditions exist. The only usage-like content ('Fields given replace those there; clear removes a song's tags') describes update semantics, not tool selection.

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

Deploy Server

Other Tools