The Glitch MCP server connects AI developer tools (Cursor, Claude Code, Codex) to the hosted Glitch Agent service for game marketing automation, letting developers manage marketing tasks without leaving their coding environment.
Authentication & Account Management
Check auth status, list/select game titles, fetch title context, and review subscription/billing details.
Agent Runs (Core Marketing Tasks)
Start AI agent runs using plain-language prompts (e.g., Steam page optimization, influencer outreach, PR planning, social content generation).
Monitor run status, wait for completion, list run events, retrieve final reports, and access downloadable artifacts.
Action Approval Workflows
List pending actions proposed by the agent, then approve, reject, or execute them (with explicit confirmation guards to prevent accidental triggers).
Guidance & Interactive Workflows
List open guidance requests from a paused agent run and answer them to resume the workflow.
File Uploads & Social Assets
Generate upload URLs and upload local images, videos, or documents (up to 50 MB) as run attachments or social assets.
Set up social asset folders, scan local assets, watch for changes, and upload candidates for social media scheduling.
Dashboard Navigation
Get deep links into the Glitch web UI for titles, runs, actions, or billing screens.
Draft Bluesky post drafts for social content and community updates.
Audit Discord onboarding, suggest channel structure improvements, create announcements, and manage community engagement.
Connects to the Glitch Agent service for game marketing workflows including Steam analysis, influencer outreach, PR planning, Discord management, and approval workflows.
Draft Reddit post drafts for social content campaigns and community updates.
Analyze Steam pages, compare against competitors, and create launch readiness reports to optimize store pages and wishlist conversion.
Draft TikTok post drafts for social content and campaign variants.
Review Twitch creator links and assess fit for game coverage, including audience relevance and risk notes.
Review YouTube creator links and assess fit for game coverage, including audience relevance and suggested pitch angles.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Glitch MCP Analyze our Steam page for wishlist improvements"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Glitch MCP connects AI developer tools to Glitch's public game-development prompt library, mechanics and core-loop generator, live genre taxonomy, analytics and hosting tools, and the hosted Glitch Agent service for marketing and launch workflows.
Glitch MCP makes marketing your game feel like coding. Instead of leaving Codex, Cursor, or Claude Code to open dashboards, rebuild spreadsheets, or translate marketing requests into manual workflows, developers can ask for a concrete marketing task in plain language and get back structured reports, recommended actions, draft assets, upload links, approval steps, and deep links into the full Glitch browser experience. The goal is simple: keep developers focused on building the game while Glitch turns marketing work into reviewable, executable tasks.
More Info Here: https://www.glitch.fun/publishers/agents
The MCP bundles the same 25 public prompts shown on the AI Game Development Prompts page. Prompt ids and deep links stay stable, and every prompt requires the developer or agent to create or update the game's documentation.
Use glitch_list_game_development_prompts to search by situation or category.
Use glitch_get_game_development_prompt to retrieve the complete Markdown.
Use glitch_list_game_genres for the live Glitch taxonomy; genre selection is multi-select.
Use glitch_generate_game_design_blueprint to turn an early idea into a descriptor, mechanics, core verbs, design pillars, moment-to-moment core loop, session loop, and playtest question. It prefers Glitch's OpenAI service and automatically uses the same deterministic fallback as the website when that route is unavailable. AI generation can take about a minute, so the tool emits MCP progress notifications and uses a longer request timeout.
The MCP also registers every library item as a native prompt such as glitch_game_dev_remote_game_automation, plus glitch_ai_game_development_prompt for guided selection and glitch_game_design_blueprint for guided mechanics/core-loop generation.
Related MCP server: Business Bridge MCP Server
Use these examples as starting prompts inside your MCP client. Glitch returns structured data your coding agent can read, summarize, compare, and turn into next steps for your game.
Ask: "Analyze our Steam page for Neon Drift Arena and tell me what is hurting wishlists."
Glitch returns: a Steam page report with capsule/header image feedback, short-description positioning, tag/category fit, trailer and screenshot notes, review of call-to-action clarity, comparable titles, wishlist conversion risks, and prioritized fixes. This helps you improve the store page before buying traffic or pitching creators, so more interested players convert into wishlists.
Ask: "Compare our Steam page against five similar roguelite deckbuilders launching this quarter."
Glitch returns: a competitive Steam report with pricing, release timing, tags, capsule messaging, trailer angle, review count, follower/wishlist signals where available, and a positioning map that shows where your game can stand out. This helps you avoid copycat messaging and find a sharper market angle for your launch.
Ask: "Create a Steam launch readiness report for our game using our trailer, screenshots, and store copy."
Glitch returns: a launch checklist with risk grades, missing assets, copy rewrites, screenshot sequencing suggestions, trailer hook notes, localization considerations, creator/press readiness, and a recommended pre-launch task list. This helps your team know what to fix before a public demo, festival, or launch window.
Ask: "Find creators who would be a good fit for our cozy survival crafting game and draft outreach."
Glitch returns: a creator shortlist with channel fit, audience/gameplay match, content style, likely campaign angle, outreach priority, contact notes when available, and personalized draft messages. This helps your game reach creators whose audiences are more likely to care, instead of blasting generic emails.
Ask: "Review these YouTube and Twitch creator links and tell me who is worth contacting for our horror demo."
Glitch returns: a ranked influencer report with fit score, audience relevance, recent game coverage, risk notes, suggested pitch angle, recommended key, follow-up timing, and approval-ready outreach drafts. This helps you spend limited review-key and outreach time on creators with the best chance of useful coverage.
Ask: "Build a PR plan for announcing our Steam demo next month."
Glitch returns: a press plan with announcement angle, target outlet categories, timing, embargo/release-day recommendations, press-kit gaps, subject lines, draft pitch copy, and follow-up tasks. This helps your announcement feel intentional instead of rushed when the demo goes live.
Ask: "Turn our latest devlog into a press pitch for indie game journalists."
Glitch returns: a PR-ready story angle, journalist-facing pitch, shorter alternate subject lines, quote suggestions, asset checklist, and recommended media targets. This helps translate developer updates into a story press can understand quickly.
Ask: "Review our Discord onboarding and suggest changes that help new playtesters know what to do."
Glitch returns: a Discord community audit with channel structure notes, onboarding friction, role recommendations, announcement cadence, moderation gaps, playtest call-to-action improvements, and draft welcome/FAQ copy. This helps turn curious players into active testers and community members.
Ask: "Create a Discord announcement for our new trailer and prepare follow-up questions for the community."
Glitch returns: an announcement draft, short and long variants, suggested image/video attachment guidance, ping recommendations, community questions, poll ideas, and follow-up schedule. This helps your trailer launch create conversation instead of a single post that disappears.
Store page optimization for Steam and other PC storefronts.
Launch planning, demo planning, festival readiness, and milestone marketing calendars.
Competitive research, positioning, feature comparison, pricing checks, and market narrative.
Trailer, screenshot, capsule, key art, and creative review.
Creator discovery, outreach drafts, campaign tracking, review-key workflows, and follow-ups.
PR strategy, press-kit review, announcement planning, pitch writing, and outlet targeting.
Discord community onboarding, announcements, playtest coordination, moderation planning, and engagement prompts.
Social content calendars, TikTok/Reddit/X/Bluesky post drafts, community updates, and campaign variants.
Paid marketing review, ad creative feedback, targeting notes, landing-page checks, and campaign QA.
Player research, feedback synthesis, survey summaries, sentiment themes, and next-step recommendations.
File-assisted review of screenshots, images, videos, trailers, pitch decks, press kits, CSVs, and documents.
Approval workflows for risky actions, so developers stay in control before anything is executed.
Deep links back to the Glitch browser experience when a richer dashboard, report, or approval flow is needed.
This repository is the public adapter. It does not contain the private Glitch Agent planner, prompts, routing policies, queue workers, billing logic, model keys, integration credentials, or executor code. All valuable service logic stays behind the hosted Glitch SaaS boundary.
The complete public AI game-development prompt library as MCP tools, prompts, and resources.
A multi-genre mechanics and core-loop generator that prefers Glitch's OpenAI service and includes a documentation-ready local fallback.
MCP tools for starting and monitoring Glitch Agent runs.
Structured reports, pending actions, guidance requests, and artifact links.
Direct read-only access to the canonical Glitch analytics catalog and 70+ dashboard reports without starting a paid Agent run.
Deep links into the rich Glitch browser experience.
Optional local stdio proxy for MCP clients that do not yet support remote auth cleanly.
Client setup docs for Codex, Cursor, and Claude Code.
Private Glitch Agent planning prompts. The separate AI Game Development Prompt library is intentionally public.
Internal route resolution.
Database queries.
Billing enforcement.
Integration secrets.
Social, ad, creator, and PR execution logic.
Raw planner traces and private memories.
Codex / Cursor / Claude Code
-> Glitch MCP adapter
-> https://api.glitch.fun/api
-> public prompt/design routes or /mcp/v1 title-scoped routes
-> Glitch auth, subscription, title, scope, and rate-limit checks
-> Glitch Agent SaaS backend
-> Glitch hosted UI for reports, approvals, billing, and integrationsnpm install -g glitch-mcpFor local development from this repository:
npm install
npm run build
npm testThe production API facade lives behind the existing Glitch API domain:
https://api.glitch.fun/apiCreate a Title MCP Token inside the Glitch subscription/security interface and use it as GLITCH_API_TOKEN or GLITCH_MCP_TOKEN.
export GLITCH_API_BASE_URL="https://api.glitch.fun/api"
export GLITCH_API_TOKEN="gl_mcp_..."
export GLITCH_TITLE_ID="title_..."Title MCP tokens are still checked server-side for subscription, title access, scopes, rate limits, and action risk. Over the HTTP transport the adapter forwards each caller's own bearer token, so one hosted endpoint serves many developers safely. Hosted OAuth is also supported but optional (GLITCH_MCP_OAUTH_ENABLED); bearer-token auth works with it off.
More detail: docs/auth.md.
Codex stdio proxy:
[mcp_servers.glitch]
command = "npx"
args = ["-y", "glitch-mcp"]
env_vars = ["GLITCH_API_BASE_URL", "GLITCH_API_TOKEN", "GLITCH_TITLE_ID"]
default_tools_approval_mode = "prompt"Future hosted Streamable HTTP deployments should stay on the same API domain, for example https://api.glitch.fun/mcp.
Local development stdio proxy:
[mcp_servers.glitch]
command = "npx"
args = ["-y", "glitch-mcp"]
env_vars = ["GLITCH_API_BASE_URL", "GLITCH_API_TOKEN", "GLITCH_TITLE_ID"]
default_tools_approval_mode = "prompt"Full guide: docs/codex.md.
Glitch MCP also ships Codex slash-command prompt files so developers can type /prompts:glitch... from the Codex prompt box.
npx -y glitch-mcp install-codex-promptsThat command installs the bundled prompt files into ~/.codex/prompts. Restart Codex or open a new chat after installing them. The package includes direct command prompts for every public Glitch MCP tool plus higher-level workflows such as launch audits, Steam page reviews, weekly marketing syncs, pending action reviews, and local social asset workflows.
Cursor stdio proxy:
{
"mcpServers": {
"glitch": {
"command": "npx",
"args": ["-y", "glitch-mcp"],
"env": {
"GLITCH_API_BASE_URL": "https://api.glitch.fun/api",
"GLITCH_API_TOKEN": "${GLITCH_API_TOKEN}",
"GLITCH_TITLE_ID": "${GLITCH_TITLE_ID}"
}
}
}
}Local development stdio proxy:
{
"mcpServers": {
"glitch": {
"command": "npx",
"args": ["-y", "glitch-mcp"],
"env": {
"GLITCH_API_BASE_URL": "https://api.glitch.fun/api",
"GLITCH_API_TOKEN": "${GLITCH_API_TOKEN}",
"GLITCH_TITLE_ID": "${GLITCH_TITLE_ID}"
}
}
}
}Full guide: docs/cursor.md.
Cursor can use the same bundled Glitch prompt commands as project slash commands:
npx -y glitch-mcp install-cursor-prompts --project-root .That command copies prompts/glitch_*.md into .cursor/commands. Open Cursor in that project, type /glitch, and choose the Glitch command you want. The direct command prompts map to the exact public MCP tool names, while workflow prompts cover launch audits, Steam page reviews, weekly marketing syncs, pending action reviews, and local social asset workflows.
Claude Code stdio proxy:
export GLITCH_API_BASE_URL="https://api.glitch.fun/api"
export GLITCH_API_TOKEN="gl_mcp_..."
export GLITCH_TITLE_ID="title_..."
claude mcp add glitch -- npx -y glitch-mcpFull guide: docs/claude-code.md.
Claude Code can use the same bundled Glitch prompt commands as project slash commands:
npx -y glitch-mcp install-claude-prompts --project-root .That command copies prompts/glitch_*.md into .claude/commands. Restart Claude Code or start a new session in the project, then type /glitch to pick a Glitch command. The approve, execute, upload, and local watcher commands include explicit confirmation guidance.
glitch-mcp stdio
glitch-mcp http --host 127.0.0.1 --port 3333
glitch-mcp doctor
glitch-mcp versionstdio is the default command and is what most local MCP clients launch.
http is for local development and enterprise proxy scenarios. The canonical paid facade is still https://api.glitch.fun/api.
doctor verifies the configured hosted service and token without printing the token.
The adapter exposes a guarded tool surface. Social primitives are discovered dynamically from the hosted backend so MCP clients and Glitch Agent use the same title-scoped capability contract:
glitch_auth_status
glitch_list_titles
glitch_select_title
glitch_get_title_context
glitch_list_game_development_prompts — search the public prompt library by category or situation
glitch_get_game_development_prompt — retrieve complete Markdown and a stable web/resource link
glitch_list_game_genres — fetch the live alphabetized genre taxonomy for multi-select inputs
glitch_generate_game_design_blueprint — generate a documentation-ready descriptor, mechanics, core verbs, core loop, session loop, and playtest question
glitch_get_analytics_capabilities — discover canonical report families,
report keys, filters, source routes, requirements, and limits
glitch_get_analytics_report — run one canonical dashboard report directly
glitch_get_session_reports
glitch_get_web_reports
glitch_get_storefront_reports
glitch_get_wishlist_reports
glitch_get_earnings_reports
glitch_get_attribution_reports
glitch_get_cross_device_reports
glitch_get_billing_status
glitch_get_social_capabilities — list the authoritative platform matrix, connected schedulers, granular abilities, and every supported social operation
glitch_social_operation — execute a deterministic social read or explicitly confirmed mutation using an operation returned by the capability catalog
glitch_start_agent_run
glitch_get_agent_run
glitch_wait_for_agent_run
glitch_list_run_events
glitch_get_final_report
glitch_list_artifacts
glitch_list_pending_actions
glitch_approve_action
glitch_reject_action
glitch_execute_action
glitch_list_guidance
glitch_answer_guidance
glitch_resolve_guidance — present the agent's stop-gate questions as interactive multiple-choice prompts (MCP elicitation) and route answers back to resume the run
glitch_setup_social_asset_folders — create local capture/screenshot/trailer/marketing folders for developer social assets
glitch_scan_local_social_assets — scan local game asset folders, dedupe by content hash, and write a review manifest of social candidates
glitch_start_social_asset_watch — opt in to a local daily scan timer for social asset folders
glitch_stop_social_asset_watch — disable the local scan timer
glitch_upload_social_asset_candidates — upload reviewed local candidates as Glitch Media for AI processing and scheduler library creation
glitch_create_upload_url
glitch_upload_file — upload a local image, video, or document (screenshot, gameplay clip, brief) to a title or run
glitch_open_dashboard
glitch_get_hosting — inspect bandwidth, websites, releases, domains, databases, and plans
glitch_get_hosting_analytics — compare hosted-site, Store, and combined title performance
glitch_create_hosting_site — create a managed website with a free Glitch address
glitch_update_hosting_site — change name, static/server mode, region, and non-secret settings
glitch_list_hosting_releases — inspect deployment history and rollback targets
glitch_deploy_hosting_build — turn a ready game build into a hosted release and optionally publish it
glitch_promote_hosting_release — publish or roll back an immutable hosted release
glitch_connect_hosting_domain / glitch_verify_hosting_domain — connect and verify a domain the developer owns
glitch_check_hosting_domain / glitch_purchase_hosting_domain — check live pricing, accept agreements, and start secure checkout
glitch_generate_hosting_ai_instructions — create a copy-and-paste deployment/add-on guide without credentials
glitch_list_hosting_databases / glitch_get_hosting_database — inspect safe managed database metadata; owners reveal credentials manually in the Hosting dashboard, never through MCP
glitch_create_hosting_database / glitch_update_hosting_database / glitch_retry_hosting_database / glitch_delete_hosting_database
glitch_change_hosting_plan / glitch_confirm_hosting_checkout — manage direct, Microsoft Marketplace, or paid AWS Marketplace bandwidth plans and confirm direct paid Hosting checkouts
Full contract: docs/tool-reference.md.
Hosted facade contract: docs/hosted-api-contract.md.
Glitch MCP can handle the complete website deployment flow with one scoped MCP token:
Use glitch_list_deployments and select a compatible processing or ready game build already uploaded on Deploy Game.
Preserve that build id. If it is processing, resume waiting on it; never activate it or upload the unchanged artifact again. Only when no compatible build exists, use glitch_deploy_game_build once and persist the returned id.
Use glitch_deploy_hosting_build with the selected build id. It waits for game-build and release processing, selects or creates the hosting site, creates an immutable release, and publishes it when publish=true.
Use glitch_promote_hosting_release to roll back to an earlier release.
Developers do not need to supply a custom smoke-test suite. Glitch runs mandatory deployment-type acceptance gates that custom variables cannot disable. MCP reports processing_stage while waiting and includes the build id, error_code, failure_stage, retryable, error_message, and remediation when a build fails.
For Store-embedded browser surfaces, the canonical Aegis bridge is https://api.glitch.fun/js/aegis-bridge.js. Static HTML/HTM entries and discovered standard Pixel Streaming player pages are patched automatically. Node/SSR, streamed-native/noVNC, generic container, non-HTML static, and custom Pixel Streaming frontends must add the script once to their own browser layout and verify it loads in the final page.
Before step 2 or 3, inspect the finished production artifact and prove its exact entry path. index.html is valid only when it exists at that path and is the real browser bootstrap. A Node/server build must use the executable module that binds PORT; package.json is metadata and is rejected as an entry. Test the exact entry in clean Linux or the production container, verify health and all assets, reach the first interactive screen without console errors, and verify the final public HTTPS URL. A ready release is not yet active.
Node packages must also include a production Dockerfile in the same build
context as package.json and the executable entry. Put it at the ZIP root by
default. Bind to 0.0.0.0 and align HOST=0.0.0.0, PORT=3000, Dockerfile
EXPOSE 3000, and custom_variables.target_port=3000 unless another single
port is explicitly tested. Do not call glitch_update_deployment_status with
ready while a Store build is processing; Glitch returns HTTP 400.
All mutations require confirm=true. Hosting remains independent from the Glitch Store distribution fee and release state.
The developer token preset can manage the full lifecycle of a title's hosted website: settings, releases, domains, analytics, managed databases, and bandwidth plans.
Paid operations use a two-step safety flow:
Read the current Hosting catalog or domain availability response.
Show the developer the exact price and confirmation phrase.
Call the paid tool with confirm=true, the expected price, and that exact phrase.
Open the returned secure-checkout URL. Glitch never accepts card details through MCP.
After payment, call glitch_confirm_hosting_checkout. Glitch verifies the session with the payment provider before database setup begins.
Database responses contain an endpoint, port, and binding name only. Passwords, secret references, and full connection strings are never returned. glitch_update_hosting_site also rejects password-, token-, key-, and connection-string-shaped configuration before it leaves the local adapter.
Use the packaged /glitch_manage_hosting prompt for a guided, nontechnical management flow.
The local adapter can turn development artifacts into scheduled social drafts without asking a developer to leave their project folder.
glitch_setup_social_asset_folders creates the conventional folders:
captures/, screenshots/, trailers/, builds/latest/social/, marketing/, and .glitch/social-assets/.
glitch_scan_local_social_assets ranks screenshots, clips, trailers, and marketing exports, computes SHA-256 hashes, dedupes repeated files, and writes a review manifest.
glitch_upload_social_asset_candidates uploads only approved candidates as Glitch Media. A title_promotion_schedule_id is required when the upload should create social library posts.
Glitch Media AI analyzes the uploaded asset first. After that analysis completes, the backend creates a scheduler library TitleUpdate and uses the existing OpenAIApiService social copy functions with the selected title promotion schedule to write platform-specific text.
The watcher stays off by default. Developers can opt in with glitch_start_social_asset_watch to refresh the local candidate manifest daily; the watcher never uploads by itself.
Glitch MCP uses progressive enhancement:
Structured MCP results for every client.
Dashboard deep links for the full Glitch browser experience.
MCP Apps widgets where a host supports inline interactive UI.
Full UX map: docs/rich-ui.md.
All paid checks happen on the hosted Glitch service.
Analytics tools are read-only, title-scoped to reports:read, bounded to 25
reports and 365 days per query, and preserve empty/partial states instead of
inventing zero values.
reports:read returns aggregate-safe reports; raw identity-level fields and
identity filter values stay redacted unless the credential also has the
narrowly scoped reports:identity ability.
Mutating tools require explicit confirmation.
Social operations are title-scoped, reject credential-shaped input, and recursively remove OAuth tokens, secrets, passwords, API keys, and authorization data from responses.
Read-only, operator, and developer MCP tokens receive different social abilities; publishing, engagement, messaging, account changes, and destructive operations require the developer abilities.
Approval and execution are separate.
Uploaded files are reference material, not trusted instructions.
glitch_upload_file supports images, videos, and documents up to 50 MB; shared HTTP mode rejects local file_paths and stdio can be constrained with GLITCH_MCP_UPLOAD_ALLOWED_ROOTS.
Local social asset tools are stdio-only, review-first, and upload screenshots/clips as Media; scheduler TitleUpdate library items are created only after Media AI processing, not before.
The local social watcher is off by default. When activated, it rescans and dedupes candidates; uploads still require explicit approval and a title_promotion_schedule_id.
Social asset uploads require an explicit scheduler when they should create TitleUpdate library posts. After AI analysis completes, Glitch uses the selected title promotion schedule and the existing OpenAIApiService social copy system to write platform-specific text.
Tool errors are sanitized before they reach the AI client.
Tokens are never printed by doctor.
The public package cannot run the agent without Glitch SaaS.
Security model: SECURITY.md.
npm install
npm run build
npm testThe tests mock the hosted Glitch facade and cover config loading, HTTP behavior, title selection, run polling, confirmation gates, MCP server initialization, resources, prompts, and tool registration.
Answer a Glitch Agent guidance request and resume the server-side workflow when possible.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| guidance_id | Yes | Glitch guidance request id. | |
| answer | Yes | ||
| payload | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and openWorldHint=true. The description adds that it resumes the workflow 'when possible' but does not disclose conditions for failure or side effects, offering limited context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear sentence with no redundant information, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and moderate schema coverage, the description is too minimal. It does not explain answer format, payload purpose, or what happens after answering, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (descriptions for title_id and guidance_id but not answer and payload). The tool description adds no parameter meaning, failing to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool answers a Glitch Agent guidance request and resumes the server-side workflow, distinguishing it from sibling tools like glitch_approve_action and glitch_reject_action which handle actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, such as when to answer versus reject or approve. It only implies usage by describing the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Approve a reviewable Glitch Agent action. Execution still remains subject to server-side guardrails.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| action_id | Yes | Glitch agent action id. | |
| confirm | No | Must be true. This prevents accidental model-triggered approvals. | |
| note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true. The description adds value by noting 'Execution still remains subject to server-side guardrails,' informing agents that approval may not guarantee execution. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the purpose, second adds a behavioral note. No unnecessary words. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers purpose and guardrails, it omits critical details: the mandatory 'confirm' parameter (must be true) is not mentioned, and the relationship with glitch_execute_action is unclear. More context is needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters described). The 'note' parameter lacks both schema and description coverage. The tool description does not add parameter details, failing to compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Approve a reviewable Glitch Agent action.' It uses a specific verb ('approve') and resource ('reviewable Glitch Agent action'), distinguishing it from siblings like glitch_reject_action or glitch_execute_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for approving actions but does not specify when or when not to use it, nor does it mention prerequisites like listing pending actions. The lack of explicit guidance on alternatives or context weakens this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the current user token or title MCP token can access Glitch MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the description's mention of 'check' is consistent but adds no new behavioral traits beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple auth-check tool with comprehensive annotations, the description is sufficient. It lacks explicit return value details, but the output is implied by the check. The context of sibling tools is clear, and no further elaboration is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter (title_id) with a full description, achieving 100% schema description coverage. The tool description adds no additional parameter semantics, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks authentication status for the current user or title token, using a specific verb (check) and resource (access). It is distinct from sibling tools which focus on actions, guidance, or file uploads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description itself does not provide usage guidance, but the input schema's description for 'title_id' states when to omit it, linking to glitch_select_title or GLITCH_TITLE_ID. This gives context for using the tool correctly, though no explicit alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a short-lived upload URL for attaching a file to a Glitch Agent title or run.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| file_name | Yes | ||
| mime_type | Yes | ||
| size_bytes | Yes | ||
| agent_run_id | No | Glitch agent run id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the detail that the URL is 'short-lived', providing temporal context. However, it does not explain what destructive effects occur (e.g., resource allocation) or authentication requirements. Given annotations cover some behavioral aspects, the description adds marginal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 18-word sentence with no extraneous information. It is appropriately front-loaded. However, given the tool's complexity, a slightly expanded description could provide needed context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema. The description is minimal and does not explain the lifecycle of the upload URL (e.g., expiration), how to use it, or its relation to sibling tools like 'glitch_upload_file'. Given the moderate complexity, the description is notably incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (title_id and agent_run_id have descriptions). The main description does not explain the purpose or constraints of parameters like file_name, mime_type, or size_bytes, failing to compensate for the low coverage. Users may not understand the required format or role of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create'), resource ('short-lived upload URL'), and context ('attaching a file to a Glitch Agent title or run'). It differentiates from the sibling tool 'glitch_upload_file' by focusing on URL generation rather than the actual upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for attaching files, but does not specify when to use this tool versus alternatives like 'glitch_upload_file', nor does it mention prerequisites or exclusions. Usage context is clear but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute an approved Glitch Agent action. Public, paid, and creator-facing work remains guarded by Glitch.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| action_id | Yes | Glitch agent action id. | |
| confirm | No | Must be true. Public, paid, or creator-facing work remains guarded server-side. | |
| note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the mutation nature is clear. The description adds minimal context about guarded public/paid/creator work, but lacks details on permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action. No unnecessary wording, though slightly more structure could help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and 4 parameters, the description is too sparse. It does not explain what constitutes an approved action, how to obtain action_id, return values, or errors. The confirm requirement is in schema but not highlighted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 params have descriptions). The tool description does not add any extra meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute' and the resource 'an approved Glitch Agent action'. It distinguishes this tool from siblings like glitch_approve_action or glitch_reject_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 versus alternatives. The mention of guarded work provides some context but not usage conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a durable Glitch Agent run with status, actions, guidance, events, files, and final report when available.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| run_id | Yes | Glitch agent run id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and not destructive. The description adds behavioral context by stating it fetches a 'durable' run and lists return fields, adding value beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the tool's purpose and return components with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the key components returned, which is helpful. However, it lacks details on format or pagination. Annotations cover idempotence and safety, making this adequate for a fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage. The description does not add additional meaning beyond the schema's parameter descriptions. According to guidelines, baseline 3 is appropriate when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a durable Glitch Agent run' with specific verb and resource. It lists the returned components (status, actions, guidance, events, files, final report), distinguishing it from siblings like glitch_get_final_report and glitch_list_run_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies comprehensive fetch by listing components, but lacks guidance on prerequisites (e.g., title selection) or conditions for using sibling tools like glitch_list_run_events for specific data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check subscription, trial, plan, and credit state for a title.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld hints. The description adds the specific billing aspects checked, but does not disclose any additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the tool's purpose without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description states what is checked, it does not describe the return format or structure. Given no output schema, the description could be more complete about expected outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already explains when to omit title_id. The tool description adds no further meaning to the parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks subscription, trial, plan, and credit state for a title, using a specific verb and resource. It distinguishes itself from sibling tools by being the only billing-focused tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 versus alternatives is provided. The parameter description implies usage after selecting a title, but the main description lacks such context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the human-friendly final or partial report for a Glitch Agent run.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| run_id | Yes | Glitch agent run id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, which cover safety and idempotency. The description adds that the report is 'human-friendly' and possibly partial, but does not elaborate on behavior like error states or format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded with the key action and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description gives a basic idea of what is returned ('human-friendly final or partial report'). However, it does not mention when the report is partial, error handling, or the role of the optional title_id parameter, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description adds no additional meaning beyond what is in the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a report for a Glitch Agent run, using the specific verb 'Fetch' and resource 'report'. However, it does not explicitly differentiate from siblings like glitch_get_agent_run or glitch_list_artifacts, which could also involve fetching run-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention when not to use it, prerequisites, or relationships to other tools like glitch_get_agent_run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch safe, subscription-gated context for a game title.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds the important behavioral context of being 'subscription-gated', which is not in the annotations. This helps the agent understand access constraints. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 7 words, extremely concise with no wasted text. Every word adds value: 'Fetch' indicates the action, 'safe' and 'subscription-gated' add constraints, and 'context for a game title' defines the resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description adequately covers the purpose and constraints, but does not explain what the returned context contains (e.g., settings, status). Given sibling tools and the lack of output schema, a bit more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, with a clear description in the schema itself. The tool description adds no additional meaning beyond what the schema provides for title_id. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches context for a game title, using the verb 'Fetch' and specifying 'safe, subscription-gated context'. It distinguishes from siblings like glitch_list_titles and glitch_select_title by focusing on context retrieval rather than listing or selection. However, it could be more specific about what 'context' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives like glitch_list_titles or glitch_select_title. It mentions 'subscription-gated' as a condition but lacks explicit guidance on when to invoke or avoid this tool, and no alternatives are listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List downloadable files and hosted report artifacts for a Glitch Agent run.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| run_id | Yes | Glitch agent run id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, making safety clear. The description adds context about the content of artifacts (downloadable files and reports) but does not discuss any additional behavioral traits (e.g., error states, pagination).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with two parameters and no output schema, the description is adequate but does not mention the return format or any potential limitations. Given the presence of thorough annotations, it meets minimal requirements but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both title_id and run_id. The tool description does not add any extra meaning or usage hints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resources 'downloadable files and hosted report artifacts' for a 'Glitch Agent run'. It distinguishes from siblings like glitch_list_titles and glitch_list_pending_actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving artifacts of a run, but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open or answered guidance requests for a title or run.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| run_id | No | Glitch agent run id. | |
| status | No | open | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, destructiveHint, idempotentHint) already cover behavioral traits; the description adds no extra context such as pagination, rate limits, or scope limitations, so it does not enhance transparency beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the main action and efficiently conveys the core purpose with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations and schema descriptions for some parameters, the description covers the basic use case. However, it omits default values (e.g., limit=50) and does not mention result ordering or pagination, which would improve completeness for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context that filtering is by title or run, but does not explain status enum values beyond 'open/answered' (missing 'dismissed', 'all') or the limit parameter. Schema coverage is 50%, so description partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific resource ('guidance requests') and filter criteria ('open or answered', 'for a title or run'), clearly distinguishing it from siblings like glitch_answer_guidance or glitch_list_pending_actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing guidance requests but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List proposed, guidance-needed, approval-needed, approved, or executed actions for a title.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| run_id | No | Glitch agent run id. | |
| status | No | pending | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds only the status enumeration already present in the schema, with no additional behavioral insights like pagination or implications of missing parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with the verb and resource front-loaded. It lists the statuses clearly but the phrasing is slightly run-on; however, it avoids redundancy and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with annotations covering safety and no output schema, the description adequately states what is listed but does not hint at the output structure, pagination, or how it fits into the workflow (e.g., as a precursor to executing actions). Slightly incomplete given the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (title_id and run_id have descriptions). The description adds context by listing the statuses that can be filtered, but does not describe the 'limit' parameter or the semantics of 'run_id'. It partially compensates but could provide more detail on how parameters affect results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'list' and the resource 'actions for a title' and enumerates the statuses it can filter. However, it does not fully differentiate from other list tools like glitch_list_guidance or glitch_list_artifacts, as it only implies through context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 versus alternatives (e.g., glitch_list_guidance, glitch_list_artifacts). The description fails to mention when not to use it or provide comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List user-visible timeline events for a Glitch Agent run.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| run_id | Yes | Glitch agent run id. | |
| after_id | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds minimal context beyond 'user-visible', which does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence of 10 words with no extraneous information. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return format, pagination (limit), and the cursor (after_id). It only mentions 'user-visible timeline events', leaving critical details undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (title_id and run_id have descriptions, after_id and limit do not). The tool description does not add any parameter semantics, failing to compensate for the missing schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'user-visible timeline events for a Glitch Agent run', distinguishing it from sibling tools that 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.
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 vs alternatives, or prerequisites like title_id can be omitted if previously set. The usage is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List game titles available to the authenticated Glitch user or title MCP token.
| Name | Required | Description | Default |
|---|---|---|---|
| include_archived | No | Include archived titles when the token has permission. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds context about authentication requirements and token permissions for archived titles, which adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single optional parameter, no output schema), the description is mostly complete, though it could optionally describe the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the description does not add new meaning beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state it lists game titles available to the authenticated user or token, which is specific and distinguishes it from sibling tools like glitch_select_title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving titles before selection, but does not explicitly state when to use or not use it, nor provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Glitch dashboard links for a title, run, action, or billing screen.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| kind | No | title | |
| run_id | No | Glitch agent run id. | |
| action_id | No | Glitch agent action id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description confirms it returns links (read-only) and specifies the kinds of screens, adding some behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb 'Return', no wasted words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with good annotations, the description adequately explains the output and the options for the kind parameter. Lacks details on parameter relationships (e.g., when run_id is needed) but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (75%), so baseline is 3. The description lists the kinds ('title, run, action, or billing screen') which maps to the 'kind' enum, adding marginal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'dashboard links', specifying the types: title, run, action, or billing screen. It distinguishes from sibling tools as the only tool returning dashboard links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. No explicit context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reject a proposed or approval-needed Glitch Agent action.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| action_id | Yes | Glitch agent action id. | |
| reason | No | Rejected from MCP client. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and description aligns with that ('Reject'). However, description adds no additional behavioral details beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear verb-resource structure, no filler, front-loaded with essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal context for a destructive action with three parameters and no output schema. Lacks details on side effects, prerequisites, or what happens after rejection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (>50%), baseline is 3. Tool description adds no new parameter information beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (Reject) and resource (Glitch Agent action that is proposed or needs approval). It distinguishes from sibling tools like glitch_approve_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage context (rejecting proposed/approval-needed actions) but does not explicitly state when to use this tool vs alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select a title for this MCP process after verifying access with the hosted Glitch service.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | Yes | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds no additional behavioral context beyond implying a verification step. It does not clarify the state change or outcome of selection, and no behavioral traits beyond annotations are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence of 13 words with zero waste. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, annotation-rich tool with no output schema, the description is mostly adequate. It mentions a prerequisite but lacks explanation of what happens after selection or the tool's role in the MCP process lifecycle. A minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter. The description adds no extra meaning beyond the schema's parameter description, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Select' and resource 'title' within the MCP process context. It mentions a prerequisite (after verifying access) but does not explicitly distinguish this tool from siblings like glitch_list_titles or glitch_get_title_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that access verification must precede this tool's use, but it gives no explicit when-to-use, when-not-to-use, or alternative guidance. Siblings like glitch_list_titles are not mentioned as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a paid Glitch Agent run for a title. Subscription and title permissions are enforced by Glitch.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| agent_id | No | Specific Glitch title agent id. Omit to use the title's default MCP agent. | |
| prompt | Yes | The user-visible task for the Glitch Agent. | |
| run_type | No | manual | |
| trigger_source | No | mcp | |
| live_mode | No | Request live mode. Server-side billing, connection, and approval gates still apply. | |
| background | No | Queue the run and return immediately. | |
| wait_for_completion | No | Poll until the run completes, pauses for guidance/approval, fails, or times out. | |
| timeout_ms | No | ||
| poll_interval_ms | No | ||
| attachment_ids | No | ||
| tool_command | No | ||
| session_context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds that it is 'paid' and 'permissions enforced', but does not elaborate on what constitutes destruction (e.g., credit consumption, state changes) or other behavioral nuances beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the core action and resource, achieving maximum conciseness. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, no output schema, openWorldHint), the description is highly insufficient. It does not explain how the run progresses, what the return value is, how to handle billing errors, or how to integrate with sibling tools like glitch_wait_for_agent_run. Critical behavioral context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no additional explanation for the 13 parameters. Schema coverage is only 46%, meaning many parameters lack inline descriptions, and the tool description does not compensate. For example, 'run_type' and 'trigger_source' are not explained in the description, leaving agents without guidance on their usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start a paid Glitch Agent run'), the resource ('for a title'), and includes context ('Subscription and title permissions are enforced by Glitch'). It effectively distinguishes from sibling tools like glitch_answer_guidance or glitch_get_agent_run by specifying the initiation of a run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the run is paid and that permissions are enforced, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to start a run vs. wait for it). The usage context is implied but not clearly delineated, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local image, video, or document (e.g. a screenshot, gameplay clip, or brief) to a Glitch title or run. Files become run attachments and potential social assets, treated as reference material behind the prompt-injection boundary.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| agent_run_id | No | Attach the file to a specific run. | |
| file_path | No | Path to a local file (image, video, or document) on the machine running this MCP. stdio only. | |
| content_base64 | No | Base64-encoded file contents. Use this instead of file_path over the HTTP transport. Requires file_name. | |
| file_name | No | File name. Inferred from file_path when omitted; required with content_base64. | |
| mime_type | No | MIME type. Inferred from the file extension when omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds behavioral context by stating that files become 'run attachments and potential social assets' and are 'treated as reference material behind the prompt-injection boundary', offering insight into security and asset implications 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every sentence adds value. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and moderate complexity. The description covers purpose and some behavioral context but fails to explain return values or clarify parameter combinations (e.g., file_path vs content_base64). Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% so all parameters are documented. The description does not add significant meaning beyond what the schema provides, though it does mention file types (image, video, document) which aligns with mime_type inference. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads local image, video, or document files to a Glitch title or run. It specifies the verb 'upload', the resource 'local file', and the destination 'Glitch title or run', distinguishing it from sibling tools like glitch_start_agent_run or glitch_select_title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, such as glitch_create_upload_url. It implies usage for uploading files as run attachments, but lacks when-not-to-use or alternative comparisons, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a Glitch Agent run until it completes, pauses for approval/guidance, fails, is canceled, or times out. Streams live events as progress/log notifications when the client supports them.
| Name | Required | Description | Default |
|---|---|---|---|
| title_id | No | Glitch game title id. Omit only after calling glitch_select_title or setting GLITCH_TITLE_ID. | |
| run_id | Yes | Glitch agent run id. | |
| timeout_ms | No | ||
| poll_interval_ms | No | ||
| stream | No | Stream live events as progress/log notifications when the client supports them. Falls back to polling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds behavioral context: it blocks until terminal states and streams live events. It does not contradict 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and key feature (streaming). Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential states and streaming capability. However, it does not explain the return value or the fallback to polling when streaming is unsupported. Overall, it is largely complete for a blocking wait tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 3 of 5 parameters with descriptions. The tool description does not elaborate on the remaining parameters (timeout_ms, poll_interval_ms) beyond what the schema provides. No additional semantic information is added for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for a Glitch Agent run to reach terminal states (complete, pause, fail, cancel, timeout). It also mentions streaming events, distinguishing it from sibling tools like glitch_get_agent_run which likely provides a non-blocking status check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when waiting for a run to finish, but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. No guidance on fallback behavior for streaming is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource or action (e.g., guidance, actions, runs, files). Even closely related tools like approve vs. execute vs. reject action have clearly different purposes, and descriptions further disambiguate them.
Most tools follow a consistent 'verb_noun' pattern (e.g., glitch_list_titles, glitch_start_agent_run). One exception is glitch_auth_status, which lacks a verb, and glitch_wait_for_agent_run uses a phrasal verb. Overall, the pattern is largely predictable.
With 20 tools, the set is slightly above the ideal 3-15 range but still well-scoped for the multi-faceted domain (authentication, billing, title management, agent runs, actions, files, guidance). No tool feels redundant.
The tool surface covers core workflows (start/wait/get runs, actions, guidance, files) but lacks basic lifecycle operations like listing all runs, canceling a run, or deleting artifacts. This creates notable gaps that an agent may need to work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI agents to 1000+ apps with managed authentication and tool-calling.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Give your AI agents the tools to build, manage, and run automation workflows.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Glitch-Gaming-Platform/Glitch-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
