What can you do with this server?

It is an MCP server that lets you ask questions about JMP 19.1 documentation in your own words and get JMP-specific answers with menu paths, steps, and citations. * search_jmp_docs — Natural-language search over all JMP docs, with JMP-name translation (e.g. “random forest” → Bootstrap Forest), optional book filtering, and intent hints. * whats_this — Explain an on-screen JMP UI element using JMP's official context-help map. * find_menu_path — Find authoritative menu locations for JMP features/tasks. * get_jmp_page — Retrieve the full text and figures of a specific documentation page. * find_example — Locate worked examples, optionally filtered by sample data table. * find_jmp_figures — Search documentation screenshots/captions by what the figure should show. * list_jmp_books and browse_jmp_toc — Explore the structure of the 20 documentation books and their tables of contents. * jmp_fetch_live — Bypass the local index and fetch a page directly from jmp.com. * index_stats — Report what is indexed and when the index was built. * Designed for local, private use with a local LLM; tools return structured JSON with source URLs for use by agents.

How do I use jmp-docs-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jmp-docs-mcp How do I run a random forest in JMP?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

jmp-docs-mcp

by nepseli

Overview Schema Source Related Servers Discussions Admin

Python

Local

jmp-docs-mcp

Ask JMP's documentation a question in your own words. Get the menu path, the steps, and a link to the page it came from.

An MCP server + chat app over all 3,864 pages of the JMP 19.1 documentation. Runs entirely on your own machine — no API keys, no per-question cost, nothing leaves your laptop.

License: MIT Python 3.11+ MCP Local Tests

The chat app

The problem

JMP is statistical software used heavily in semiconductor fabs, pharma, chemicals and manufacturing — for design of experiments, SPC, capability studies, reliability analysis and data exploration.

It also has 3,864 pages of documentation across 20 books, and finding anything in it is harder than it should be:

JMP is GUI-driven, so the answer you need is usually a place — a menu path and a sequence of clicks — not a code snippet.
Many users are occasional users. An engineer who runs a designed experiment twice a year knows the statistics cold but can't remember where JMP keeps the feature.
JMP names things its own way. This is the real problem.

That last point isn't a guess. Measured against the actual corpus:

The page that answers the question	What a user types	Times that phrase appears on that page
`bootstrap-forest.shtml`	"random forest"	0
`boosted-tree.shtml`	"gradient boosting"	0
`oneway-analysis.shtml`	"ANOVA"	2

Ask a normal RAG system "how do I run a random forest in JMP?" and it finds nothing useful. There's no keyword overlap, and embeddings are unreliable at bridging product names. The answer is right there in the docs — the words just don't match.

Closing that gap is what this project is.

Related MCP server: anydocs

What you get

Ask in your words. Get JMP's answer, with the menu path first.

You: How do I run a random forest in JMP?
Assistant: Analyze > Predictive Modeling > Bootstrap Forest (JMP calls this a Bootstrap Forest.)
Open your data table.
Select Analyze > Predictive Modeling > Bootstrap Forest.
Select the response variable and click Y, Response.
Select the predictor variables and click X, Factor.
Set the Validation Portion (e.g. 0.25).
Click OK.
Sources: Bootstrap Forest · Launch the Bootstrap Forest Platform

Answers include the menu path, the sample data table to use, and the real figures from the documentation:

Menu chips and inline figures

And when the docs genuinely don't cover something, it says so instead of inventing a menu:

You: How do I train a YOLO object detection model in JMP?
Assistant: The provided documentation excerpts do not cover training a YOLO object detection model in JMP. JMP does not support deep learning frameworks for object detection…

How it works

  your question
       │
       ├─ 1. translate    "random forest"  →  "Bootstrap Forest"
       ├─ 2. classify     how-to? interpret? scripting?
       ├─ 3. retrieve     semantic search (FAISS) + keyword search (BM25)
       ├─ 4. rank         prefer the page type that matches your intent
       └─ 5. answer       local LLM, citations, figures

Four pieces do the work, each built from something JMP already publishes:

1. Vocabulary bridge — 134 entries, 478 user terms. random forest → Bootstrap Forest, pivot table → Tabulate, VLOOKUP → Join, Cpk → Process Capability. Applied twice: the synonyms are baked into the keyword index so search can match words the page never contains, and JMP's terms are injected into the query. Worth +13.9 points of recall.

2. UI element map — 3,475 entries. JMP ships a hidden context-help map linking on-screen element names to exact doc sections. Parsed out and exposed as the whats_this tool.

3. Menu reference — 433 menu items, parsed from JMP's own menu documentation. So "where do I click?" gets an authoritative answer, not a regex guess.

