MangroveAI

kb_search

Read-onlyIdempotent

Locate KB articles or source sections using short topic keywords. Use when the user asks to find written material, or an explanation is missing a specific fact that requires a source passage. For general definitions, explanations, comparisons and combination/caution questions, start with query_knowledge op=ask instead. This returns snippets and section anchors, not full articles. All query terms must match; do not send a full question or split it into speculative keyword searches. A tag restricts the category and disables synonym expansion. If the snippets or attached graph evidence answer the request, answer directly. Read one returned section with kb_get_document only if a required fact is still missing. Do not automatically search again or read every result.

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": {
      "q": "<q>"
    },
    "name": "kb_search"
  }
}

Input Schema

Name	Required	Description
`q`	Yes	The search text, in ordinary words.
`tag`	No	Restrict to one tag category; disables synonym expansion.
`tags`	No	Restrict to any of these tag categories; cannot combine with tag.
`limit`	No	Maximum results.
`expand`	No	Whether to expand synonyms; ignored when tags are set.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark this read-only, idempotent, and closed-world, and the description goes well past them: it discloses the return shape ('snippets and section anchors, not full articles'), the strict AND matching semantics, and the side effect that a tag disables synonym expansion. The guidance against speculative query splitting and automatic re-searching is behavioral detail not derivable from any structured field.

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 purpose and the query_knowledge fork before the mechanics, and every sentence is directive rather than filler. It runs long (eight sentences) and the tag/synonym note duplicates the schema, but trimming further would lose actionable routing guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and five parameters, the description covers what is returned (snippets and section anchors, not full articles), how to construct the query, and the escalation path to kb_get_document. Nothing an agent needs to call this correctly and stop at the right moment is missing.

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, and the description adds real query-construction semantics beyond it: use short topic keywords, all terms must match, and don't send a full question or split it into speculative keyword searches. The tag/expand interaction is restated from the schema rather than added, which keeps it from a 5.

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?

Opens with a specific verb and resource ('Locate KB articles or source sections') plus a scoping constraint ('using short topic keywords'). It explicitly distinguishes itself from kb_get_document (read a section) and query_knowledge op=ask (general Q&A), so an agent can pick it without opening sibling schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States both the trigger conditions ('user asks to find written material', 'a required fact is still missing') and the exclusions ('For general definitions, explanations, comparisons... start with query_knowledge op=ask instead'). It also prescribes the follow-up ladder: answer directly if snippets suffice, kb_get_document for exactly one section, and explicitly forbids re-searching or reading every result.

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

All MangroveAI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.