Skip to main content
Glama
cphoskins
by cphoskins

gamma-app-mcp

MCP server for Gamma.app — generate presentations, documents, webpages, and social posts via the Gamma Public API v1.0. Full parameter surface including templates, folders, headers/footers, and email sharing.

Features

  • Generate from text — presentations, documents, webpages, and social posts with the full v1.0 parameter surface

  • Generate from template — swap content into an existing Gamma template, preserving layout (ideal for batch variants)

  • Poll generation status — async job tracking with share URL, export URL, and credit usage

  • List workspace themes — discover real theme IDs (no more hardcoded fallbacks)

  • List workspace folders — paginated folder discovery for output organization

  • Describe options — local enum introspection so LLMs can look up valid values without trial and error

  • Structured error surfacing — Gamma API error codes and payloads flow through instead of being swallowed

  • Input validation — char limits, enum checks, and format/dimension compatibility verified before network calls

Related MCP server: Gamma MCP Server

Installation

pip install gamma-app-mcp

Or install from source:

git clone https://github.com/cphoskins/gamma-app-mcp.git
cd gamma-app-mcp
pip install -e .

Configuration

Get your API key

  1. Log in to Gamma.app

  2. Go to Account Settings > API Keys (https://gamma.app/settings/api-keys)

  3. Generate a key

API key access requires a Pro, Ultra, Teams, or Business plan.

Claude Code

claude mcp add gamma -s user \
  -e GAMMA_API_KEY=sk-gamma-your-key-here \
  -- gamma-app-mcp

Claude Desktop / other stdio hosts

Add to your client config:

{
  "mcpServers": {
    "gamma": {
      "command": "gamma-app-mcp",
      "env": {
        "GAMMA_API_KEY": "sk-gamma-your-key-here"
      }
    }
  }
}

Environment variables

Variable

Required

Description

GAMMA_API_KEY

Yes

Your Gamma API key (Account Settings > API Keys)

GAMMA_BASE_URL

No

Override the public API base URL (default: https://public-api.gamma.app)

Tools

Tool

Purpose

gamma_generate

Create a presentation, document, webpage, or social post from text. Full control over format, themes, images, headers/footers, folders, sharing, and export.

gamma_generate_from_template

Create a variant from an existing Gamma template (gammaId), swapping content while preserving layout.

gamma_get_status

Poll a generation job by generationId until status is completed or failed. Returns gammaUrl, exportUrl, and credit usage.

gamma_list_themes

List themes in the authenticated workspace (standard + custom, 50+ themes). Cursor-paginated with query/limit/after — matching gamma_list_folders. Surfaces errors instead of falling back to hardcoded defaults.

gamma_list_folders

List workspace folders the authenticated user is a member of, with query filter and cursor pagination.

gamma_describe_options

Local lookup of accepted enum values for API parameters — no network call.

Example workflow

1. Simple presentation

# Via MCP:
gamma_generate(
    input_text="Q3 2026 board update — ARR, burn, hiring plan, risks.",
    format="presentation",
    num_cards=12,
    text_options={"amount": "detailed", "tone": "professional", "audience": "board members"},
    image_options={"source": "aiGenerated", "style": "clean editorial"},
    card_options={"dimensions": "16x9"},
    export_as="pdf",
)
# -> {"generationId": "abc123...", "status": "submitted"}

gamma_get_status("abc123...")
# -> {"status": "completed", "gammaUrl": "https://gamma.app/docs/...", "exportUrl": "...", "credits": {...}}

2. Template-based batch variant

# Discover theme and folder IDs
gamma_list_themes()
gamma_list_folders(query="Investor")

# Generate from an existing 1-page template
gamma_generate_from_template(
    prompt="Personalized intro deck for Acme Corp, a manufacturing client in Dallas.",
    gamma_id="gamma_tpl_abc123",
    theme_id="theme_xyz",
    folder_ids=["fld_investor_decks"],
    export_as="pptx",
)

3. Branded deck with header/footer

gamma_generate(
    input_text="...",
    format="presentation",
    card_options={
        "dimensions": "16x9",
        "headerFooter": {
            "topLeft": {"type": "image", "source": "themeLogo", "size": "sm"},
            "bottomRight": {"type": "cardNumber"},
            "bottomCenter": {"type": "text", "value": "Confidential"},
            "hideFromFirstCard": True,
        },
    },
    sharing_options={
        "workspaceAccess": "edit",
        "externalAccess": "view",
        "emailOptions": {
            "recipients": ["team@example.com"],
            "access": "comment",
        },
    },
)

Development

git clone https://github.com/cphoskins/gamma-app-mcp.git
cd gamma-app-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
pytest

Release

./release.sh 0.3.0
git add -A && git commit -m "Release v0.3.0"
git tag v0.3.0
git push origin main --tags

The push --tags triggers .github/workflows/publish.yml, which builds the sdist/wheel, publishes to PyPI via trusted publishing (OIDC, no stored tokens), and creates a GitHub release. See PUBLISHING.md for the one-time PyPI trusted publisher setup.

API reference

See GAMMA_API_REFERENCE.md for the full v1.0 endpoint and parameter inventory sourced from developers.gamma.app.

License

MIT — see LICENSE. Inspired by CryptoJym/gamma-mcp-server; ground-up Python rewrite with expanded coverage and corrected v1.0 endpoint paths.

Available Tools

6 tools
gamma_describe_optionsA

Describe accepted enum values for Gamma API parameters.

Local lookup — no network call. Helps you discover valid values without trial and error.

Args: category: Specific category to describe. One of: textModes, formats, cardSplits, textAmounts, imageSources, cardDimensions, cardDimensionsByFormat, exportTypes, workspaceAccessLevels, externalAccessLevels, emailAccessLevels, headerFooterElementTypes, headerFooterImageSources, headerFooterImageSizes, headerFooterPositions. Empty to list all categories. format: When category is cardDimensions or cardDimensionsByFormat, filter to allowed dimensions for a specific format (presentation, document, social, webpage).

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNo
formatNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

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

No annotations provided, but the description fully carries the burden by stating it's a local lookup (no network call) and no side effects are implied. The behavior is transparent and clearly described.

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 concise, with a clear structure: a sentence stating the purpose, a line about no network call, and an args section with detailed bullet points. No unnecessary information.

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 presence of an output schema (not shown), the description does not need to explain return values. It covers purpose, behavior, parameters, and usage context completely for a parameter discovery tool.

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%, yet the description provides exhaustive detail on the 'category' parameter (listing all possible values) and clarifies that 'format' filters dimensions by format for specific categories. This adds significant value 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's purpose: describing accepted enum values for Gamma API parameters. It specifies that it is a local lookup with no network call, distinguishing it from sibling tools (generate, status, folders, themes).

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 context for when to use the tool (to discover valid values) and lists possible categories and the format filter. However, it does not explicitly mention alternatives or when not to use, so it's slightly less than perfect.

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

gamma_generateA

Generate a Gamma presentation, document, webpage, or social post from text.

Generation is asynchronous. Returns a generationId; poll gamma_get_status until status is 'completed' or 'failed' to retrieve the share URL.

Args: input_text: Topic, outline, or full content (1-400000 chars). text_mode: How to interpret input — 'generate' (expand), 'condense', or 'preserve' (keep as-is). Default 'generate'. format: Output type — 'presentation', 'document', 'social', or 'webpage'. Omit to use Gamma's default. theme_id: Theme ID from gamma_list_themes. Omit for default theme. num_cards: Target card count (minimum 1, plan-dependent maximum). 0 = let Gamma decide. card_split: 'auto' or 'inputTextBreaks' (splits on blank lines in input). additional_instructions: Extra style/content guidance (max 5000 chars). export_as: Auto-export format — 'pdf', 'pptx', or 'png'. Empty for no export. folder_ids: Workspace folder IDs to place the output in (max 10). Use gamma_list_folders to discover IDs. text_options: Nested object with 'amount' (brief|medium|detailed|extensive), 'tone' (string, max 500 chars), 'audience' (string, max 500 chars), 'language' (ISO code, e.g. 'en', 'es', 'fr'). image_options: Nested object with 'source' (aiGenerated, pictographic, unsplash, webAllImages, webFreeToUse, webFreeToUseCommercially, giphy, pexels, placeholder, noImages, themeAccent), 'model' (e.g. 'dall-e-3', 'imagen-4-ultra', 'flux-2-pro'), 'style' (string, max 500 chars). card_options: Nested object with 'dimensions' (fluid, 16x9, 4x3, pageless, letter, a4, 1x1, 4x5, 9x16 — must match format) and 'headerFooter' (6-position layout with logos, card numbers, or text). sharing_options: Nested object with 'workspaceAccess' (noAccess, view, comment, edit, fullAccess), 'externalAccess' (noAccess, view, comment, edit), and 'emailOptions' ({recipients: [...], access: ...}).

Call gamma_describe_options to inspect accepted enum values.

ParametersJSON Schema
NameRequiredDescriptionDefault
input_textYes
text_modeNogenerate
formatNo
theme_idNo
num_cardsNo
card_splitNo
additional_instructionsNo
export_asNo
folder_idsNo
text_optionsNo
image_optionsNo
card_optionsNo
sharing_optionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

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

The description discloses asynchronous behavior, polling requirement, and parameter constraints (e.g., char limits, folder count). Without annotations, it carries the full burden and provides substantial behavioral insight beyond the schema.

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 structured with a clear lead sentence, followed by an async note and a detailed parameter list. While thorough, it is lengthy and could benefit from earlier mention of core workflow (generate, poll, retrieve).

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 description covers the full workflow (async generation, polling, retrieval) and references sibling tools (gamma_get_status, gamma_describe_options). It lacks only a direct comparison to gamma_generate_from_template, but the output schema exists, reducing the need for return-value details.

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?

With 0% schema coverage, the description compensates fully by detailing each parameter's purpose, allowable values, defaults, and nested structures (e.g., text_options, image_options). Examples and constraints (max 5000 chars, min 1 card) add clarity the schema lacks.

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 generates various Gamma outputs from text. However, it does not differentiate from the sibling gamma_generate_from_template, leaving ambiguity about when to use this tool versus the template-based alternative.

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 explicit guidance on when to use this tool, when not to, or alternatives. It references gamma_describe_options for enum values but lacks context on decision-making between this and sibling tools like gamma_generate_from_template.

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

gamma_generate_from_templateA

Generate a variant from an existing Gamma template with swapped content.

Uses POST /generations/from-template. The template Gamma must have exactly one Page. Layout is preserved; new content is generated from the prompt. Ideal for batch content with consistent branding — per-segment investor decks, per-lead LinkedIn cards, rebranded decks per channel partner.

Args: prompt: Content description for the new variant (1-400000 chars). gamma_id: The Gamma ID of the template file (required). theme_id: Optional theme ID to override the template's theme. image_options: Same shape as gamma_generate's image_options. sharing_options: Same shape as gamma_generate's sharing_options. folder_ids: Workspace folder IDs to place the output in (max 10). export_as: Auto-export format — 'pdf', 'pptx', or 'png'.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYes
gamma_idYes
theme_idNo
image_optionsNo
sharing_optionsNo
folder_idsNo
export_asNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, description carries full burden. Discloses layout preservation, content generation, single-page template requirement, and limits (max 10 folder IDs). Does not mention auth or rate limits, but covers core behavioral traits.

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?

Concise and well-organized. One sentence summary, endpoint reference, usage guidance, then parameter block. No redundant words. Every sentence adds value.

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 7 parameters, no annotations, and presence of output schema (not shown but sufficient), description covers all necessary aspects: purpose, usage, parameter docs, and behavioral constraints. References sibling tool for shared parameter shapes. Complete and self-contained.

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 has 0% description coverage; description compensates fully. Each parameter gets a meaningful description: prompt length constraint, gamma_id required, theme_id optional, image_options/sharing_options reference to sibling tool, folder_ids cap, export_as enum values. Adds crucial context beyond schema types.

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?

Clear verb-resource pairing: 'Generate a variant from an existing Gamma template with swapped content.' Specifies the endpoint and constraint (template must have exactly one page). Distinguishes from sibling gamma_generate by focusing on template reuse.

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?

Provides ideal use cases: 'batch content with consistent branding' with examples. Does not explicitly state when not to use or name alternatives, but context implies contrast with gamma_generate for scratch generation.

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

gamma_get_statusA

Poll a generation job to retrieve status and results.

Call after gamma_generate or gamma_generate_from_template with the returned generationId. Poll every few seconds until status is 'completed' or 'failed'. On completion, the response includes gammaUrl (shareable link), exportUrl (if exportAs was requested), and credits (deducted/remaining).

Args: generation_id: The generationId returned from a generate call.

ParametersJSON Schema
NameRequiredDescriptionDefault
generation_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior3/5

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

No annotations are provided, so the description bears full burden. It covers polling behavior and output fields but omits error handling, timeouts, or consequences of invalid generation_id. This leaves gaps for an agent to anticipate failure modes.

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 compact and logically ordered: purpose, preconditions, polling behavior, output fields, and an explicit Args section. Every sentence adds value 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?

Given the tool's simplicity (1 parameter, output schema present), the description covers all necessary aspects: what it does, when to use it, how to use it, and what results to expect. No critical gaps remain.

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 coverage is 0%, but the description explicitly states the single parameter generation_id is 'The generationId returned from a generate call,' providing clear provenance. No additional constraints are needed for a simple ID string.

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 'Poll a generation job to retrieve status and results,' specifying a specific verb and resource. It distinguishes itself from sibling tools like gamma_generate and gamma_describe_options by focusing on status retrieval after generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call after gamma_generate or gamma_generate_from_template with the returned generationId. Provides polling frequency guidance and expected terminal statuses ('completed' or 'failed').

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

gamma_list_foldersA

List workspace folders the authenticated user is a member of.

Cursor-paginated. Use the returned folder IDs as the folder_ids parameter when calling gamma_generate or gamma_generate_from_template to place output into specific folders.

Args: query: Filter folders by name substring. Empty for no filter. limit: Results per page (1-50). 0 = let Gamma decide. after: Cursor from a previous response's nextCursor for pagination.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNo
limitNo
afterNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

Describes cursor-paginated behavior and links to other tools, but without annotations, it does not disclose read-only nature or rate limits. However, it respects the tool's expected behavior.

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?

Four concise sentences, front-loaded with purpose, then pagination, then parameter details. No wasted words.

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?

Covers all essential aspects: purpose, pagination, parameter descriptions, and usage integration with other tools. Output schema exists, so return values need not be described.

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?

With 0% schema coverage, the description fully explains each parameter: query as substring filter, limit with range and default meaning, and after as cursor for pagination.

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?

Clearly states the verb 'list' and resource 'workspace folders', distinguishing it from sibling tools like gamma_generate and gamma_list_themes.

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?

Provides context for when to use (to obtain folder IDs for gamma_generate calls) and explains filter options, but lacks explicit exclusions for alternative tools.

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

gamma_list_themesA

List themes available in the authenticated workspace.

Returns both standard and custom themes with their IDs plus colorKeywords and toneKeywords metadata (50+ themes at last count). Cursor-paginated. Use the returned theme ID as the theme_id parameter when calling gamma_generate or gamma_generate_from_template.

Args: query: Filter themes by name substring (e.g. 'dark'). Empty for no filter. limit: Results per page (1-50). 0 = let Gamma decide (default). after: Cursor from a previous response's nextCursor for pagination.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNo
limitNo
afterNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. Discloses returns both standard and custom themes with colorKeywords/toneKeywords metadata, and cursor-based pagination.

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?

Concise and well-structured: brief intro followed by clear Args section. Every sentence adds value.

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 output schema exists, description covers return metadata and pagination adequately. All three parameters explained with constraints.

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%, but description fully explains each parameter: query filters by substring, limit specifies page size (1-50, 0 for default), after for pagination cursor.

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?

Clearly states the tool lists themes available in the authenticated workspace, distinguishes from siblings like gamma_generate which uses theme_id.

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?

Explains that the returned theme_id is used in gamma_generate or gamma_generate_from_template; mentions filtering and pagination. Does not explicitly state when not to use, but context is clear.

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.

  1. 6 tool updatesv0.2.0
    • First observedgamma_describe_options
    • First observedgamma_generate
    • First observedgamma_generate_from_template
    • First observedgamma_get_status
    • First observedgamma_list_folders
    • First observedgamma_list_themes

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: parameter discovery, generation from text, generation from template, status polling, folder listing, and theme listing. No two tools overlap in functionality.

Naming Consistency4/5

All tools use snake_case with a 'gamma_' prefix. Most follow a verb_noun pattern, but 'gamma_generate' is just a verb (no noun object), and 'gamma_generate_from_template' uses a preposition. Minor inconsistency does not hinder understanding.

Tool Count5/5

6 tools is well within the typical 3-15 range. Each tool serves a necessary role in the Gamma generation workflow without redundancy or bloat.

Completeness4/5

Covers the core generation lifecycle: parameter exploration, creation (two variants), status polling, and resource listing. Missing listing of existing Gammas or deletion, but these are not essential for the stated generation purpose.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/cphoskins/gamma-app-mcp'

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