4. Intent routing — 8 intents. "How do I run a Partition?" returns Launch the Partition Platform. "How is the Partition split computed?" returns Statistical Details. Same topic, different need.

Quickstart

You need: Python 3.11+, Ollama, ~8 GB free disk.

git clone https://github.com/nepseli/jmp-docs-mcp.git
cd jmp-docs-mcp

1 — Install

python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[dev]"

2 — Get the model

ollama pull qwen3:8b

3 — Build the index (one time, ~70 min, unattended)

.\.venv\Scripts\python.exe scripts\build_corpus.py
.\.venv\Scripts\python.exe scripts\build_index.py

Downloads 3,864 pages and 4,251 figures (~15 min, resumable — interrupt it freely), then embeds them (~46 min). For a faster build, set index.embed_model: BAAI/bge-small-en-v1.5 in config.yaml.

If your clone is inside OneDrive / Dropbox / iCloud, move the data directory somewhere unsynced first — 7,000 files will otherwise churn your sync client on every rebuild. Copy .env.example to .env and set JMPDOCS_PATHS__DATA_DIR.

4 — Run

Double-click Start JMP Docs.bat, or:

.\Start-JmpDocs.ps1

Open http://localhost:8501.

Command	Does
`.\Start-JmpDocs.ps1`	Start (starts Ollama too if needed)
`.\Start-JmpDocs.ps1 -Status`	Is it running? Is it healthy? Is the index built?
`.\Start-JmpDocs.ps1 -Restart`	Force a clean restart
`.\Start-JmpDocs.ps1 -Stop`	Stop it

If the app says "the documentation index has not been built yet" but you know you built it, the running copy is stale — use -Restart. The launcher health-checks rather than just checking whether the port is busy, so it will replace a hung instance instead of reporting a false success.

The Python is cross-platform; only the launcher scripts are Windows-specific.

python3 -m venv .venv && ./.venv/bin/python -m pip install -e ".[dev]"
./.venv/bin/python scripts/build_corpus.py
./.venv/bin/python scripts/build_index.py
./.venv/bin/python -m streamlit run src/jmpdocs/app.py

Not executed by the author — reports welcome.

Using it as an MCP server

The chat app is the demo. The MCP server is the part that scales, because MCP is a protocol — not a Claude feature. Any MCP-capable agent can use these tools.

The 10 tools

Tool	Answers
`search_jmp_docs`	General questions, with citations
`whats_this`	"What is this thing on my screen?"
`find_menu_path`	"Where do I click?"
`get_jmp_page`	Full text of one page
`find_example`	Worked examples, optionally by sample data table
`find_jmp_figures`	Dialog screenshots, by caption
`list_jmp_books` · `browse_jmp_toc`	Structure navigation
`jmp_fetch_live`	Bypass the index, fetch fresh from jmp.com
`index_stats`	What's indexed, and when

In Claude Desktop or Claude Code

Copy the jmp-docs block from claude_desktop_config.example.json into your claude_desktop_config.json, fix the paths, restart. Now you can ask JMP questions while writing JSL, without leaving your editor.

Inside a larger agent

This is where it gets useful. The tools return structured JSON with source URLs, not prose — they're built to be consumed by a machine that may want to verify, chain or combine them.

Load them into any LangGraph agent with langchain-mcp-adapters:

from langchain_mcp_adapters.client import MultiServerMCPClient
from langgraph.prebuilt import create_react_agent
from langchain_ollama import ChatOllama

client = MultiServerMCPClient({
    "jmp-docs": {
        "command": "/path/to/jmp-docs-mcp/.venv/bin/python",
        "args": ["-m", "jmpdocs.mcp_server"],
        "transport": "stdio",
    }
})

tools = await client.get_tools()
agent = create_react_agent(ChatOllama(model="qwen3:8b"), tools)

Patterns this unlocks:

A manufacturing copilot. Give one agent this server plus your MES or data warehouse. It can pull yesterday's yield data, notice the Cpk dropped, and look up how to build the capability report — in a single conversation.
A JSL coding agent. Pair with a filesystem server so the agent reads your script, looks up the message syntax it needs here, and writes the fix.
A supervisor routing to specialists. In a multi-agent setup, this becomes the "JMP knowledge" node the supervisor delegates documentation questions to.
Onboarding automation. A scheduled agent that answers new-starter JMP questions in Slack, citing the official docs every time.

For networked deployments, --http serves streamable-HTTP instead of stdio:

python -m jmpdocs.mcp_server --http --host 0.0.0.0 --port 8000

Why local models

Running on Ollama is a design choice, not a compromise.

