Skip to main content
Glama

Kivel

search_tools

Read-onlyIdempotent

Search all 174 catalog tools across 12 categories, plus native MCP tools. Resources and utilities include availability and their MCP entry point. Returns up to 25 matches. Use describe_tool for inputs.

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

Input Schema

NameRequiredDescriptionDefault
queryNoKeywords; leave empty to list the first 25 tools.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real context beyond them: the 25-match result cap, that native MCP tools are included alongside the 174 catalog tools, and that results carry availability and MCP entry point information.

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?

Four short sentences, front-loaded with scope and result cap, then the follow-up routing. The sentence about resources/utilities is slightly awkward but still carries useful information, so no real waste.

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?

There is no output schema, so the description must cover returns, and it does: match count limit plus the availability and entry-point fields. For a single-parameter search tool with full annotation coverage, that is nearly complete; only pagination or truncation behavior beyond 25 is unaddressed.

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 coverage is 100% and the description's 'Returns up to 25 matches' partly overlaps with the schema's empty-query note. With only one optional parameter fully documented by the schema, the description adds little meaning beyond it, so the baseline 3 applies.

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?

States a specific verb and resource ('Search all 174 catalog tools across 12 categories') with scope and a result cap, which is much better than a tautology. It names describe_tool as the follow-up but does not differentiate itself from the sibling list_tools, so sibling separation is only partial.

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?

Routes the agent explicitly to describe_tool for input details and tells it the empty-query behavior (list first 25), which is clear usage context. It stops short of stating when to prefer this over list_tools or when not to search at all.

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.