Skip to main content
Glama

suggest_search

Convert game events, code names, or Japanese sound words into usable search queries for sound-effect and BGM libraries, helping you locate matching audio.

Instructions

Turn a game event, code name or Japanese sound word (シュッ, 被弾, ぽよん) into searches that work on sound libraries.

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": {
      "text": "<text>"
    },
    "name": "suggest_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the core transformation but says nothing about the return format, whether multiple suggestions are returned, language handling, or any operational constraints—details that matter especially without an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler. The examples are compact and directly illustrate the input domain.

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 one-parameter tool the description covers the input side adequately, but with no output schema and no annotations it should clarify what 'searches' means in practice—a list of query strings, suggested terms with metadata, etc. That gap leaves an agent unsure how to consume the result.

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 0%, so the description must define the lone 'text' parameter. It does so usefully by naming input categories (game event, code name, Japanese sound word) and giving concrete examples, but it leaves ambiguity about whether natural-language phrases, multi-word queries, or non-Japanese onomatopoeia are also acceptable.

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 phrase ('Turn ... into searches') and names the resource domain ('sound libraries'), making clear this is a query-generation tool rather than a direct sound search like sibling search_sounds. It stops short of explicitly naming or contrasting alternatives, but the transformation framing is distinctive enough for an agent to infer the difference.

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 by the listed input types (game event, code name, Japanese sound word), suggesting when to reach for this tool. However, there is no explicit statement about when to use it instead of search_sounds or other siblings, and no exclusions or prerequisites are given.

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