ossian-mcp

Ask the documents

ask_documents

Read-onlyIdempotent

Answer questions from your organisation's own documents with cited passages. Reports when the corpus lacks support instead of guessing, so 'not found' is a real answer.

Instructions

Answer a question from the organisation's own documents, with citations. Returns the exact passages the answer was written from. Use this for anything about internal policy, runbooks, handbooks, contracts or product documentation — anything the user's organisation wrote down. If nothing in the corpus supports an answer this reports that rather than guessing: treat 'not found' as the real answer and say so, do not fall back on general knowledge and present it as the organisation's policy.

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": {
      "question": "<question>"
    },
    "name": "ask_documents"
  }
}

Input Schema

Name	Required	Description	Default
`question`	Yes	The question, in full. Prefer the user's own wording.
`namespace`	No	Narrow to one slice of the corpus, e.g. 'runbooks'. Omit to search everything.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.2Sep 12, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedv0.1.1Sep 7, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely new behavior: exact passages are returned and a 'not found' outcome is reported instead of a hallucinated answer, which materially changes how the agent should present results.

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?

The core action and citation behavior are front-loaded and every sentence carries information. The final sentence is slightly long with two imperatives stacked, but nothing is 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?

With no output schema, the description still covers what is returned (exact source passages) and the failure mode ('not found'), which is the information an agent most needs in order to relay results honestly.

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 description coverage is 100%, so both 'question' and 'namespace' are fully documented in the schema. The description adds no parameter guidance (e.g. how to phrase the question or when to narrow with namespace), so this stays at the baseline.

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 ('Answer a question from the organisation's own documents'), plus the output form ('with citations'). The scoping phrase 'anything the user's organisation wrote down' separates it from the sibling 'recall', which an agent would otherwise confuse with a document-QA tool.

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?

Gives concrete use-case categories (internal policy, runbooks, handbooks, contracts, product documentation) and an implicit exclusion (don't use general knowledge). It never names the sibling tools (list_documents, recall, list_namespaces) as alternatives, so the routing is contextual rather than explicit.

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

Deploy Server