Your questions never leave the machine. JMP's heaviest users work in semiconductor, pharma and defence-adjacent manufacturing, where pasting anything into a hosted chatbot is a policy violation. Even a question like "why is my Cpk dropping on the etch process" leaks intent. Local inference removes the problem entirely — nothing to review, nothing to get approved.

Zero marginal cost. After the one-time build, every question is free forever. Share it with 40 engineers; the cost doesn't change.

It works offline. On a fab floor, in a validation lab, on a plane.

Nothing gets deprecated underneath you. The model is a file you control. Same index + same model + temperature 0.1 gives the same answer next quarter — which matters if you're citing documentation in a validation report.

The trade is speed: 45–60 s per answer on CPU, versus 2–5 s from a hosted API. See Limitations.

Why Qwen 3 specifically

The job here is narrow: read these six documentation excerpts and rewrite them as numbered steps with citations. It is not open-ended reasoning — retrieval already did the hard part. That shapes what matters in a model.

Requirement	Why Qwen 3 fits
Truly free to use	Apache 2.0. Llama's licence has usage conditions that make corporate legal teams pause; Qwen's doesn't.
Follows format instructions	The intent templates demand a specific shape — menu path first, then numbered steps, then citations. Qwen 3 holds that structure reliably at 8B, which many same-size models don't.
Faithful to source	It summarises the excerpts rather than drifting into its own knowledge — exactly what you want when hallucinating a menu path is the worst failure mode.
Fits in memory	~5 GB alongside the 440 MB embedder, comfortable on a 16 GB machine.
Scales without code changes	Ships as 0.6b / 1.7b / 4b / 8b / 14b / 32b. Got a GPU? Change one config line to `qwen3:14b`.

qwen3:8b is the answer model. qwen3:4b is configured in the fast-model slot for query rewriting, but that path is off by default — measured on this hardware, it ignored both reasoning=False and /no_think, spent 30+ seconds emitting chain-of-thought prose instead of search queries, and produced worse results than the free deterministic fallback. It's kept as a config option for when a better small model is available.

Other models work — llama3.1:8b, mistral-nemo, gemma3 — change llm.answer_model and restart. Nothing in the code is Qwen-specific.

Historical note: the project originally targeted gpt-oss:20b. The local model blob turned out to be corrupt (it failed to load on two Ollama versions with a tensor size overflow), and switching to qwen3:8b turned out to be the better choice for CPU inference anyway.

Results

36 golden questions, written in user vocabulary rather than documentation vocabulary. A test set phrased the way the docs phrase things would score near-perfect and prove nothing.

Configuration	Recall@6	MRR	Latency
Default	97.2 %	0.843	0.44 s
Without the vocabulary bridge	83.3 %	0.657	0.41 s
With cross-encoder reranking	97.2 %	0.831	4.32 s

Intent classification: 100 % (14/14). Tests: 110 passed, 1 xfailed.

Two findings worth recording, because both contradicted the original design:

The vocabulary bridge is the most valuable component — +13.9 points overall. On bridge-specific questions it lifts recall from 73 % to 93 %.

The cross-encoder reranker earns nothing. Same recall, slightly worse ranking, ~10× the latency. It's off by default. It only looked essential until a scoring bug was found: BM25 scores aren't comparable across queries, so normalising the pooled scores once let a long question drown out the short alias query carrying the bridge. Normalising per query moved recall from 86.1 % to 97.2 % on its own.

One test is a deliberate failure: JMP has no deduplication feature, so "how do I remove duplicate rows?" has no page to find. It's marked known_gap and xfailed rather than deleted — hiding it would hide a real documentation gap.

.\.venv\Scripts\python.exe scripts\eval_retrieval.py              # score it
.\.venv\Scripts\python.exe scripts\eval_retrieval.py --no-alias   # ablate the bridge
.\.venv\Scripts\python.exe -m pytest                              # full suite

Configuration

config.yaml holds the defaults. Override any value with an environment variable using the JMPDOCS_ prefix and __ for nesting:

JMPDOCS_LLM__ANSWER_MODEL=qwen3:14b
JMPDOCS_RETRIEVAL__K_FINAL=8

Setting	Default	Change it when
`llm.answer_model`	`qwen3:8b`	You have GPU headroom → `qwen3:14b`
`index.embed_model`	`BAAI/bge-base-en-v1.5`	You want a ~3× faster build → `bge-small`
`retrieval.rerank`	`false`	Retrieval is missing things and you'll accept the latency
`llm.num_predict`	`420`	Answers are getting truncated

New JMP release? Point source.version and source.base_url at it and re-run both build scripts. The crawler is cache-backed, so only changed pages refetch.

Project layout

src/jmpdocs/
  ingest/       toc · crawl · parse · menus · images · build_index
  knowledge/    aliases.yaml (the bridge) · intent taxonomy
  retrieval/    store · hybrid search
  graph/        LangGraph pipeline · intent-specific prompts
  mcp_server.py FastMCP, 10 tools
  app.py        Streamlit chat
scripts/        build_corpus · build_index · eval_retrieval · refresh
eval/           golden_questions.yaml
tests/          111 tests

Stack: LangGraph · LangChain · FastMCP · FAISS · rank-bm25 · sentence-transformers (BGE) · Streamlit · Ollama

Ideas for improvement

Roughly ordered by value per unit of effort.

Make the vocabulary bridge self-extending. It's hand-authored — the one component that can't be derived from the site. Logging queries that retrieve nothing confident would surface missing aliases automatically, turning usage into a growth loop.

GPU inference. The biggest user-visible win. Answers drop from ~50 s to 3–5 s with no code change. This was built on a machine with a 2 GB integrated GPU, which is why CPU numbers dominate here.

Make figures searchable. Images are display-only today. Running a vision model over the 4,251 screenshots once at build time would let you find "the dialog with the Validation Portion field" by content, not just caption.

Answer caching. Docs are static and engineers ask overlapping questions. A semantic cache would make repeat asks instant and compound across a team.

Cross-version diffing. Index two JMP releases and answer "what changed in DOE between 18 and 19?" — a question the official docs answer poorly and that matters at every upgrade.

A bigger evaluation set. 36 questions catches regressions but is thin for tuning; differences under ~5 points are noise. A few hundred, harvested from real JMP community threads, would let the weights be tuned rather than reasoned about.

Verify generated JSL. Scripting answers look right but are untested. Running them against a real JMP instance and feeding errors back would close the loop.

Index the JMP User Community. Official docs describe features; community threads solve problems. Both, clearly labelled by source, would cover the questions the manual doesn't.

Limitations

Stated plainly, because they're real.

Answers take 45–60 seconds. The big one. On CPU, prompt evaluation runs ~55 tok/s and generation ~8 tok/s — generation dominates. The first question of a session adds ~12 s of model loading, and the app needs ~20 s on first load to memory-map the index, during which the sidebar is missing and it looks half-broken. A GPU fixes this. If you want speed above all, this is the wrong architecture.

Answer quality is capped by an 8B model. Retrieval does the heavy lifting and the model summarises, which suits a documentation assistant. It won't design your experiment or interpret your results the way a statistician would. It will not tell you whether a Bootstrap Forest is the right choice.

The vocabulary bridge is finite. 134 entries cover common cases. Ask about something outside it in non-JMP terms and you'll get the same miss a plain RAG would. It's designed to be extended — one YAML line, asserted by the tests — but it doesn't extend itself.

It only knows JMP 19.1, and only what's documented. Nothing about older versions, add-ins, or community solutions. Where the docs have gaps, so does this.

Retrieval is strong but not proven at scale. 97.2 % recall on 36 questions authored by the same person who built the system. An independent, larger set would be a fairer test.

Figures are shown, never analysed. A screenshot that perfectly answers your question won't be found unless its caption matches.

Windows-verified only. The Python should run anywhere; the launchers are PowerShell and batch.

It's a personal project, not a product. No auth, no multi-user isolation, no support commitment. Single-user localhost is the design point.

Legal

This is an independent, unofficial tool. It is not affiliated with, endorsed by, or sponsored by JMP Statistical Discovery LLC or SAS Institute Inc. "JMP" is a trademark of JMP Statistical Discovery LLC.

The ingestion pipeline downloads JMP's publicly accessible documentation at build time (their robots.txt permits crawling; the crawler is rate-limited and polite). That content belongs to JMP and is not redistributed here — the crawled corpus, figures and index are excluded from version control and must stay that way. Each user builds their own index, and every answer cites and links back to the official page.

If you represent JMP and would like something changed, please open an issue.

License

MIT — see LICENSE.

The licence covers the source code only, not the JMP documentation this tool retrieves. See NOTICE for scope, trademarks and third-party components.

Available Tools

10 tools

browse_jmp_tocBrowse Jmp TocA

Browse the table of contents for one book.

ParametersJSON Schema

Name	Required	Description
`book`	Yes	Book name from list_jmp_books.
`limit`	No	Max entries.
`contains`	No	Only titles containing this text.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. 'Browse' conveys read-only intent, but the description does not explicitly mention side effects, authentication, or behavior around limits and filtering. It is acceptable for a simple read operation but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the action and resource. There is no filler or redundancy, and it is appropriately sized for a simple TOC-browsing tool.

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?

An output schema exists, and the input schema fully documents parameters, so the description does not need to explain return values or parameter formats. The main gap is the lack of explicit usage guidance versus alternatives, but for a simple read-only browsing tool the definition is essentially complete.

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%, and all three parameters (book, limit, contains) have explicit descriptions in the schema. The tool description adds no parameter-specific semantics, but none are needed because the schema already provides complete information. Baseline 3 applies.

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?

The description states a specific action ('browse') on a specific resource ('table of contents for one book'). This clearly distinguishes it from siblings like list_jmp_books and search_jmp_docs. The scope is explicit and unambiguous.

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

Usage Guidelines3/5

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

The description implies usage by naming the resource, but it does not explicitly say when to use this tool versus alternatives such as search_jmp_docs or find_menu_path. The schema hint 'Book name from list_jmp_books' provides some context, but the tool description itself lacks direct usage guidance.

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

find_exampleFind ExampleA

Find worked examples, optionally restricted to a sample data table.

JMP users learn from the built-in sample data, so this searches the ~630 'Example of...' pages specifically.

ParametersJSON Schema

Name	Required	Description
`k`	No	Max examples.
`topic`	Yes	Topic or JMP platform to find examples for.
`dataset`	No	Optional sample data table, e.g. 'Big Class.jmp'.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the search scope (~630 pages) and optional dataset restriction, but doesn't mention behavior like result ordering, pagination, or what happens when no examples are found. The description adds some context beyond the schema but not deep behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The core purpose is front-loaded, and the second sentence provides valuable context about the search scope. Every sentence earns its place.

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?

The tool has an output schema, so return values are covered elsewhere. The description explains the search scope and optional restriction, which is sufficient for an agent to invoke it correctly. It could mention result limits or error behavior, but the output schema and parameter defaults cover most operational needs.

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 the schema already documents all three parameters. The description adds context about the 'dataset' parameter (restricting to a sample data table) and the 'topic' parameter (topic or JMP platform), but doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate.

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?

The description clearly states the tool's purpose: finding worked examples, optionally restricted to a sample data table. It also distinguishes itself from generic documentation search by specifying it searches the ~630 'Example of...' pages, which differentiates it from siblings like search_jmp_docs and get_jmp_page.

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?

The description explains the context ('JMP users learn from the built-in sample data') and implies this tool is for finding examples rather than general docs. It doesn't explicitly name alternatives or say when not to use it, but the scope is clear enough for an agent to select it appropriately among siblings.

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

find_jmp_figuresFind Jmp FiguresA

Find documentation figures (JMP dialog and report screenshots) by caption.

ParametersJSON Schema

Name	Required	Description	Default
`k`	No	Max figures.
`query`	Yes	What the figure should show.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that matching is done 'by caption' and that the tool is read-only in nature, but it does not describe matching semantics, ordering, or limits. This is adequate for a simple find tool but leaves some behavioral detail unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single focused sentence with no filler. The core action, resource type, and matching criterion are all front-loaded and immediately usable.

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?

Given the tool's simplicity, the presence of an output schema, and full parameter schema coverage, the description covers what the agent needs for basic invocation. It could add usage guidance or matching behavior, but nothing essential is missing for selecting and calling the tool.

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, but the description adds meaningful semantic context by specifying that the query should be a caption. This is more specific than the schema's 'What the figure should show' and helps the agent phrase the query correctly.

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?

The description states a specific verb ('Find') and a specific resource ('documentation figures... by caption'), and clarifies the figure types as JMP dialog and report screenshots. This clearly differentiates it from sibling tools like search_jmp_docs, which target documentation text rather than figures.

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

Usage Guidelines3/5

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

The description implies the tool should be used when looking for JMP figures by caption, but it does not explicitly state when not to use it or name alternatives. The intended use is inferable but not directly contrasted with siblings such as search_jmp_docs or find_example.

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

find_menu_pathFind Menu PathA

Find where a feature lives in JMP's menus.

Backed by JMP's own menu reference (every menu item and its description), so the paths are authoritative rather than scraped from prose.

ParametersJSON Schema

Name	Required	Description	Default
`k`	No	Max menu items.
`task`	Yes	What the user wants to do, e.g. 'fit a model'.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It adds useful context about the data source ('JMP's own menu reference' and 'authoritative rather than scraped'), but it does not disclose edge cases, no-result behavior, or how the task string is matched. The output schema may cover the return shape, but behavioral details remain thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with the main purpose front-loaded. The second sentence adds a valuable authority qualifier without fluff, and every sentence earns its place.

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

Completeness3/5

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

Since an output schema exists, the description does not need to explain return values. However, in a crowded sibling set, the lack of explicit routing guidance (when to choose find_menu_path over search_jmp_docs or browse_jmp_toc) leaves an important gap. The core invocation parameters and purpose are still clear.

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 100%, so the baseline is 3 even without description-level parameter details. The description's 'feature' maps naturally to the required task parameter, but it adds no extra meaning about k or task phrasing beyond what the schema already states.

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?

Clearly states a specific verb ('Find') and resource ('where a feature lives in JMP's menus'), which makes the tool's scope immediately recognizable. This distinguishes it from general documentation/search siblings like search_jmp_docs or get_jmp_page.

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

Usage Guidelines3/5

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

The description implies the tool is for menu-location questions, but it never explicitly contrasts it with siblings such as search_jmp_docs, whats_this, or browse_jmp_toc. There is no clear when-to-use vs. when-not-to-use guidance beyond the purpose phrase.

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

get_jmp_pageGet Jmp PageA

Return the full text of one documentation page, with its figures.

ParametersJSON Schema

Name	Required	Description	Default
`page`	Yes	Page path ('jmp/tabulate.shtml') or an exact page title.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/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 burden, and it clearly discloses the core behavior: retrieving the full text and including figures. It does not go into error handling or format details, but for a read-only page retrieval tool the main behavior is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the action and the key output detail ('with its figures') with no filler or redundant phrasing.

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?

For a one-parameter retrieval tool with an output schema present, the description is largely sufficient: it names what is returned and the input format is covered by the schema. It could be more complete by mentioning invalid-page behavior or clarifying how figures are represented, but these are minor gaps.

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 100%, and the parameter description already explains that 'page' accepts a path or exact title. The tool description adds no additional meaning about the parameter beyond what the schema provides, so the baseline of 3 is appropriate.

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?

The description states a specific verb ('Return') and a clear resource ('the full text of one documentation page'), and it distinguishes itself from siblings like search_jmp_docs, browse_jmp_toc, and find_jmp_figures by focusing on a single page's complete content plus its figures.

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

Usage Guidelines3/5

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

Usage context is implied: an agent would use this when it already knows a page path or exact title and wants the full content. However, the description does not explicitly state when to prefer this over search_jmp_docs, find_jmp_figures, or browse_jmp_toc, nor does it name alternatives.

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

index_statsIndex StatsA

Report what the local index contains and when it was built.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly indicates a read-only reporting operation, which is helpful, but it does not explain what happens if the local index does not exist or is stale, nor does it mention whether the report could trigger an update. The core behavior is transparent, but edge cases are left open.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that immediately states the action and the two key outputs (contents and build time). There is no filler, and the most important information is front-loaded.

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?

Given that the tool takes no parameters and has an output schema, the description is largely complete for an agent deciding whether to call it. The only missing context is explicit guidance on when to choose this over sibling tools, but the resource name and purpose make the use case reasonably clear.

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?

The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 for a zero-parameter tool is appropriate; the description correctly focuses on the tool's purpose rather than inventing parameter details.

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?

The description uses a specific verb ('Report') with a clear resource ('the local index') and specifies exactly what is reported: its contents and build time. This distinguishes it from siblings like search_jmp_docs and browse_jmp_toc, which navigate or search documentation rather than inspect the index itself.

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

Usage Guidelines2/5

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

The description gives no explicit guidance on when to use this tool versus alternatives. It implies a status/inspection use case, but it never states conditions like 'use this to check if the index is current' or 'instead of searching, use this to see indexed items.' An agent must infer the intended context from the name and resource.

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

jmp_fetch_liveJmp Fetch LiveA

Fetch a documentation page live from jmp.com, bypassing the local index.

Use when a page may be newer than the index, or is not indexed.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	A https://www.jmp.com/support/help/en/19.1/... URL.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool bypasses the local index and fetches live from jmp.com, implying a network read operation. However, it does not mention potential failure modes, network dependency, rate limits, or any side effects. For a simple fetch tool, this is adequate but not rich. It adds some context beyond the name but lacks depth on error behavior or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero fluff. The first sentence states the core purpose and mechanism ('Fetch a documentation page live from jmp.com, bypassing the local index.'), and the second provides direct usage guidance. It is front-loaded with the most critical information and every word earns its place. Ideal conciseness for a simple tool.

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?

Given the tool's simplicity (one parameter, no annotations, and an output schema), the description is complete. It states what the tool does, how it differs from the index-based approach, and when to use it. The output schema covers return values, so the description need not explain them. Nothing an agent needs to correctly invoke this tool is missing.

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?

The input schema already describes the 'url' parameter with a specific format ('A https://www.jmp.com/support/help/en/19.1/... URL'). Schema description coverage is 100%, so the schema carries the parameter documentation. The description does not add any additional meaning about the parameter beyond its existence and purpose, which is baseline for full coverage. It neither detracts nor enhances the schema's clarity.

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?

The description clearly states the action ('Fetch a documentation page live from jmp.com') and the resource (documentation page at jmp.com). It also distinguishes itself from the local index and implicitly differentiates from sibling tools like get_jmp_page by saying 'bypassing the local index.' This is specific and unambiguous.

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?

The description explicitly states when to use this tool: 'Use when a page may be newer than the index, or is not indexed.' This provides clear context for selection. However, it does not explicitly name an alternative (e.g., get_jmp_page) or state when NOT to use it, which would strengthen the guidance. Still, the 'when to use' is explicit and sufficient for an agent to route correctly.

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

list_jmp_booksList Jmp BooksA

List the JMP documentation books, with page counts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

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

The description states the core behavior and a key output characteristic (page counts), but with no annotations it carries the full burden of disclosure. It does not explicitly say the operation is read-only, describe the return shape beyond page counts, or mention ordering or live/cached behavior. The output schema partially compensates for return details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. It states the action, the resource, and the distinguishing output detail efficiently.

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 zero-parameter list operation with an output schema, the description is sufficient. It identifies the exact scope ('JMP documentation books') and the expected content (page counts), leaving no essential detail missing for invoking the tool.

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?

The tool has zero parameters, so the baseline is 4. There is no parameter ambiguity, and the description does not need to explain parameter meanings beyond what the empty schema already establishes.

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?

The description names a specific verb ('List') and a specific resource ('JMP documentation books'), and adds the output detail 'with page counts.' This clearly distinguishes it from siblings like search_jmp_docs or get_jmp_page, which operate on different levels of content.

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

Usage Guidelines3/5

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

The intended use is implied: use this tool when the user wants an overview of available JMP documentation books. However, it does not explicitly contrast itself with sibling tools like browse_jmp_toc or search_jmp_docs, nor state when not to use it.

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

search_jmp_docsSearch Jmp DocsA

Search the JMP 19.1 documentation and return the most relevant excerpts.

Handles JMP's own naming: asking for a "random forest" finds "Bootstrap Forest", "pivot table" finds "Tabulate", and so on.

ParametersJSON Schema

Name	Required	Description
`k`	No	Number of excerpts to return.
`book`	No	Restrict to one book, e.g. 'Design of Experiments Guide'.
`query`	Yes	Natural-language question about JMP.
`intent`	No	Optional intent hint. One of: how_to, what_is, interpret, option_lookup, example, scripting, where_is_it, troubleshoot.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral burden. It discloses that the tool returns excerpts and handles JMP's non-obvious naming conventions, which is useful. However, it does not explain limitations, result relevance behavior, or whether output is restricted by book unless specified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the core action, and every sentence adds value. The naming-convention paragraph is high-signal and not redundant with the schema.

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?

Given the rich input schema, an output schema, and a fairly simple search operation, the description covers what an agent needs to invoke the tool correctly. It lacks sibling differentiation and some usage context, but those are already accounted for in other dimensions.

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, but the description adds meaningful semantics for the query parameter by giving concrete examples of JMP naming translation. This helps an agent understand that query terms will be mapped to JMP's official terminology.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches JMP 19.1 documentation and returns excerpts, using a specific verb and resource. It does not explicitly differentiate itself from siblings like find_menu_path or get_jmp_page, so it stops short of a 5.

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

Usage Guidelines2/5

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

The description implies the tool is for natural-language doc searches, and the query schema parameter reinforces this, but it gives no explicit guidance about when to prefer search_jmp_docs over related tools such as find_example, browse_jmp_toc, or whats_this. No exclusions or alternative routing are provided.

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

whats_thisWhats ThisA

Explain an on-screen JMP element using JMP's own context-help map.

JMP ships a mapping from UI element names to the exact documentation section that describes them; this looks the user's words up in it.

ParametersJSON Schema

Name	Required	Description	Default
`k`	No	Max matches.
`ui_element`	Yes	Name of something visible in JMP, e.g. 'Query Builder Join Editor'.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the underlying mechanism (looking words up in JMP's built-in context-help map), which hints at a non-full-text lookup. But it doesn't disclose failure behavior (no match found), result ranking, or exactness of matching. The presence of an output schema mitigates return-format ambiguity.

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?

Compact two-paragraph structure that front-loads the purpose in the first sentence and adds the mechanistic detail in the second. Both sentences earn their place with no fluff or repetition of schema content.

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?

For a straightforward two-parameter lookup tool with full schema coverage and an output schema, the description is largely sufficient. The mechanism is disclosed, parameters are documented, and return values are likely covered by the output schema. The main gap is usage differentiation against sibling search_jmp_docs, already noted.

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 the baseline is 3. The schema already documents ui_element with a concrete example and k as 'Max matches' with default and bounds. The tool description adds no parameter-level meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Explain'), a clear resource ('on-screen JMP element'), and a distinctive mechanism ('JMP's own context-help map'). This differentiates it from sibling search_jmp_docs by emphasizing a map-based lookup rather than document search, though it doesn't name alternatives explicitly.

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

Usage Guidelines3/5

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

The phrase 'on-screen JMP element' implies the intended scenario — the element must be visible in JMP. However, there is no explicit guidance on when to choose this over the close sibling search_jmp_docs, nor any exclusions or alternative routing.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

10 tool updatesv0.1.0Sep 17, 2026
- First observedbrowse_jmp_toc
- First observedfind_example
- First observedfind_jmp_figures
- First observedfind_menu_path
- First observedget_jmp_page
- First observedindex_stats
- First observedjmp_fetch_live
- First observedlist_jmp_books
- First observedsearch_jmp_docs
- First observedwhats_this

Deploy Server

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

TDQS

A4/5.0

Scored 2026-09-17 07:20 across 10 tools

Disambiguation5/5

Each tool targets a distinct resource: docs search, menu lookup, examples, figures, TOC, books, context help, and page retrieval. The closest pair, get_jmp_page and jmp_fetch_live, is clearly differentiated by local index vs. live bypass.

Naming Consistency4/5

Most tools follow a snake_case verb_noun pattern (search_jmp_docs, find_menu_path, get_jmp_page, browse_jmp_toc). A few deviations like whats_this, jmp_fetch_live, and index_stats are noticeable but do not seriously undermine the overall pattern.

Tool Count5/5

Ten tools is well-scoped for a documentation server: it covers search, navigation, retrieval, examples, figures, menu paths, and index introspection without redundancy. Each tool has a clear role and none feels like filler.

Completeness5/5

The surface covers the full documentation workflow: discovering features, finding menu paths, browsing TOCs, retrieving pages, locating examples and figures, and checking index freshness. The live fetch fallback also handles newer or unindexed content, leaving no obvious dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

developer-toolkit-mcp A
io.github.mjaskolski
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
AI & Machine Learning Search
21
docs A
com.ntop
Search and query nTop's knowledge base and engineering guides from AI applications.
Search Documentation Access
32
Razi Tools A
io.github.razikallayi
PDF, image, video, OCR, screenshot, SQL, QR and text tools for agents. No API key, no signup.
Image & Video Processing Databases
281
docs2mcpOAuth
com.docs2mcp
Query your own PDFs and documents from any MCP client. Every answer cites the page it came from.
RAG Systems Search
1

Related MCP Servers

Jamf Docs MCP Server
Documentation Access Search
GET-Technology-Inc
A
license
A
quality
A
maintenance
Provides AI assistants with direct access to Jamf official documentation, enabling them to answer Jamf-related questions by searching, retrieving articles, and browsing product documentation.
Updated 3 days ago (2026-09-21 07:26 UTC)
6
858 npm
3
MIT
anydocs
Search Documentation Access RAG Systems
kiyeonjeon21
A
license
A
quality
A
maintenance
Provides fast, token-efficient search over coding agent documentation (e.g., Claude Code, Cursor) using local SQLite FTS5 indexing, with tools for searching snippets, reading pages, and grepping markdown.
Updated a month ago (2026-08-15 11:27 UTC)
5
MIT
DocAgent
Sharvary-HH
A
license
Not graded
quality
C
maintenance
Enables document retrieval, OCR, web search, and calculator tools via a RAG pipeline and LangGraph agent, all running locally with Ollama.
Updated 2 months ago (2026-07-22 14:14 UTC)
MIT
Mosaic MCP Server
Search RAG Systems
alexxb2mg-svg
A
license
Not graded
quality
A
maintenance
Provides 11 MCP tools for deterministic, local semantic search over your documents, including indexing, retrieval, exact-match facets, temporal truth, semantic diff, and agent-first JSON output. Enables LLMs and agents to search, retrieve, and analyze documents without cloud dependencies or per-query costs.
Updated 24 days ago (2026-08-30 11:31 UTC)
2
Apache 2.0