librarian

Overview Schema Source Related Servers Discussions Admin

search

Find relevant technical answers, docs, and forum posts by submitting a specific question, error text, product, and version to hybrid keyword-semantic retrieval with quality and version ranking.

Instructions

Hybrid keyword + semantic search over the local index, reranked for quality and version.

Write one specific question or symptom per call; include error text and product names. If the user's question spans several distinct topics, make one call per topic. Good: 'webgisdr backup fails unable to generate token 11.3'; 'federate ArcGIS Server with Portal certificate error'; 'Data Store upgrade 11.5 to 12.1 validation fails'. Bad: 'portal'; 'upgrade, federation, SSL and backups in 11.x'. If two or three rephrased searches find nothing relevant, stop and say so rather than searching indefinitely.

Returns compact results: chunk_id (stable, citable), date, versions, source/kind, flags (official, accepted, top_voted, vendor_staff, expert), score, approximate tokens, URL, snippet.

Args: query: the question or symptom, e.g. an error message plus the component involved. limit: max results (1-50). version: the user's product version, e.g. "11.3" or "10.9.1" ("11" = any 11.x). Pass it whenever known: matching versions rank higher. version_mode: "boost" (default) ranks matching versions higher; "filter" keeps only them (drops the many posts that never state a version, so use sparingly). date_from / date_to: ISO dates (YYYY-MM-DD) bounding the post date. source_type: e.g. "docs", "kb", "bug", "forum" (see outline). source: a source id from outline. explain: include the per-signal scoring breakdown.

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

Input Schema

Name	Required	Default
`limit`	No
`query`	Yes
`source`	No
`date_to`	No
`explain`	No
`version`	No
`date_from`	No
`source_type`	No
`version_mode`	No	boost

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 5, 2026

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the full load and does most of it: it explains ranking signals, the boost-vs-filter default and its tradeoff, the stopping condition, and what the result rows contain (stable citable chunk_id, date, versions, flags, score, tokens, URL, snippet). It omits the safety/read-only framing, index freshness or coverage limits, and what an empty result versus a filtered-out result looks like.

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 one-line purpose, then query-writing guidance, then args. The good/bad example block is on the long side but each example teaches a distinct lesson (error text, product names, one topic per call), so little is truly wasted.

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?

For a 9-parameter, un-annotated search tool with an output schema, the description covers purpose, query construction, version handling, filtering tradeoffs, backup/exit behavior, and result shape. An agent has everything needed to invoke it correctly on the first attempt.

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 compensates for nearly every parameter: version format with the '11' = any 11.x shorthand and the instruction to pass it whenever known, version_mode semantics and defaults, ISO date format for date_from/date_to, source_type examples with a pointer to outline, source id provenance, limit bounds (1-50), and what explain adds. This adds meaning well beyond the bare schema types.

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 plus the mechanism and ranking model: 'Hybrid keyword + semantic search over the local index, reranked for quality and version.' This separates it from sibling tools like fetch (retrieve a known doc) and outline (enumerate sources), which the description also references as the place to find source ids.

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?

Explicit when-to-use guidance: one specific question or symptom per call, one call per distinct topic, with concrete good/bad query examples. It also gives an explicit stopping rule ('if two or three rephrased searches find nothing relevant, stop') and tells the agent to use version_mode='filter' sparingly because it drops undated posts.

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

Deploy Server