Skip to main content
Glama
ZornZL
by ZornZL

kb_search

Searches the full wiki knowledge base with title-weighted full-text matching to find relevant pages, returning titles, paths, snippets, node tokens, and links; set result count 1–20.

Instructions

在全库检索(标题权重更高),返回命中页面的标题、路径、片段、node_token 与链接。

Args: query: 检索词,用你会写进标题的说法,不要用编号或缩写。 k: 返回条数,1–20,默认 8。

Input Schema

NameRequiredDescriptionDefault
kNo
queryYes

Output Schema

NameRequiredDescriptionDefault
resultYes

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 at all, the description carries the full burden, and it does disclose one genuine behavioral trait — title-weighted ranking across the entire library. It says nothing about permissions/auth, rate limits, result ordering/pagination beyond k, or whether body text is searched alongside titles.

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?

Two tight components: a one-sentence capability line with the ranking caveat front-loaded, followed by a compact Args block. No filler, no restatement of the schema's type information.

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?

An output schema exists, so listing return fields is redundant but harmless. For a zero-annotation, zero-schema-coverage tool, the missing pieces are the follow-up workflow (what to do with node_token, i.e. kb_read) and any authentication or result-limit behavior — the definition is workable but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description fully compensates: it gives query formulation rules ('write it the way you'd write a title, no IDs or abbreviations') and states the k bound of 1–20 which the schema does not express at all (schema only shows type integer and default 8). An agent can call this correctly from the description alone.

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 (检索/search) and resource (全库, the whole knowledge base), plus the scope note that title matches are weighted higher and what each hit contains. It doesn't name kb_read or any sibling explicitly, but '全库检索' versus reading a single page is distinguishable from the sibling names alone.

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 only implied: a global search tool that returns node_token naturally precedes kb_read, but the description never says so nor names any alternative or when-not condition. The query-phrasing hint ('用你会写进标题的说法') is the only actionable guidance about how to use it well.

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