Which integrations are available for this server?

Provides unified semantic search across Plesk documentation sources (Admin Guide, REST API, CLI, PHP SDK, JS SDK) for extension developers, enabling efficient retrieval of relevant documentation, file content, and references.

How do I use mcp-plesk-dev-docs?

1. Click on "Install 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., "@mcp-plesk-dev-docs How to add a custom button in Plesk UI?" 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.

mcp-plesk-dev-docs

by barateza

Overview Schema Related Servers Score Discussions

Python

Local

mcp-plesk-dev-docs

Python 3.12+ PyPI Version PyPI Downloads MCP Registry License: MIT MCP Compatible Code style: black Ruff MCP Badge

NOTE

This MCP server provides unified documentation search for extension developers. If you are looking to manage your live Plesk server via AI, please see theofficial Plesk MCP Server.

State-of-the-Art (SOTA) semantic search across the entire Plesk documentation surface, optimized for sub-second latency on Apple Silicon.

Why this exists

Plesk documentation is spread across five separate sources: an admin guide, a REST API reference, a CLI reference, a PHP SDK, and a JS SDK. Answering a single extension development question often means searching all of them manually, cross-referencing results, and still missing the relevant section.

This server ingests all five sources, embeds them with a multilingual model, and exposes a single search_plesk_unified MCP tool. It uses hybrid search (Vector + FTS), Reciprocal Rank Fusion (RRF), and Cross-Encoder reranking to deliver high-precision results in milliseconds.

Related MCP server: Plesk Extensions Guide MCP Server

Architecture & Performance

flowchart TD
    Client["MCP Client\n(Claude Desktop / Cursor / etc.)"]

    Client -->|"search_plesk_unified(query)"| Server

    subgraph Server["FastMCP Server · Modular Architecture"]
        direction TB
        Main["Bootstrap · server/main.py"]
        Life["Lifecycle Hooks · server/lifecycle.py"]
        Tools["MCP Tools · server/mcp_app.py"]

        Main --> Life --> Tools
    end

    subgraph Pipeline["Retrieval Pipeline"]
        direction TB
        E["1 · Embed query\n(Hardware-accelerated)"]
        S["2 · Hybrid Search\nVector (LanceDB) + FTS (Tantivy)"]
        R["3 · RRF Merge + Rerank\n(MiniLM-L4-v2)"]
        N["4 · Neighbor Expansion\n(Context Enrichment)"]
        A["5 · AI Synthesis\n(sampling-enabled)"]
        E --> S --> R --> N --> A
    end

    subgraph Store["LanceDB Vector & FTS Store"]
        direction LR
        G["Guide"]
        A_["API"]
        C["CLI"]
        P["PHP Stubs"]
        J["JS SDK"]
    end

    Tools --> Pipeline
    S <--> Store

Performance Benchmarks (2026-05-04)

Optimized for Apple Silicon (M2/M3) using MPS acceleration and memory-resident table caching.

Profile	Embed Model	HR@5	MRR@5	Avg Latency	Est. RAM
`light`	BAAI/bge-small	100.0%	0.917	1.007 s	~200 MB
`medium`	BAAI/bge-base	100.0%	0.917	~0.60s	~600 MB
`full-tq`	BAAI/bge-m3	75.0%	0.750	~0.40s	~1300 MB

Metrics measured on Apple M2 Pro with LanceDB connection caching enabled.

Key Features

Single-Instance Lock: PID-based lock prevents concurrent LanceDB access when multiple MCP clients or IDE sessions try to launch the server simultaneously.
Sub-Second Hybrid Search: Combined Vector + Tantivy FTS with RAM-cached table connections for instant retrieval.
AST-Aware Chunking: Uses tree-sitter to respect class and method boundaries in PHP, JS, and TS documentation.
TurboQuant Acceleration: Fast 4-bit quantized search for the full-tq profile, delivering 10x lower latency for large models.
Neighborhood Retrieval: Automatically fetches adjacent chunks (prev/next) to provide complete context for grounding.
Macro-Context Summaries: Injects file-level purpose summaries into every chunk using the SummaryCache.
AI-Synthesized Answers: Generates concise answers from search results with structured inline citations [1], [2].

MCP Components

This server provides tools, prompts, and resources. See docs/mcp-components.md for a full reference.

Primary Tools

Tool	Description
`search_plesk_unified`	Hybrid search with RRF and Cross-Encoder reranking.
`get_file_content`	Retrieve the full content of a specific documentation file.
`resolve_references`	Find all files referencing a specific symbol or topic.
`refresh_knowledge`	Re-fetch sources and update the index (incremental).
`trigger_index_sync`	Start a background indexing job.
`daemon_health`	Check readiness, hardware acceleration (MPS/CUDA), and latency stats.

Resources

plesk://toc/api - Table of Contents for API documentation.
plesk://toc/cli - Table of Contents for CLI reference.
plesk://toc/guide - Table of Contents for Extensions Guide.
plesk://toc/php-stubs - Hierarchical list of PHP classes.

🚀 Installation & Setup

Because this server is published to PyPI and listed on the MCP Registry, you don't even need to clone the repository to run it!

Option 1: Run instantly via `uvx` (Recommended)

You can run or integrate the server in seconds.

1. Add to Claude Desktop

Add the server config to your claude_desktop_config.json (typically at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS, or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "plesk-dev-docs": {
      "command": "uvx",
      "args": ["mcp-plesk-dev-docs"]
    }
  }
}

2. Configure in Cursor

Go to Settings > Features > MCP, click + Add New MCP Server:

Name: plesk-dev-docs
Type: command
Command: uvx mcp-plesk-dev-docs

Option 2: Local Developer Setup (Manual Build)

If you want to modify the source code, run benchmarks, or manage database migrations:

Quick bootstrap (recommended):

git clone https://github.com/barateza/mcp-plesk-dev-docs.git
cd mcp-plesk-dev-docs
./install.sh          # Linux / macOS
# powershell -ExecutionPolicy Bypass -File install.ps1   # Windows

Manual setup:

git clone https://github.com/barateza/mcp-plesk-dev-docs.git
cd mcp-plesk-dev-docs
uv pip install -e ".[dev]"

Run Initial Indexing: Generate the offline vector database and full-text search indexes:
```
uv run python -m mcp_plesk_dev_docs.server.main refresh_knowledge
```

Start the Server:

uv run python -m mcp_plesk_dev_docs.server.main

Configuration

Set environment variables in .env:

PLESK_MODEL_PROFILE=light       # light | medium | full-tq
PLESK_ENABLE_SAMPLING=true     # AI-Synthesized answers
PLESK_DAEMON_AUTO_WARMUP=true  # Preload models on startup
PLESK_INDEX_SUMMARIES=true     # Enable file-level summaries
OPENROUTER_API_KEY=sk-or-v1-...

Documentation

docs/benchmarks.md - Detailed latency and quality reports.
docs/mcp-components.md - Full tool and resource reference.
docs/turboquant.md - 4-bit quantization internals.

License

MIT. See LICENSE.

Ownership & Disclaimer

This is a personal project by Gilson Siqueira. It is not officially affiliated with, endorsed by, or supported by Plesk or WebPros International GmbH. Plesk is a trademark of WebPros International GmbH.

Important notice about Plesk-owned deliverables

Portions of this repository were developed under contract for Plesk International GmbH ("Plesk") only if specifically identified as such. The MIT license above applies only to material the repository owner is authorized to license. Files or directories owned by Plesk, if any, are listed in NOTICE. If you need assurance about licensing for a particular file, contact Plesk or seek legal counsel before relying on the MIT License for Plesk-owned files.

Built to make Plesk extension development faster.

Available Tools

10 tools

check_sync_statusB

Check the status of a background indexing job.

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3/5.0

Behavior2/5

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

With no annotations, the description must carry the full burden of behavioral disclosure. It only states the basic function, omitting any details about required permissions, idempotency, polling behavior, or possible status values. This is insufficient for a tool with no 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?

The description is a single sentence that is direct and front-loaded. It contains no unnecessary words and efficiently communicates the core purpose.

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?

Given the tool's simplicity (one parameter) and the existence of an output schema, the description is minimally adequate. However, it lacks context about how to obtain the job_id or what typical statuses might be, leaving some gaps in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter (job_id) with 0% textual coverage, and the description does not mention or clarify it. The description adds no meaning beyond the schema, failing to compensate for the missing parameter descriptions.

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 'Check the status of a background indexing job' clearly states the action (checking status) and the target (background indexing job), distinguishing it from sibling tools like trigger_index_sync which perform actions rather than checks.

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 provides no guidance on when to use this tool versus alternatives such as trigger_index_sync or refresh_knowledge. The agent is left to infer usage context without explicit hints.

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

daemon_healthB

Return daemon-centric readiness status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior1/5

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

With no annotations provided, the description bears full responsibility for disclosing traits like possible statuses, side effects, or authentication needs. It only states 'readiness status' without elaborating on what that entails or how the tool behaves.

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 description is extremely concise (5 words) and front-loaded with the verb. However, it sacrifices informativeness for brevity.

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

Completeness2/5

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

Even though the tool has zero parameters and an output schema exists, the description omits essential context: what 'daemon-centric' means, possible statuses, or how the output should be interpreted. This leaves the agent underinformed.

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?

There are no parameters, and schema coverage is trivially 100%. The description does not need to add parameter information, so a baseline of 4 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 action ('Return') and the resource ('readiness status'), with a specific qualifier ('daemon-centric'). It distinguishes the tool from siblings like 'requantize_knowledge' or 'search_mcp_plesk_dev_docs' by indicating a health-check purpose.

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?

No guidance is given on when to use this tool versus alternatives (e.g., 'check_sync_status' or 'trigger_index_sync'). The description provides no context about prerequisites or appropriate scenarios.

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

get_file_contentA

Retrieve the full content of a specific documentation file.

Use this when you have a filename from a search result and need more context than what was provided in the search snippets.

ParametersJSON Schema

Name	Required	Description	Default
`category`	Yes	Supported Plesk documentation categories.
`filename`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/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 full burden. It describes a read operation ('Retrieve') with no side effects mentioned. While the behavior is clear for a simple retrieval, it could disclose more, such as whether the operation is read-only or any potential 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, front-loaded with the purpose, and contains no unnecessary words. Every sentence adds value: the first states the action, the second provides usage context.

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 need not be explained. The description covers purpose and typical use case (from search result). However, it does not mention any constraints like file size limits or error conditions, but given the simple nature, it is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (only 'category' described). The description does not elaborate on the 'filename' parameter, which lacks a schema description, missing an opportunity to clarify its format or origin. The description only mentions 'filename from a search result' implicitly, not directly explaining the parameter.

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 'Retrieve the full content of a specific documentation file,' specifying the verb and resource. It distinguishes itself from the sibling tool 'search_mcp_plesk_dev_docs' by explicitly stating the use case of retrieving full content when a filename is known from a search result.

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 provides explicit guidance: 'Use this when you have a filename from a search result and need more context than what was provided in the search snippets.' This tells when to use it and implies it builds on the search tool, but does not explicitly exclude other uses or mention alternatives beyond the one sibling.

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

list_model_profilesA

List built-in model profiles and show the active profile.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 must fully disclose behavioral traits. It implies read-only behavior ('list', 'show') but does not explicitly state that the tool has no side effects or destructive potential. The description is minimally adequate but lacks depth.

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 containing two clear actions. Every word serves a purpose with no redundancy or fluff. It is highly concise.

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 zero parameters and the presence of an output schema, the description sufficiently covers the tool's purpose. It explains what the tool does (list profiles, show active) without needing to detail return values, as that is handled by the output schema.

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%. According to the guidelines, zero parameters yields a baseline score of 4. The description does not add parameter info (none needed), so this score 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 'List built-in model profiles and show the active profile' clearly states the verb 'list' and the resource 'model profiles', with an additional action 'show active'. This distinguishes it from sibling tools like 'requantize_knowledge' or 'warmup_server', which have entirely different purposes.

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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. While the purpose is clear, there is no contextual advice for the agent's decision-making.

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

refresh_knowledgeA

Index Plesk documentation into LanceDB.

This tool provides a blocking refresh that returns a report of the indexing operation. For very large documentation sets, use trigger_index_sync instead.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No		all
`reset_db`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It mentions blocking behavior and returns a report, but lacks disclosure about side effects of reset_db, data deletion, or permissions. Leaves some behavioral gaps.

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, front-loaded with purpose. No extraneous information.

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

Completeness2/5

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

While output schema likely covers return values, the tool has no annotations and 0% schema parameter coverage. Description fails to explain parameters or behavioral details like reset_db effects. Incomplete for confident usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain any parameters (category, reset_db). The agent would have to infer from schema alone, which is insufficient.

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 indexes Plesk documentation into LanceDB, using a specific verb and resource. It distinguishes itself from the sibling trigger_index_sync by noting the blocking behavior.

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 states when to use (blocking refresh) and when not (for very large sets, use trigger_index_sync instead). Provides clear context for choosing between tools.

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

requantize_knowledgeB

Rebuild the TurboQuant index from stored vectors.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral transparency. It only mentions rebuilding an index but does not disclose side effects, resource usage, idempotency, or concurrency implications. This is minimal transparency for a potentially impactful operation.

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, concise sentence with no wasted words. It is front-loaded with the action and resource.

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?

Given the tool has zero parameters and an output schema exists, the description is minimally adequate. However, it could be more complete by mentioning whether the rebuild is safe to run concurrently, if it requires a locked state, or typical duration. For a simple rebuild action, it is acceptable but not thorough.

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 schema coverage is 100%. The description does not need to add parameter details. Per guidelines, 0 parameters baseline is 4.

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 verb 'Rebuild' and the resource 'TurboQuant index from stored vectors', making the action specific. However, it does not differentiate from sibling tools like refresh_knowledge or trigger_index_sync, which might have similar purposes.

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?

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or contextual usage hints. The description lacks any when-to-use or when-not-to-use information.

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

resolve_referencesA

Find other files that reference a specific symbol or topic.

Useful for finding usage examples of a class, method, or CLI command across the documentation.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`category`	Yes	Supported Plesk documentation categories.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 full burden. It states the tool finds references, but does not disclose behavioral traits such as return format, partial match behavior, or any side effects. It is adequate but not detailed.

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, front-loaded with the primary purpose, followed by a usage example. No extraneous information; every sentence is valuable.

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 simple two-parameter tool with an output schema, the description covers the essential purpose and usage. It could be improved by referencing the output format, but is largely complete for the tool's scope.

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 50% (only category has a description). The description adds meaning by explaining 'query' as a 'symbol or topic' and 'category' as 'Plesk documentation categories', but lacks format details or constraints beyond 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?

The description clearly states the tool finds files referencing a specific symbol or topic, with an explicit verb 'Find' and resource 'other files'. It distinguishes from siblings like 'search_mcp_plesk_dev_docs' by focusing on references specifically, not general search.

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 mentions usefulness for finding usage examples, implying when to use, but provides no explicit guidance on when not to use or alternative tools. Sibling tools suggest alternatives, but no comparison is made.

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

search_mcp_plesk_dev_docsC

Search the unified Plesk documentation for a specific query.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`category`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations present, the description must convey behavioral traits. It only states 'search' without explaining what the search returns (e.g., list of documents, snippets), whether it supports pagination, or any limitations. This is minimal information.

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

Conciseness3/5

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

The description is concise at one sentence, but could include more detail without becoming verbose. It is front-loaded with the action and resource, which is good.

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?

Given only two parameters and an output schema (though not shown), the description is adequate but fails to mention return format or any additional details that would fully prepare an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has two parameters, but only 'category' includes a description. The description does not explain the 'query' parameter beyond its type, nor does it clarify how the optional 'category' filter works. Overall, little value added beyond the schema.

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 verb 'search' and the resource 'unified Plesk documentation', making the tool's purpose obvious. However, it does not explicitly differentiate from sibling tools, though no sibling appears to have a similar purpose.

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?

No guidance is provided on when to use this tool versus alternatives, nor any context about prerequisites or limitations. The description is a single sentence with no usage hints.

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

trigger_index_syncC

Trigger a background indexing job for Plesk documentation.

Returns a job_id that can be used with check_sync_status.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No		all
`reset_db`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It discloses the background job trigger and job_id return, but fails to explain mutation, destructiveness, prerequisites, or side effects (e.g., what 'reset_db' does). The description is insufficient for safe use.

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, no fluff. It front-loads the action and return value, achieving maximum conciseness.

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

Completeness2/5

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

Given the tool triggers a background job, it lacks details on idempotency, side effects, and prerequisites. Parameters are unexplained. Despite an output schema existing, the description is incomplete for safe and correct agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not mention or explain any parameters. The 'reset_db' parameter especially needs clarification (e.g., does it reset the index?). The description adds no value over the bare schema.

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 verb 'trigger' and resource 'background indexing job for Plesk documentation', and mentions the return value. It distinguishes from the sibling 'check_sync_status' but not from other potential alternatives like 'refresh_knowledge'.

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 indicates when to use the tool (to trigger indexing) and what to do with the result (use with check_sync_status). However, it lacks explicit guidance on when not to use it or mention of alternative tools, leaving some ambiguity.

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

warmup_serverA

Preload the active profile models and table without running indexing.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states 'preload' without detailing side effects, idempotency, permissions, or whether it is a read-only operation. This is insufficient for an AI agent to safely invoke the 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 a single, efficient sentence that front-loads the key purpose and constraint ('without running indexing'). No unnecessary words.

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 has no parameters and an output schema exists (though not shown), the description adequately covers the tool's purpose. However, it could mention the output or behavior on repeated calls for full completeness.

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 description does not need to add parameter info. Baseline score of 4 is warranted as the schema coverage is 100% and no parameter documentation is needed.

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 verb 'preload' and the resource 'active profile models and table', and explicitly specifies it does so 'without running indexing', clearly distinguishing it from sibling tools like trigger_index_sync.

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 for preloading without indexing, but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites.

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. Dates show when Glama detected each change.

10 tool updatesv0.7.0Jul 29, 2026
- First observedcheck_sync_status
- First observeddaemon_health
- First observedget_file_content
- First observedlist_model_profiles
- First observedrefresh_knowledge
- First observedrequantize_knowledge
- First observedresolve_references
- First observedsearch_mcp_plesk_dev_docs
- First observedtrigger_index_sync
- First observedwarmup_server

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose. Search, file retrieval, reference resolution, indexing operations, system health, and profile management are all separate concerns with no overlapping functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., get_file_content, trigger_index_sync), but 'search_mcp_plesk_dev_docs' includes the server name, and 'daemon_health' is noun_noun. These minor deviations from the dominant pattern prevent a perfect score.

Tool Count5/5

With 10 tools, the set is well-scoped for a documentation server that includes indexing, search, and system health. Each tool serves a clear function without unnecessary bloat or sparseness.

Completeness4/5

The tool set covers the core lifecycle: indexing (refresh, trigger, check), search, retrieval, reference resolution, and system management. Minor gaps exist, such as the lack of a tool to list documentation sections or metadata, but these are not critical.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
mcp-server A
com.apple-rag
Apple Developer Documentation with Semantic Search, RAG, and AI reranking for MCP clients
RAG Systems Documentation Access Search
22116
Cerebrium Docs A
ai.cerebrium
Search the Cerebrium docs: deployment, cerebrium.toml, hardware, endpoints. Also sends feedback.
Documentation Access Developer Tools AI & Machine Learning
31
docs A
com.ntop
Search and query nTop's knowledge base and engineering guides from AI applications.
Search Documentation Access
32

Related MCP Servers

UseKeen Documentation MCP
Documentation Access Search
PromptMixerDev
A
license
Not graded
quality
D
maintenance
Enables AI assistants to search documentation of packages and services to find implementation details, examples, and specifications.
Updated a year ago (2025-05-08 02:00 UTC)
MIT
Plesk Extensions Guide MCP
RAG Systems Documentation Access Vector Databases
barateza
A
license
Not graded
quality
Not graded
maintenance
Provides semantic search capabilities over the Plesk Extensions Guide documentation using Retrieval-Augmented Generation (RAG) and vector embeddings. It enables AI assistants to retrieve relevant technical information and answer natural language queries regarding Plesk extension development.
Updated 7 months ago (2026-02-11 03:01 UTC)
-
Onec Platform Help MCP Server
RAG Systems Documentation Access Developer Tools
rzateev
A
license
Not graded
quality
F
maintenance
Provides a RAG-based search system for 1C:Enterprise platform documentation using hybrid BM25 and semantic search across multiple versions. It enables developers to retrieve API signatures, methods, and usage examples directly within IDEs or through a REST API.
Updated 7 months ago (2026-02-12 19:38 UTC)
22
MIT
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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/barateza/mcp-plesk-dev-docs'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mcp-plesk-dev-docs

Why this exists

Architecture & Performance

Performance Benchmarks (2026-05-04)

Key Features

MCP Components

Primary Tools

Resources

🚀 Installation & Setup

Option 1: Run instantly via uvx (Recommended)

1. Add to Claude Desktop

2. Configure in Cursor

Option 2: Local Developer Setup (Manual Build)

Configuration

Documentation

License

Ownership & Disclaimer

Important notice about Plesk-owned deliverables

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Option 1: Run instantly via `uvx` (Recommended)