A
licenseA
qualityF
maintenanceGenerate professional AI-powered presentations from a topic, raw text, or document file.
Export to PPTX, PDF, image, or shareable link.
5
1
MIT
Twistly AI Presentation Maker
by ai.twistly
Server Details
Twistly turns your ideas, notes, and documents into ready-to-edit PowerPoint presentations. Describe a topic, paste in text, or share a file (PDF, DOCX, PPTX, or TXT), and Twistly builds a structured deck of up to 50 slides with clear layouts and matching visuals in seconds. Pick from 50+ templates to keep a consistent, on-brand look.
Everything comes out as a native, fully editable .pptx file, not a web export, so it opens cleanly in PowerPoint with no broken layouts. Edit it by hand like any normal presentation, or use the Twistly add-in for PowerPoint to keep refining and redesigning your slides. Nothing stays locked in a separate editor.
Generation runs asynchronously: a tool call returns a job id, the assistant follows the job, and the finished deck arrives as a download link in the chat.
Used by students, educators, business professionals, and teams around the world.
Ownership verified
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
- Status
- Unhealthy
- Uptime
- 23.3% over 21 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.1/5.0
Scored across 4 tools
Disambiguation4/5
Three creation tools differ by input source (file, text, topic), which is mostly clear. However, create_from_file also accepts a text field, overlapping with create_from_text, which could cause slight confusion.
Naming Consistency5/5
All tools use consistent snake_case with a predictable verb_from_noun or get_noun pattern. No deviations.
Tool Count5/5
Four tools perfectly cover an async generation service: three input variants and one status poller. No redundancy or bloat.
Completeness4/5
The core submit-and-poll lifecycle is complete, and results are retrievable via status. Minor gaps: no cancel or list jobs, and no direct result retrieval beyond polling.
Available Tools
4 toolscreate_from_fileCreate presentation from a fileAInspect
Submit an async job that generates a presentation from a PDF, PPTX, DOCX, or TXT document. The document arrives in exactly one of the following ways. file: an attachment reference the host fills in for a document the user attached. The server fetches the bytes from it directly, so the document never passes through the conversation and its size is not a limit. The object is valid only as the host produced it — there is no way to compose one from the conversation. text: the document’s full content, with filename alongside it. This client has no way to hand an attached document to a tool, so its content reaches the server only through this field. The text is the entire source of the presentation — the backend sees nothing else, so summarised or truncated text yields a correspondingly reduced deck. file_url: an https URL the server downloads itself (with mime_type). file_base64: the encoded bytes (with mime_type), for small files. Returns a job_id; the result is read with get_job_status under that id.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| text | No | The document's full content as text. It is the only form in which this client's attachments reach a tool, and the only source the presentation is built from. | |
| format | No | ||
| file_url | No | ||
| filename | No | ||
| language | No | ||
| template | No | 'auto' (the default) has Twistly rank its built-in templates against the content and use the best match. Pass a template name only when the user explicitly asks for a specific one. On the free plan only these templates are available: NewYork, Houston, Cambridge, Seoul, Rome, Copenhagen, Pasadena, Tokyo, Berlin, Oslo, FlowerMound, Singapore, Doha, PalmSprings, Brussels — 'auto' also picks from them; any other name is refused for a free account with the error code template_not_available. | auto |
| mime_type | No | ||
| verbosity | No | How much text each slide carries: "short" for concise slides, "detailed" for fuller prose, "bulletPoints" for bulleted lists. Omit to let Twistly decide. | |
| num_slides | No | Number of slides. Omit this field (or pass -1) to let Twistly choose the best count automatically — do this whenever the user did not request a specific number. Pass 1-50 only when the user explicitly asked for that many. | |
| file_base64 | No | ||
| image_style | No | ||
| image_source | No | Where slide images come from. 'auto' (the default) generates AI images — keep it unless the user explicitly asks otherwise. Use 'pexels' or 'unsplash' ONLY when the user explicitly asks for stock photos, and 'scrapingdog' only when they ask for images found on the web. Not to be confused with image_style, which only styles AI-generated images. | auto |
| text_density | No | ||
| content_modificator | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| status | Yes | |
| created_at | Yes |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=false, openWorldHint=true, and idempotentHint=false. The description goes further by disclosing that this is an async job returning a job_id polled via get_job_status, and that a 'file' object is valid only as the host produced it. Useful additions, though it says nothing about cost, quotas, or failure modes beyond truncation.
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?
Front-loaded with the async-job mechanic and organized by input method, but it is delivered as one dense paragraph with no headings or bullets, making the four mutually exclusive input paths hard to scan. Content largely earns its place, but structure costs it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the description still covers the job_id/get_job_status workflow. With 15 parameters at 33% coverage, the main missing piece is the deck-shaping options (image_style, text_density, content_modificator, format), but the hardest part for an agent — how to supply the document — is thoroughly covered.
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 33%, below the 50% threshold, so the description must compensate. It does an excellent job on the mutex-like input fields (file, text, file_url, file_base64) and the consequence of truncated text, but it says nothing about format, filename, language, image_style, text_density, or content_modificator, leaving half the customization surface unexplained.
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?
Names a specific verb+resource ('submit an async job that generates a presentation from a PDF, PPTX, DOCX, or TXT document') and frames the tool by its input modality, which is exactly how it differs from create_from_text and create_from_topic. An agent can route between the three siblings without opening a schema.
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?
It gives detailed guidance on which input field to use (file vs text vs file_url vs file_base64) and warns that truncated text reduces the deck, which is strong parameter-choice guidance. However, it never names or contrasts the sibling tools, so the choice between this tool, create_from_text, and create_from_topic is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_from_textCreate presentation from textAInspect
Submit an async job that turns provided text into a presentation. Returns a job_id; the result is read with get_job_status under that id. Very long text is rejected by the backend token limit.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| format | No | ||
| language | No | ||
| template | No | 'auto' (the default) has Twistly rank its built-in templates against the content and use the best match. Pass a template name only when the user explicitly asks for a specific one. On the free plan only these templates are available: NewYork, Houston, Cambridge, Seoul, Rome, Copenhagen, Pasadena, Tokyo, Berlin, Oslo, FlowerMound, Singapore, Doha, PalmSprings, Brussels — 'auto' also picks from them; any other name is refused for a free account with the error code template_not_available. | auto |
| verbosity | No | How much text each slide carries: "short" for concise slides, "detailed" for fuller prose, "bulletPoints" for bulleted lists. Omit to let Twistly decide. | |
| num_slides | No | Number of slides. Omit this field (or pass -1) to let Twistly choose the best count automatically — do this whenever the user did not request a specific number. Pass 1-50 only when the user explicitly asked for that many. | |
| image_style | No | ||
| image_source | No | Where slide images come from. 'auto' (the default) generates AI images — keep it unless the user explicitly asks otherwise. Use 'pexels' or 'unsplash' ONLY when the user explicitly asks for stock photos, and 'scrapingdog' only when they ask for images found on the web. Not to be confused with image_style, which only styles AI-generated images. | auto |
| text_density | No | ||
| content_modificator | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| status | Yes | |
| created_at | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag non-readonly, open-world, non-idempotent behavior, and the description adds the genuinely useful traits: it is asynchronous, returns a job_id, requires polling, and that oversized text is refused by a backend token limit. That is real context beyond the 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?
Three short sentences, front-loaded with what the tool does and the async handoff, then the constraint. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The async lifecycle, the job_id handoff and the failure mode for long text are all covered, and an output schema exists so return-shape detail is unnecessary. For a 10-parameter generation tool the remaining uncovered options are documented in the schema itself, so completeness is good but not exhaustive.
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 only 40%, so the description carries partial burden; it clarifies the text input's practical limit (backend token rejection) which the maxLength of 2000000 characters does not express in token terms. It says nothing about format, language, image_style, text_density or content_modificator, which are undocumented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Submit'), resource ('text into a presentation') and mechanism ('async job'), which cleanly separates it from create_from_file and create_from_topic without needing the schema.
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?
Explicitly says the result must be read via get_job_status under the returned job_id, giving the agent the follow-up step. It does not, however, state explicitly when to prefer this over create_from_file/create_from_topic, leaving that to inference from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_from_topicCreate presentation from a topicAInspect
Submit an async job that generates a presentation from a short topic prompt. Returns a job_id; the result is read with get_job_status under that id.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| format | No | ||
| content | No | ||
| language | No | ||
| template | No | 'auto' (the default) has Twistly rank its built-in templates against the content and use the best match. Pass a template name only when the user explicitly asks for a specific one. On the free plan only these templates are available: NewYork, Houston, Cambridge, Seoul, Rome, Copenhagen, Pasadena, Tokyo, Berlin, Oslo, FlowerMound, Singapore, Doha, PalmSprings, Brussels — 'auto' also picks from them; any other name is refused for a free account with the error code template_not_available. | auto |
| num_slides | No | Number of slides. Omit this field (or pass -1) to let Twistly choose the best count automatically — do this whenever the user did not request a specific number. Pass 1-50 only when the user explicitly asked for that many. | |
| image_style | No | ||
| image_source | No | Where slide images come from. 'auto' (the default) generates AI images — keep it unless the user explicitly asks otherwise. Use 'pexels' or 'unsplash' ONLY when the user explicitly asks for stock photos, and 'scrapingdog' only when they ask for images found on the web. Not to be confused with image_style, which only styles AI-generated images. | auto |
| tone_and_style | No | ||
| target_audience | No | ||
| presentation_type | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| status | Yes | |
| created_at | Yes |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds valuable behavioral context: it is an asynchronous job and the output must be fetched via get_job_status using the returned job_id. This goes beyond the annotations and is crucial for correct invocation.
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 core action and then the retrieval instruction. 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?
The description adequately covers the async workflow and result retrieval, which is important given the output schema. However, for an 11-parameter tool with only 27% schema description coverage, the description is incomplete because it offers no guidance on the many undocumented parameters, leaving the agent to infer their semantics.
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 low (27%), with only template, num_slides, and image_source documented in the schema. The description provides no parameter-level information at all, so it fails to compensate for the undocumented parameters like format, content, language, tone_and_style, target_audience, and presentation_type.
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 states a specific verb (Submit an async job) and resource (a presentation) from a short topic prompt, clearly distinguishing it from file- or text-based siblings. However, it does not explicitly name alternatives like create_from_file or create_from_text, so it misses the top tier for sibling differentiation.
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 usage context: it is an async job that returns a job_id, and the result is read with get_job_status. This tells the agent how to retrieve the result, but it does not state when to prefer this tool over create_from_file or create_from_text, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_statusGet presentation job statusARead-onlyIdempotentInspect
Return the current status of a generation job. A completed job carries result.url, a direct download link to the generated .pptx file. Generation runs for minutes: with wait=true the call holds open until the job settles or ~45 seconds pass, with wait=false it answers with the status at that moment. A job that is still processing when the call returns keeps running and stays readable under the same job_id.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | true holds the call open until the job settles or ~45 seconds pass, so a job that finishes inside that window is covered by a single call. false answers immediately with the status at that moment. | |
| job_id | Yes | The job_id returned by a create_* tool. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| job_id | Yes | |
| result | No | |
| status | Yes | |
| message | No | |
| template | No | The template the deck is being/was built with; appears once resolved. |
| created_at | Yes | |
| completed_at | No |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description adds essential behavior: jobs can run for minutes, wait=true holds the call open up to ~45 seconds, wait=false returns immediately, and an in-progress job continues under the same job_id. This meaningfully enriches the annotation-only view without contradicting it.
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?
Three sentences, each earning its place: the core purpose, the output signal, and the wait behavior. The most important fact is front-loaded, and the later sentences expand on operational details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With rich annotations, a complete schema, and an output schema present, the description covers the remaining operational nuance: long-running generation, wait-timeout behavior, and persistence after return. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters already carry their meaning. The description reinforces the wait semantics and ties job_id to create_* tools, but it does not add materially new parameter-level information beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return the current status of a generation job.' It further defines what a completed job returns (result.url, direct .pptx link), clearly separating it from the sibling create_* tools, which are about launching jobs rather than checking them.
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 gives clear context for when this tool is relevant—checking generation jobs—and explains the two wait modes so an agent can choose the right behavior. It does not explicitly name exclusions or alternatives, but given that all siblings are creation tools, no alternative is needed.
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.
3 tool updates
- Changed
create_from_file1 field changed- changed
Input schema / properties / image_style / enumPrevious value: -[ - "auto", - "photorealistic", - "illustration", - "neon", - "abstract", - "black-and-white", - "3d", - "linear", - "painterly", - "silk", - "dramatic", - "holographic" -]New value: +[ + "auto", + "photorealistic", + "illustration", + "neon", + "abstract", + "black-and-white", + "3d", + "linear", + "painterly", + "silk", + "dramatic", + "holographic", + "glass-abstract" +]
- Changed
create_from_text1 field changed- changed
Input schema / properties / image_style / enumPrevious value: -[ - "auto", - "photorealistic", - "illustration", - "neon", - "abstract", - "black-and-white", - "3d", - "linear", - "painterly", - "silk", - "dramatic", - "holographic" -]New value: +[ + "auto", + "photorealistic", + "illustration", + "neon", + "abstract", + "black-and-white", + "3d", + "linear", + "painterly", + "silk", + "dramatic", + "holographic", + "glass-abstract" +]
- Changed
create_from_topic1 field changed- changed
Input schema / properties / image_style / enumPrevious value: -[ - "auto", - "photorealistic", - "illustration", - "neon", - "abstract", - "black-and-white", - "3d", - "linear", - "painterly", - "silk", - "dramatic", - "holographic" -]New value: +[ + "auto", + "photorealistic", + "illustration", + "neon", + "abstract", + "black-and-white", + "3d", + "linear", + "painterly", + "silk", + "dramatic", + "holographic", + "glass-abstract" +]
3 tool updates
- Changed
create_from_file1 field changed- changed
Input schema / properties / template / descriptionPrevious value: -"'auto' (the default) has Twistly rank its built-in templates against the content and use the best match. Pass a template name only when the user explicitly asks for a specific one."New value: +"'auto' (the default) has Twistly rank its built-in templates against the content and use the best match. Pass a template name only when the user explicitly asks for a specific one. On the free plan only these templates are available: NewYork, Houston, Cambridge, Seoul, Rome, Copenhagen, Pasadena, Tokyo, Berlin, Oslo, FlowerMound, Singapore, Doha, PalmSprings, Brussels — 'auto' also picks from them; any other name is refused for a free account with the error code template_not_available."
- Changed
create_from_text1 field changed- changed
Input schema / properties / template / descriptionPrevious value: -"'auto' (the default) has Twistly rank its built-in templates against the content and use the best match. Pass a template name only when the user explicitly asks for a specific one."New value: +"'auto' (the default) has Twistly rank its built-in templates against the content and use the best match. Pass a template name only when the user explicitly asks for a specific one. On the free plan only these templates are available: NewYork, Houston, Cambridge, Seoul, Rome, Copenhagen, Pasadena, Tokyo, Berlin, Oslo, FlowerMound, Singapore, Doha, PalmSprings, Brussels — 'auto' also picks from them; any other name is refused for a free account with the error code template_not_available."
- Changed
create_from_topic1 field changed- changed
Input schema / properties / template / descriptionPrevious value: -"'auto' (the default) has Twistly rank its built-in templates against the content and use the best match. Pass a template name only when the user explicitly asks for a specific one."New value: +"'auto' (the default) has Twistly rank its built-in templates against the content and use the best match. Pass a template name only when the user explicitly asks for a specific one. On the free plan only these templates are available: NewYork, Houston, Cambridge, Seoul, Rome, Copenhagen, Pasadena, Tokyo, Berlin, Oslo, FlowerMound, Singapore, Doha, PalmSprings, Brussels — 'auto' also picks from them; any other name is refused for a free account with the error code template_not_available."
4 tool updates
- First observed
create_from_file - First observed
create_from_text - First observed
create_from_topic - First observed
get_job_status
Publisher details
- Operator
- Twistly · Publisher source
- Operator website
- https://twistly.ai/ · Publisher source
- Vendor relationship
- First-party · Publisher source
- Documentation
- https://twistly.ai/mcp/ · Publisher source
- Trust center
- Not available
- Restrictions
- No paid plan, admin approval, regional restriction or custom OAuth app is needed to connect: signing in with Google, Microsoft or an email code creates the account. Usage is metered in AI credits — a new free account starts with 60 credits and each generated deck costs 20, and on the free plan a deck built from a topic is capped at 10 slides. Paid plans raise the slide limit and replace the credit balance with a daily generation quota. · Publisher source
Related MCP Connectors
Create professionally designed, editable PowerPoint presentations from a prompt.
Generate polished PowerPoint presentations from text prompts, YouTube videos, or structured outlin…
Create consulting-style presentation decks (editable PowerPoint) from a topic or notes.
1Generate professional PowerPoint presentations from text, YouTube videos, or structured JSON data.…
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables AI-powered generation of PowerPoint presentations with dynamic content, themes, and tones. Supports custom topics, audience, and slide count via the generate_ppt tool.-
- AlicenseAqualityDmaintenanceCreates and manipulates PowerPoint presentations with capabilities for adding various slide types, generating images, and incorporating tables and charts through natural language commands.11144MIT
- FlicenseNot gradedqualityBmaintenanceEnables Claude Desktop users to generate structured, editable PowerPoint decks from a natural-language brief and slide-count settings by triggering the n8n presentation pipeline. Returns the generated title, presentation ID, and a downloadable PPTX link.-
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.