Skip to main content
Glama
Unilytics MCP Server

Unilytics MCP Server

Official

kb_search

Read-only

Search a project's Knowledge Base for passages or whole files related to a natural-language query, with filters for collection, folder, skill, tags, and metadata.

Instructions

Search a project's Knowledge Base for passages or whole files related to a query. Use when the user asks what a client's files say about something, or a task needs a client's own files (such as their approved pricing or a template). The query is natural language, in the documents' language.

Filters, combined with AND: collection_id limits the search to one KB; folder to the files in a folder
and every folder below it; skill_id limits results to the files linked to that skill (a skill id from
find_skill or list_skills); tags to files carrying any of those tags (case doesn't matter; at most
20); metadata_filter to documents with those metadata values. folder is a folder's path, a result's
`path` without the file name ("/Templates", "/Templates/Pricing"; case doesn't matter), which matches
that folder in every KB of the project that has one (in one KB with collection_id), or a folder id
(a document's `parent_id` in kb_get_document), which is exactly one folder; a leading "/" makes it a
path. A folder that matches nothing is error "not_found" with reason
FOLDER_NOT_FOUND and `folder` set to it; a skill that doesn't exist or can't be used in this project
is reason SKILL_NOT_FOUND with `skill_id`. A filter that matches more than 2,000 files is refused
(reason FILTER_TOO_BROAD).

granularity "snippet" (the default) returns passages of up to 400 characters: max_results 1 to 20,
default 10. granularity "file" returns one result per file with the file's text in `content`, from
its start: max_results 1 to 10, default 5. `total_chars` is the file's full length and
`content_truncated` is true when `content` isn't the whole file; `content_next_cursor`, when set, is
the `cursor` from which kb_get_document returns the rest of that file. All files' text shares one
result-size budget, best match first, so a lower-ranked file can come with `content` null.

Each result names its file: `document_id`, `name`, `path` (its place in the KB's folders, e.g.
"/Templates/Pricing deck.pdf"), `collection` (the KB's name), `tags`, and `source_url` for a web page.
A long name or passage ends in "…"; a value too large to return (metadata, path, source_url) is null
and the result's `omitted_fields` names it with its size. `results_total` is how many results the
search returned (at most max_results, best first; more files may match); `results` holds the first
`count` of them that fit in one result. `filters` echoes the folder (a path written as "/A/B", or
the folder id), skill_id and tags as applied (normalised; null or [] when not set) and `files`, how
many files they allowed. `exhaustive` is true when every passage the filters allow was compared.

Returns only passages that came close to the query, nearest first, each with its source, `score`
(higher is closer) and `match`: "meaning" when the score reached the result's `min_score`, "words"
when the score is lower but the passage holds every word of the query (how exact names and codes are
found). An empty `results` means nothing in the searched files came close to the query.
Limit: the word rule looks only at the passages nearest in meaning, so a name or code can come back
empty when its passage is far in meaning from the rest of the query, or when the query mixes it with
words the passage doesn't hold. A code matches when written as in the document ("SKU-4417" finds
"SKU-4417", "SKU 4417" may not).

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

Input Schema

NameRequiredDescriptionDefault
tagsNo
queryYes
folderNo
skill_idNo
project_idYes
granularityNosnippet
max_resultsNo
collection_idNo
metadata_filterNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.1.0
    • removedInput schema / properties / config
      Removed value: -{
      -  "default": null,
      -  "title": "config",
      -  "type": "string"
      -}
    • addedInput schema / properties / folder
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Folder"
      +}
    • addedInput schema / properties / granularity
      Added value: +{
      +  "default": "snippet",
      +  "enum": [
      +    "snippet",
      +    "file"
      +  ],
      +  "title": "Granularity",
      +  "type": "string"
      +}
    • changedInput schema / properties / max_results / default
      Previous value: -10New value: +null
    • addedInput schema / properties / skill_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Skill Id"
      +}
    • addedInput schema / properties / tags
      Added value: +{
      +  "default": null,
      +  "items": {
      +    "type": "string"
      +  },
      +  "title": "Tags",
      +  "type": "array"
      +}
  2. First observedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare it as a non-destructive read; the description goes far beyond with named error reasons (FOLDER_NOT_FOUND, SKILL_NOT_FOUND, FILTER_TOO_BROAD), the 2,000-file filter ceiling, per-granularity result caps, the shared result-size budget, and truncation/omission behavior. Scoring semantics ("meaning" vs "words") and the exact-match limitation are disclosed rather than left for the agent to discover.

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-loads purpose and use case, then organizes filters, granularity, result shape and match semantics into distinct paragraphs. It is dense and occasionally convoluted (the sentence explaining leading "/" and multi-KB folder matching packs three rules into one clause), and several return-field explanations could be trimmed. Every paragraph is load-bearing, but the whole is long enough to burden an agent at selection time.

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, nested-object tool with no output schema, the description covers everything an agent needs: filter interaction, defaults and limits, error reasons, result fields (document_id, path, omitted_fields, total_chars, content_next_cursor) and how to continue truncated content. Nothing material is missing for correct invocation or interpretation.

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 description coverage is 0%, so the description carries the entire burden and does: folder accepts a path, a path normalised across KBs, or a folder id from kb_get_document's parent_id, with leading-slash disambiguation; tags are OR-matched, case-insensitive, capped at 20; granularity drives different max_results ranges and defaults (1-20/10 vs 1-10/5). Filters are explicitly AND-combined, which the schema cannot express.

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 a project's Knowledge Base") and immediately names the two return modes, "passages or whole files related to a query". It also sketches the distinguishing territory versus siblings by mentioning find_skill, list_skills and kb_get_document as sources of ids/cursors.

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?

Gives concrete trigger conditions ("when the user asks what a client's files say about something, or a task needs a client's own files") and routes the agent to find_skill/list_skills for skill ids and to kb_get_document for continuation. It also states the tool's own limitation case, where a code or name search can legitimately return empty, which is real when-not-to-trust guidance.

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