Skip to main content
Glama
Sign In
sinequa-docs

sinequa-docs

by hebus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Search the library docs

docs_search

Search the published documentation of the atomic, atomic-angular and galactik libraries to find the best matching sections with URLs and paths. Use it to locate docs before reading a page.

Instructions

Full-text search in the published documentation of atomic (https://hebus.github.io/atomic-docs/docs/), atomic-angular (https://hebus.github.io/atomic-angular-docs/docs/atomic-angular/), galactik (https://hebus.github.io/atomic-angular-docs/docs/galactik/). Returns the best sections (two per page at most) with their URL and path; read one with docs_read.

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

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYesWords or identifiers, e.g. 'suggest queries autocomplete' or 'createAtomicClient'
libraryNoRestrict to one library; all by default

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.1/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden and does a fair job: it discloses the corpus scope (published docs only, three named sites) and the result shape (best sections, max two per page, with URL and path). It omits ranking behavior, pagination/truncation semantics beyond 'two per page,' and any auth or rate-limit context.

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?

Two dense sentences with the capability and corpus front-loaded, followed by return shape and the handoff to docs_read. The three inline URLs add length but earn their place by pinning down exactly which documentation sets are searchable.

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?

With no output schema, the description correctly compensates by describing what comes back (sections with URL and path) and the per-page cap. The only meaningful omission is what limit does, which an agent would have to infer.

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 67%; the query parameter already documents its expected form with examples, and library is an enum with its own description that the description merely restates. The limit parameter is documented in neither schema nor description, leaving a real gap.

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 — 'full-text search in the published documentation' — and enumerates exactly which three libraries are covered, with their doc URLs. This clearly separates it from docs_read, which retrieves a single section.

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?

Explicitly routes the agent forward: results come back as sections 'read one with docs_read.' It does not state when to prefer docs_index or when search is the wrong choice (e.g. browsing an entire library), so it falls short of full when/when-not 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