Skip to main content
Glama

Account & History

manage_account
Destructive

SlideForge account for PowerPoint generation: balance, billing, job history, feedback, data controls. All free. Actions: status (balance+plan), usage (spend breakdown), jobs (history), job (single job detail — slide jobs include quality_warnings[]; deck jobs add slides_completed/slides_failed/failed_slides[]), feedback (submit), feedback_list (read your reports back: status + resolution), onboarding (capabilities overview), topup (Stripe checkout link; wallet credits automatically), webhooks/webhook_add/webhook_remove/webhook_test (push endpoint instead of polling to terminal), download_url (fresh short-TTL PPTX link for an owned job — when a result carries no inline URL), security_status (retention + access-model + deletion posture), delete_job (irreversible: job + versions + files) Action delete_asset irreversibly deletes a user-owned uploaded/generated image asset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoHTTPS endpoint to receive events (for action=webhook_add). Must be public HTTPS (private/loopback rejected).
daysNoLookback period (for action=usage, default 30)
slugNoReport slug (for action=reports — returns one report's full metadata; omit to list all).
limitNoMax rows (action=jobs default 10; action=feedback_list default 50, max 100)
actionYesOperation (required). feedback → report a defect or request against a render; pass job_id so it is actionable, and ask the user before filing. feedback_list → read YOUR OWN filed reports back, with `status` and the `resolution` written when one was acted on: check it before working around a defect you reported earlier, because it may already be fixed. brand_report → the per-token fidelity report for one of your brand kits (pass theme_id). topup → mints a Stripe checkout link the user pays at directly (wallet credits automatically) — use when a render is refused for balance. reports → list report types; webhook_add registers a push endpoint instead of polling — see the url/events props. delete_job is irreversible. delete_asset is irreversible for user-owned image assets.
amountNoUSD top-up amount (for action=topup, default 10, min 10, max 1000). Volume bonus: $50→+10%, $100→+15%, $200→+20%.
detailNoFor action=status only: default false masks identity fields; true returns full email/user_id diagnostics for the authenticated user.
eventsNoEvent types to subscribe to (for action=webhook_add; default all): job.completed, job.failed, deck.completed, deck.partial, deck.failed.
job_idNoJob ID (for action=job, action=download_url and action=delete_job)
statusNoFilter — action=jobs: queued/generating/complete/failed; action=feedback_list: open/resolved
messageNoWhat went wrong or what you want, in the user's own words (for action=feedback).
asset_idNoImage asset ID (for action=delete_asset). Logos are content-addressed/shared and are not deleted by this action.
categoryNoFeedback category (action=feedback to file under it, action=feedback_list to filter by it). The first nine are slide-quality categories — pair them with job_id.
severityNoFor action=feedback: `bug` = it is broken, `quality` = it rendered but reads poorly, `suggestion` = a request. Defaults to suggestion, so file real defects explicitly or they are triaged as wishes.
webhook_idNoWebhook subscription id (for action=webhook_remove / webhook_test).
include_previewNoPreview (for action=job)
include_childrenNoFor action=jobs: include deck child slides (each carries parent_deck_id) so a deck's slides are discoverable by listing. Default false (parents only). Deck rows roll child cost up to the deck.

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only mark destructiveHint=true, so the description carries the transparency burden and handles it well. It discloses irreversibility of delete_job and delete_asset, Stripe checkout/wallet credit behavior, webhook push semantics, short-TTL download URLs, feedback resolution status, shared logo assets not being deleted, and deck child-slide rollup behavior. This is substantial behavioral 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.

Conciseness3/5

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

The description has no fluff and is front-loaded with the tool's purpose. However, it is a long run-on paragraph of semicolon-separated action summaries, and the final delete_asset sentence is detached awkwardly. A bulleted structure would be easier for an agent to scan without losing density.

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 18 actions, 17 parameters, no output schema, and sparse annotations, the description is quite complete. It names key output differences, safety caveats, and action-specific conditions. It does not fully detail every action response shape, but combined with the rich input schema, an agent has enough to invoke the correct action.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful action-level semantics not fully present in the schema, such as job detail differences for slide vs deck jobs, download_url's purpose, status meaning, and delete_asset's ownership constraint. That raises it to 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource scope: 'SlideForge account for PowerPoint generation: balance, billing, job history, feedback, data controls.' It enumerates the actions, which distinguishes it from the sibling creation/catalog tools. It loses a point because it is a broad polymorphic tool rather than a single-verb action, so the purpose is clear but not maximally crisp.

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 explicit usage triggers for several actions: use topup 'when a render is refused for balance', download_url 'when a result carries no inline URL', webhooks 'instead of polling to terminal', and feedback_list to check whether an earlier report was already resolved. It does not give an overall when-to-prefer-this-tool statement, but the account-management scope is distinct from siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool maps to a distinct phase or responsibility: browse_catalog for exploration, plan_slide for pre-render planning, create_slide/create_deck for single vs multi-slide generation, upload_asset for asset intake, translate_deck for translation, and manage_account for account/job operations. No two tools appear to do the same thing.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores (browse_catalog, create_deck, create_slide, manage_account, plan_slide, translate_deck, upload_asset). This uniform convention makes the set predictable and easy to navigate.

Tool Count5/5

Seven tools provide a well-scoped coverage of the PowerPoint generation workflow—from browsing and planning to creating, asset management, translation, and account control—without unnecessary duplication or bloat.

Completeness5/5

The tool surface covers the full lifecycle: exploration (browse_catalog), planning (plan_slide), single/multi-slide creation (create_slide/create_deck), asset upload/generation (upload_asset), translation (translate_deck), and account/job management including deletion and webhooks (manage_account). No obvious dead ends or missing operations.