Skip to main content
Glama
Sign In
Otohiroi MCP

Otohiroi MCP

by koyomivanp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search_sounds

Find sound effects and background music by English keywords across online indexes and added packs, filtered by license, duration, loop, and natural-sound needs.

Instructions

Search sound effects and BGM by English keywords across online indexes and packs added with add_pack.

license: cc0 = no conditions (default); commercial = also CC BY / BY-SA, which need credit; any = everything, including non-commercial. natural_only leaves out sounds described as beeps, synths or 8-bit. Results are short; use audition_sounds to let the user listen.

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": {
      "query": "<query>"
    },
    "name": "search_sounds"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNo
pageNo
limitNo
queryYes
sourceNo
licenseNocc0
loop_onlyNo
max_secondsNo
min_secondsNo
alternativesNo
natural_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/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; it does disclose filter semantics (license tiers and their credit obligations, natural_only excluding beeps/synths/8-bit) and that results are short. It says nothing about pagination behavior, per-source availability, or result metadata, which matters for an 11-parameter search 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?

Front-loaded with the core action, followed by the license and natural_only semantics and a routing hint. The line breaks are functional; the only slack is that the license clause packs three tiers into one dense sentence.

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 an 11-parameter tool with no annotations and no output schema, the description covers the highest-risk filtering semantics but omits paging, duration ranges, loop_only, alternatives, and success/failure conditions. It is adequate to start a call, not to call it optimally.

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 compensate for all 11 parameters. It explains license, natural_only, and query well and hints at kind and source, but leaves page, limit, loop_only, min_seconds, max_seconds, alternatives, and the source enum values completely undefined.

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 ('Search sound effects and BGM') plus the searchable scope: online indexes and local packs added via add_pack. An agent can tell this apart from list_packs or audition_sounds 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?

Names the follow-up alternative explicitly ('Results are short; use audition_sounds to let the user listen') and implies a prerequisite for local content (packs must be added first). It does not address when to prefer other retrieval siblings, so it stops just short of a full when/when-not statement.

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