ai-slides-mcp

by vuhai2002

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are mostly distinct: branded_deck uses a logo, styled_deck uses a reference image, generate_slide_deck uses text prompts, and build_pptx assembles existing images. login_status is orthogonal. Minor potential confusion between branded_deck and styled_deck but descriptions clarify.
Naming Consistency3/5
Naming is inconsistent: some use verb_noun (build_pptx, generate_image), others use adjective_noun (branded_deck, styled_deck), and login_status follows a different pattern. No strong convention is maintained across the set.
Tool Count4/5
6 tools is a reasonable count for a slide generation server. Each serves a distinct purpose in the creation workflow, and the number feels well-scoped without being too sparse or bloated.
Completeness4/5
The tool surface covers key slide generation capabilities: creating from prompts, logos, reference styles, and assembling existing images. Minor gaps like editing existing decks or converting formats are acceptable for the stated purpose.
Average 3.5/5 across 6 of 6 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 18 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
Without annotations, the description must disclose behavioral traits. It mentions 'full-bleed' but does not explain what that entails (e.g., margins, image scaling). No details on ordering, resizing, or file handling, leaving significant behavioral ambiguity.
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 a single concise sentence, but it lacks essential detail. While not verbose, it sacrifices completeness for brevity, so it does not earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and any parameter descriptions, the description is severely incomplete. It fails to explain critical aspects like image order, aspect ratio handling, output location, or potential errors.
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 any parameters or their semantics. The agent must rely solely on parameter names (image_paths, out_path, aspect) which are insufficient for correct invocation.
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's purpose: 'Assemble existing image files into a full-bleed PowerPoint deck.' The verb 'assemble' and resource 'existing image files' give a specific action, and it is distinct from sibling tools like generate_image or styled_deck, though not explicitly differentiated.
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 like branded_deck or generate_slide_deck. The description does not include context, prerequisites, or exclusions, leaving the agent to infer usage.
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?
No annotations are provided, so the description carries the full burden. It mentions style copying and not content copying but does not disclose potential side effects, output file creation, or required permissions. The tool creates files but this is not stated.
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 single-sentence description is concise and front-loaded with the key action, but it lacks structure and fails to earn its place for parameter details.
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's complexity (5 params, no output schema, no annotations), the description is incomplete. It does not explain parameters, return values, or behavior beyond the basic purpose.
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?
With 0% schema description coverage and 5 parameters, the description adds no meaning beyond the schema. Only 'ref_image' is indirectly explained by 'matching a reference design image's style and colors'. Prompts, aspect, out_pptx, out_dir are unmentioned.
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 'Generate a deck matching a reference design image's style and colors (content not copied)' clearly states the specific verb ('Generate'), resource ('deck'), and what distinguishes it from similar tools (style matching, not content copying).
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 context (when you want a deck styled like a reference image) but provides no explicit guidance on when to use this tool versus siblings like branded_deck or generate_slide_deck, nor any exclusion criteria.
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 provided, so description carries full burden. It discloses the process steps (auto-detect colors, generate slides, composite logo, assemble PPTX) but lacks details on side effects, file overwrites, or required permissions. Moderate transparency.
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?
Single sentence that front-loads purpose and is efficient, but could be broken into structured steps for readability. No wasted words.
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?
With 7 parameters, no output schema, and no annotations, the description is too minimal. It does not explain parameter roles, output specifics, or error handling, leaving significant gaps.
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 elaborate on any of the 7 parameters. Only hints at 'logo' and 'prompts' implicitly. Fails to add meaning beyond the schema's default titles.
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 builds a branded slide deck with auto-detection of brand colors, slide generation, logo compositing, and PPTX assembly. It distinguishes from siblings like 'styled_deck' by emphasizing auto-detection from logo.
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?
Description implies use when needing a branded deck with logo-based color detection, but does not explicitly state when not to use or compare with alternatives like 'generate_slide_deck' or 'styled_deck'. Clear context without exclusions.
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?
Description implies a read-only check with no side effects, but lacks details on what happens when not logged in, error conditions, or return behavior. Since no annotations exist, the description carries the full burden but provides only basic transparency.
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?
Description is a single concise sentence front-loading the core purpose with no wasted words.
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?
Tool is simple with no parameters or output schema, but description does not specify the return type (e.g., boolean or status string), leaving room for ambiguity. Agent would benefit from knowing what the output represents.
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?
No parameters, so schema coverage is 100%. Baseline is 4; description adds no extra meaning beyond the empty schema, which is acceptable.
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 checks login status for image generation, using specific verb and resource. It implicitly distinguishes from sibling tools which generate content.
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 on when to use this tool versus alternatives. Although it is implicitly a precondition for image generation, the description does not explicitly state that it should be used before calling generate_image or other tools.
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?
No annotations provided, but the description discloses the auto-expansion behavior when 'enhance' is True and explains the style behaviors. It also states the output format (PNG file paths). Does not cover auth or rate limits, but reasonable for this tool.
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 well-structured with clear sections for aspect ratios and styles, but somewhat long. Core purpose is front-loaded. Could be slightly more concise by moving style details to secondary position.
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 no output schema and 6 parameters, the description covers input, key behaviors, and output format. Missing details on aspect format constraints and error handling, but generally complete.
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 has 0% description coverage; the description compensates by explaining 'prompt', 'aspect' with examples, 'enhance', 'style'. However, 'out_dir' is not explained, and 'n' is only implicitly mentioned.
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 generates image(s) from a text prompt with given aspect ratio and returns PNG file paths. It distinguishes from sibling tools like 'styled_deck' which are deck-focused.
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 when to use 'enhance' and describes specific styles ('slide', 'fintech'), but does not explicitly state when not to use this tool or compare to alternatives like 'styled_deck'.
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 provided, the description carries the full burden. It discloses the core behavior (generating images and assembling into PPTX) and explains the effect of the style and enhance parameters. It does not contradict any annotations and adds sufficient context for safe invocation.
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 efficient, with the main action in the first sentence. Subsequent sentences add necessary detail without fluff. Slightly longer than ideal but earns its length.
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 6 parameters and no output schema, the description covers the purpose, all parameters, and behavioral choices. It does not discuss return values or errors, but for a generation tool this is acceptable. It provides enough context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning to each parameter: 'prompts' as 'CONTENT of one slide', explains the default style, and clarifies the enhance flag. This goes well beyond the raw schema, making the parameters understandable.
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 starts with 'Generate one image per prompt then assemble them into a PPTX deck,' clearly stating the verb and resource. It distinguishes from siblings by detailing the style and enhance options, which are specific to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using the style parameter ('style='slide' (default here) applies a clean editorial presentation design') and the enhance parameter ('Set enhance=False to send prompts verbatim'). It implies the intended use case for slide decks but does not explicitly mention when not to use it or alternatives.
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:

[![ai-slides-mcp MCP server](https://glama.ai/mcp/servers/vuhai2002/ai-slides-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vuhai2002/ai-slides-mcp)

Score Badge

Copy to your README.md:

[![ai-slides-mcp MCP server](https://glama.ai/mcp/servers/vuhai2002/ai-slides-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vuhai2002/ai-slides-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/vuhai2002/ai-slides-mcp'

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