slidev-orchestrator-mcp

by death-joke

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.3
Disambiguation5/5
Each tool targets a distinct action: listing presentations, creating presentations, starting/stopping servers, checking server status, selecting a presentation, and calling a slidev tool. No two tools have overlapping purposes.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (list_presentations, create_presentation, start_server, stop_server, select_presentation, call_slidev_tool). The exception is server_status, which is noun_noun; renaming it to get_server_status or list_servers would make the naming fully consistent.
Tool Count5/5
With 7 tools, the server is well-scoped for its purpose of orchestrating Slidev presentations and their dev servers. Each tool earns its place and the count is not overwhelming.
Completeness5/5
The server covers the full lifecycle of presentation scaffolding and server management (create, list, start, stop, status), and provides access to the official Slidev MCP for editing slides. No major gaps are apparent for the stated purpose.
Average 4/5 across 7 of 7 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states the basic action without mentioning side effects (e.g., whether it kills the process, what happens if no server is running, or if it waits for shutdown). This is a significant gap for a mutation 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, clear sentence with no fluff. It is appropriately sized for the minimal information provided and is front-loaded with the action.
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 has one required parameter with no schema description and no annotations, the description is not complete enough. It omits parameter semantics, prerequisites, potential error conditions, and any information about the expected outcome beyond the basic action.
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 single parameter 'name' has no description in the schema (0% coverage), and the description does not explicitly explain what 'name' refers to. It implies 'name' is the presentation name via 'of a presentation,' but this is not directly stated, leaving ambiguity about the exact value to pass.
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 (stop) and the resource (the running Slidev dev server of a presentation). It is specific and distinguishes from siblings like start_server by indicating the opposite action.
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 'running Slidev dev server' implies it should be used when a server is active, but the description does not explicitly state when to use this tool versus alternatives like start_server or server_status. No clear context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It mentions 'passthrough' but does not disclose error handling when the called tool doesn't exist, whether a presentation must be selected first, whether the operation is read-only or potentially destructive, or what the return format looks like. An arbitrary tool invoker needs more safety context.
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 exactly two sentences, front-loaded with the core purpose and followed by the use-case context. Every word earns its place; there is no fluff or repetition. This is nearly ideal concision.
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 this is a passthrough to an unknown set of tools, the description is incomplete. It doesn't explain how a client should discover valid tool names, what happens if the tool is not found, whether a presentation must be actively selected, or whether the output is simply the underlying tool's output. With no output schema and no annotations, the description should convey more about expected behavior and prerequisites.
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% with both parameters described. The 'tool' parameter is well-described as 'Original tool name on the Slidev MCP', and 'args' is described as 'Arguments for that tool'. The description itself adds no additional parameter semantics beyond the schema, so the baseline of 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 clearly states a specific verb ('call'), resource ('tool of the currently targeted presentation's official Slidev MCP'), and mechanism ('by its original name'). It also distinguishes itself from the sibling tools by being a 'fallback passthrough' rather than a concrete operation, making its role clear.
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 identifies when to use this tool: 'Useful for MCP clients that do not support dynamic tool list updates (tools/list_changed)'. It implies that for supporting clients, the direct tools should be used instead, though it doesn't name specific alternatives. This gives clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It mentions that the tool returns the local URL and that ports are auto-allocated unless specified, which adds some behavioral context. However, it does not disclose side effects such as background process management, port conflict handling, or state changes beyond starting the server.
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 core action, then the return value, then the port behavior. No filler or redundant phrases—every sentence contributes useful information.
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 tool with two parameters and no output schema, the description provides the essential info needed for correct invocation: what it does, what it returns, and how port allocation works. It could mention prerequisites or cleanup steps, but those are not necessary for basic use and are partly covered by sibling tools like stop_server.
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 schema already provides 100% coverage for both parameters, so the baseline is 3. The description adds value by clarifying that ports are automatically allocated unless the optional 'port' parameter is provided, which goes beyond the schema's simple 'Optional fixed port' description. 'For a presentation' also reinforces the meaning of the 'name' parameter as a folder name.
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 starts the Slidev dev server for a presentation, which is a specific action on a specific resource. It is distinct from sibling tools like stop_server and server_status, so there is no ambiguity about its 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?
The description provides no explicit guidance on when to use this tool vs alternatives like stop_server or server_status. It implies usage by stating 'Start the Slidev dev server' but does not mention prerequisites, exclusions, or when alternatives are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses the created files and the npm install side effect, including the install=false override, which is useful. However, it does not mention behavior if the target folder already exists, potential overwrites, or the return value, leaving some uncertainty.
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 verb and resource, no fluff. The install behavior is clearly appended as a conditional, making it easy to scan.
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 is a simple scaffold operation with complete schema documentation; the description covers the main action and side effects. Gaps include no output schema or return value details and no mention of error cases, but the essential invocation context is present.
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 schema provides complete coverage for all four parameters, giving a baseline of 3. The description adds some context by clarifying that install controls npm install and that the tool scaffolds a folder with slides.md and package.json, but it doesn't add significant meaning 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 uses a specific verb ('scaffold') plus resource ('new Slidev presentation') and details what is created (folder + slides.md + package.json), clearly distinguishing it from the sibling tools that list, start, stop, select, or call presentations.
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 implies when to use the tool—when a new Slidev presentation is needed—by specifying the scaffolding behavior. It doesn't explicitly exclude alternatives or state when not to use, but the distinct creation purpose provides clear context relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key side effect (selecting a new presentation replaces the previous target) and the dynamic tool exposure behavior. It does not mention potential failure modes or whether the previous server connection is terminated, but the core state-changing behavior is clearly stated.
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 primary action, and the second sentence provides essential behavioral context without redundancy. 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 tool with a single parameter and no output schema, the description covers the core functionality and the essential state-changing behavior. It could additionally mention prerequisites (e.g., server must be running, use list_presentations to get names), but it is mostly 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 coverage is 100% with the parameter 'name' described as 'Presentation folder name'. The description adds no additional meaning about the parameter, such as how to discover valid names, so it stays at the schema baseline without adding value.
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 ('Target') with a clear resource ('a presentation') and explains the mechanism (connects to a server, exposes slidev_* tools). It clearly distinguishes from siblings like list_presentations and create_presentation by focusing on selection.
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 implies this is a prerequisite for using the dynamically exposed slidev_* tools, which gives clear situational context. However, it does not explicitly name alternatives or exclusion criteria, leaving room for more explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds value by revealing the exact root directory and the rule for identifying presentations. It does not specify the output format or error behavior, but for a simple list operation the core behavior is well conveyed.
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 concise sentences, front-loaded with the main purpose and immediately followed by a clarifying definition. No wasted 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?
For a simple no-parameter list tool, the description is nearly complete. It defines the scope and identification rule. However, it does not explicitly state what the returned list contains (e.g., folder names, paths), which would be useful given the absence of an 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, so the baseline is 4. There are no parameter semantics to explain; the description appropriately focuses on the listing behavior rather than 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 clearly states the tool lists Slidev presentations, specifies the resource (presentations in /app), and defines what qualifies (sub-folder with slides.md). This distinguishes it from sibling tools like create_presentation or start_server, which perform different actions.
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 clear context about scope (root directory /app and the criterion for a presentation), implying its use for discovery before other operations. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It explicitly notes that only 'currently running' servers are listed and specifies the return fields (name, port, URL, pid), giving the agent a clear picture of the tool's read-only behavior and output. No side effects or prerequisites are mentioned, but for a simple list operation this is adequate.
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, resource, and output format without any wasted words. It is optimally concise and well-structured.
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, zero parameters, and absence of an output schema, the description is complete: it states what the tool does and what information is returned. There are no ambiguities left for the agent.
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 schema fully covers parameter semantics. The description adds context about the scope (all running servers) but doesn't need to explain parameter details, aligning with the baseline score of 4 for parameterless tools.
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 the specific verb 'List' and identifies the resource as 'currently running Slidev dev servers', with the exact output fields (name, port, URL, pid). This clearly distinguishes it from sibling tools like start_server and stop_server, which handle server lifecycle operations.
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 makes it clear that this tool is for viewing current server status, which implies its use when you need to check running servers. While it doesn't explicitly name alternatives or exclusions, the sibling tool names make the context obvious, so the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![slidev-orchestrator-mcp MCP server](https://glama.ai/mcp/servers/death-joke/slidev-orchestrator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/death-joke/slidev-orchestrator-mcp)

Score Badge

Copy to your README.md:

[![slidev-orchestrator-mcp MCP server](https://glama.ai/mcp/servers/death-joke/slidev-orchestrator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/death-joke/slidev-orchestrator-mcp)

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/death-joke/slidev-orchestrator-mcp'

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