Skip to main content
Glama

Quote a wake word

quote_wake_word
Read-only

Price and rules for a custom wake word (the phrase that wakes the user’s assistant, e.g. "hey omarchy"), trained by Ania for omahey and Ania Player. Checks the phrase: 4–30 letters, 2–4 words (English also accepts ONE word of at least 3 syllables, like "Galadriel"), no digits/punctuation, no third-party assistant names (Alexa, Siri, Cortana, Hey Google). Shows the price (launch promo on the first wake word until 2026-12-30) in the user’s currency. Charges nothing.

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

Input Schema

NameRequiredDescriptionDefault
phraseNoThe wake phrase, as the user would say it.
languageNoThe user's language as a BCP-47 tag (e.g. 'en', 'en-US', 'pt-BR', 'es'). Replies and prices follow it.
wake_languageNoLanguage the wake word is spoken in (what the model listens for): en-US or pt-BR.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and destructiveHint=false, and the description reinforces this with 'Charges nothing'. It adds genuinely useful behavioral context beyond the annotations: the validation ruleset, the launch-promo pricing window (until 2026-12-30), and currency-aware pricing. It stops short of saying what an invalid phrase returns, which would complete the picture.

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?

Front-loaded with the pricing purpose and scope in the first clause, then the validation rules, then the price/currency behavior. Dense but every sentence carries information; the only slight drag is the parenthetical explanation of what a wake word is, which most callers already know.

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?

For a 3-parameter, non-mutating quote tool with no output schema, the description covers purpose, constraints, pricing behavior, and cost. The remaining gap is the failure mode (what the caller learns when a phrase violates the rules), which an agent might otherwise need to guess.

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 is 3, but the description adds constraint knowledge the schema does not carry: 4-30 letters, 2-4 words, the one-word three-syllable English exception, no digits or punctuation, and no third-party assistant names. That materially improves an agent's chance of passing a phrase the tool will accept.

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

Purpose5/5

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

States a specific verb and resource ('Price and rules for a custom wake word'), and immediately clarifies the scope with 'Charges nothing', which separates it from the purchase/creation siblings like create_wake_word and download_wake_word. An agent can tell this is a read-only quote/validation call without opening the schema.

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?

The framing 'Price and rules ... Charges nothing' clearly establishes this as a free pre-check step, but it never explicitly says 'call this before create_wake_word' or names any alternative tool. The usage context is clear enough to act on, yet the routing to siblings is left implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources