llmref

Server Details

Versioned documentation registry and semantic search for AI tools and coding assistants.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 36 days
Last Tested: 2026-09-22 02:36
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: reclear-io/llmref-plugin
GitHub Stars: 0

TDQS

A4.2/5.0

Scored 2026-09-10 23:20 across 4 tools

Disambiguation5/5

Each tool targets a distinct resource and action: project discovery, version listing, artifact URL resolution, and semantic search. There is no meaningful overlap between them.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern. list_projects/list_versions and resolve_docs/search_docs are parallel and predictable.

Tool Count5/5

Four tools is well-scoped for a documentation indexing/retrieval server. Each tool serves a clear step in the workflow without redundancy or bloat.

Completeness4/5

The tools cover project discovery, version discovery, artifact resolution, and semantic search, which forms a complete workflow. A minor gap is the lack of direct document content retrieval, though artifact URLs make this workable.

Available Tools

4 tools

list_projectsA

Read-only

Inspect

List indexed documentation projects. Use this first to discover what's available. Supports a forgiving fuzzy query over slugs (ranked by relevance) plus limit and skip for pagination.

ParametersJSON Schema

Name	Required	Description
`skip`	No	Number of results to skip, for pagination (default 0).
`limit`	No	Maximum number of results to return (default 50, max 200).
`query`	No	Forgiving fuzzy filter over project slugs; results are ranked by relevance.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations provide readOnlyHint and openWorldHint, so the description's focus on fuzzy query and pagination adds useful behavior detail without contradicting annotations. It doesn't cover all traits (e.g., rate limits), but it's sufficient for this simple, read-only tool.

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 only two sentences, both front-loaded with essential info: purpose first, then usage and features. No filler or repetition; every word 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?

For a simple listing tool with no output schema, the description covers purpose, usage context, and parameter behavior adequately. Missing details like default pagination behavior are already in the schema, so no critical gap.

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 description essentially restates schema info: 'forgiving fuzzy `query` over slugs' and pagination. It adds minimal insight beyond what the schema provides, so 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 action: 'List indexed documentation projects.' It also offers a usage hint ('Use this first to discover what's available'), which distinguishes it from siblings like list_versions and search_docs, ensuring no confusion.

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 advises 'Use this first to discover what's available', implying it's a starting point. It also explains query and pagination support. However, it doesn't explicitly state when not to use it or mention alternatives, leaving some ambiguity.

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

list_versionsA

Read-only

Inspect

List available versions for a project. Call this before resolve_docs or search_docs to see valid version strings.

ParametersJSON Schema

Name	Required	Description	Default
`project`	Yes	Project slug (e.g. "nextjs", "react")

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and dynamism. The description adds context that ordering matters, which is valuable behavioral info beyond what annotations provide.

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, front-loaded sentences with no fluff. Every sentence adds value: first states purpose, second gives usage guidance.

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 one parameter, no output schema, and comprehensive annotations, the description is sufficient. It covers purpose, usage context, and parameter hint via usage example, leaving no critical 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%; the schema already describes the 'project' parameter in detail. The description does not add additional parameter meaning beyond what is in the schema.

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?

Description clearly states the tool lists available versions for a project, with a specific verb and resource. It distinguishes itself by naming sibling tools resolve_docs and search_docs, implying it is a prerequisite.

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?

Explicitly instructs to call this tool before resolve_docs or search_docs, providing clear when-to-use context and differentiating its role among siblings.

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

resolve_docsA

Read-only

Inspect

Resolve a project version and get artifact URLs (llms.txt, llms-full.txt, meta.json, dumps). Use list_versions first to discover valid version strings.

ParametersJSON Schema

Name	Required	Description	Default
`project`	Yes	Project slug (e.g. "nextjs", "react")
`version`	Yes	Version string or "latest"

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already mark the tool as readOnlyHint=true. The description adds the specific artifacts returned, which is useful context. No contradictions or missing behavioral traits beyond what annotations provide.

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 sentences, no filler. Front-loaded with the primary action and follows with a usage hint. Every word is informative.

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?

Description adequately explains what the tool does and lists the artifact filenames. However, without an output schema, it could be improved by specifying the response structure (e.g., key-value pairs). Still, sufficient for a simple tool.

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?

Input schema covers both parameters (project, version) with descriptions. The tool description does not add new semantics beyond the schema, so baseline score of 3 applies.

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 resolves a project version to retrieve artifact URLs, mentioning specific filenames. It distinguishes itself indirectly by referencing list_versions as a prerequisite, but does not explicitly contrast with siblings like search_docs.

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 advises using list_versions first, which provides clear context. However, it lacks explicit when-not-to-use guidance or comparisons with sibling tools beyond the prerequisite hint.

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

search_docsA

Read-only

Inspect

Semantic search across a project's documentation. Returns chunks ranked by relevance. Requires the server to have semantic search enabled.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Natural-language search query
`top_k`	No	Max results (1-50, default 10)
`project`	Yes	Project slug (e.g. "nextjs", "react")
`version`	Yes	Version string or "latest"
`token_budget`	No	Max tokens to budget for results (default 4096)

TDQS

A3.8/5.0

Behavior4/5

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

The description adds context beyond annotations (readOnlyHint, openWorldHint) by disclosing the server-side requirement for semantic search. It does not contradict annotations.

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 that front-load the purpose and then add the prerequisite. Every sentence is necessary and no filler.

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 search tool with 5 parameters fully defined in schema and no output schema, the description gives sufficient context (semantic search, relevance ranking, server requirement). Could mention how top_k and token_budget affect output, but overall 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?

Input schema has 100% description coverage, so parameters are already well-documented. The description does not add extra meaning or context for any parameter, resulting in a baseline score.

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 it performs 'semantic search across a project's documentation' and returns 'chunks ranked by relevance', specifying the verb (search) and resource (project docs). It distinguishes from siblings like list_projects and resolve_docs by focusing on semantic search.

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?

Only mentions a prerequisite ('Requires the server to have semantic search enabled'). No guidance on when to use this tool versus siblings (list_projects, list_versions, resolve_docs) or 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.

Tool Schema Changelog

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

1 tool updateJul 1, 2026

Changedlist_projects4 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / properties / limit

Added value: +{
+  "default": null,
+  "description": "Maximum number of results to return (default 50, max 200).",
+  "format": "uint",
+  "minimum": 0,
+  "type": [
+    "integer",
+    "null"
+  ]
+}

addedInput schema / properties / query

Added value: +{
+  "default": null,
+  "description": "Forgiving fuzzy filter over project slugs; results are ranked by relevance.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / skip

Added value: +{
+  "default": null,
+  "description": "Number of results to skip, for pagination (default 0).",
+  "format": "uint",
+  "minimum": 0,
+  "type": [
+    "integer",
+    "null"
+  ]
+}

4 tool updatesJul 1, 2026
- First observedlist_projects
- First observedlist_versions
- First observedresolve_docs
- First observedsearch_docs

Related MCP Connectors

ref-tools-ref-tools-mcpOAuth
ai.smithery
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Documentation Access Developer Tools Code Analysis
21,173
ragie
com.mcparmory
Ingest, manage, and retrieve documents for RAG-powered AI applications
RAG Systems Databases Knowledge & Memory
2
docuwriter AOAuth
ai.docuwriter
Generate, search, and manage codebase documentation on DocuWriter.ai. 72 tools incl. Autopilot.
AI & Machine Learning Developer Tools Documentation Access
723
KumbukaOAuth
ai.kumbuka
Governed, auditable knowledge your team curates for its AI assistants, self-hostable
Knowledge & Memory RAG Systems
21

Related MCP Servers

MCPDocSearch
Web Scraping RAG Systems Search
MCP-Mirror
A
license
Not graded
quality
Not graded
maintenance
Crawls documentation websites and provides semantic search capabilities over the content through vector embeddings, enabling natural language queries of technical documentation.
Updated a year ago (2025-06-25 18:03 UTC)
2
MIT
Crawl4AI RAG MCP Server
adnan0758
A
license
Not graded
quality
C
maintenance
Enables AI assistants to crawl, index, and retrieve information from technical documentation using semantic search, with optional knowledge graph validation for code hallucination detection.
Updated 2 months ago (2026-07-17 17:27 UTC)
MIT
Search Docs MCP
Search Documentation Access AI & Machine Learning
mostafa-ghaith
F
license
A
quality
D
maintenance
Enables semantic search across multiple AI library documentations to keep coding assistants up-to-date.
Updated a year ago (2025-04-18 16:02 UTC)
1
1
-
knowledge-server
RAG Systems Search Documentation Access
bwarzecha
A
license
Not graded
quality
D
maintenance
Enables LLMs to search and retrieve information from large technical documentation (OpenAPI specs, markdown) via intelligent chunking and semantic search.
Updated a year ago (2025-08-05 22:25 UTC)
MIT

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources