Skip to main content
Glama

Get a playbook

get_playbook
Read-onlyIdempotent

Step-by-step guide for a common job, written for you to follow. Available: add-site (A new domain on a server that already runs sites: its own user, folder, PHP pool, web server block, database, SSL and a check that the other sites were not touched.); backups (Scheduled database and file backups with rotation, an optional off-server copy, and a tested restore.); bot-attack (A shop or site is slow or flooded by bots (layered navigation, search, login, account sign-up, API): find what is hitting it and slow it down without blocking customers or search engines.); drupal (Check-up and common jobs for Drupal 9, 10 and 11 with drush: status, security updates, database updates, cache, cron, configuration.); email (Order confirmations, password resets and contact forms that land in spam or never arrive: check how the site sends, the domain's SPF, DKIM and DMARC records, the server's reputation, and move sending to a proper mail service when that is the fix.); failed-services (Services marked failed on a server: tell the ones left behind by sites that were removed (Virtualmin, Plesk and cPanel leave per-site units) from the ones that broke, fix the broken ones, remove the leftovers in one approved plan, and leave the server with no failed units.); ghost (Where Ghost keeps things, ghost-cli as the site's owner, updates and restarts, mail, the database, backups and the common faults.); hardening (Review and tighten an existing server's security without breaking what runs on it.); laravel (Check-up and common jobs for Laravel apps with artisan: environment, deploy steps, migrations, queues and the scheduler as services, logs.); magento-upgrade (Move a Magento or Mage-OS shop to a newer version or patch level: compatibility check of PHP, database, search and modules, a rehearsal on a copy, then the live upgrade in a short maintenance window with a way back.); magento (A full Magento Open Source (or Mage-OS) shop on one server: nginx, PHP-FPM, MariaDB, OpenSearch, Valkey/Redis, cron, SSL, production mode.); malware-cleanup (Contain, investigate and clean a compromised Magento or WordPress site, then close the way in and change every credential.); migrate (Migrate a Magento or WordPress site (or any folder) from one of the user's servers to another, with a short maintenance window and a way back.); other-shops (What is where and the common jobs for three more kinds of site AskYourStack finds: Joomla 4 and 5, OpenCart 3 and 4, and Magento 1 / OpenMage.); performance (Measure a slow shop or site from the server (response times, PHP workers, database, caches, bots, memory, disk), name the real causes with numbers and fix them in order of impact.); prestashop (Check-up and common jobs for PrestaShop 1.7, 8 and 9: cache, debug mode, modules, shop address and SSL, maintenance mode, updates, security.); publish-content (Turn SEO data (Search Console, SE Ranking, a Semrush or other report the user uploads) into a content plan, then write articles, landing pages or category texts and save them as drafts in WordPress or Magento for the user to review.); restore (Bring a site, some files or a database back from a backup or an AskYourStack snapshot, after saving the current state, into a scratch place first when there is any doubt.); seo-dashboard (A site's search performance over the last 90 days as one visual page set in the Inter typeface. Fixes only the basics; what to analyse and show is the AI's judgement.); seo-technical (Technical SEO of a shop or site from the server side (what Googlebot really crawls, errors it gets, robots, sitemaps, redirects, canonicals, speed), combined with Search Console, SE Ranking or the user's exported reports, then fixes on the server.); server-setup (Turn an empty VPS into a sane, updated, secured base before anything is installed on it.); shopware (Check-up and common jobs for Shopware 6: scheduled tasks and the message queue as services, cache, plugins, themes, indexing, updates.); site-checkup (A health and security review of a Magento or WordPress site already in production, with a prioritised list of fixes.); site-down (A shop or site that does not answer, shows an error page or a blank page: find which layer failed (DNS, certificate, web server, PHP, database, disk, memory), bring it back and say why it happened.); staging (A private copy of a live shop or site on the same server or another, with its own database and address, closed to search engines and with emails and payments switched off.); updates (Security updates of the system, WordPress core, plugins and themes, or Magento security patches, with a snapshot first, checks after and the reboot planned with the user.); whizzycommerce (How to work on a WhizzyCommerce shop connected on the Sites & Apps page: what to read first, how changes are proposed and confirmed, what applies at once (colours, fonts), orders, prices, translations, design and own themes, SEO fields and redirects, and what to leave to the merchant.); woocommerce (Check-up and common jobs for WordPress shops: orders, background tasks, WP-Cron, updates with the database step, speed, and what never to cache.); wordpress (WordPress with nginx, PHP-FPM, MariaDB, Redis object cache, wp-cli, system cron and SSL.)

Input Schema

NameRequiredDescriptionDefault
nameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds that the content is a procedure meant for the agent to follow and that some playbooks end in an 'approved plan', hinting at approval workflows, but says nothing about size, structure or that the guide may steer the agent to other tools.

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 purpose is correctly front-loaded in one sentence, but the body is a very large wall of parenthetical mini-essays, only a fraction of which is needed to choose a playbook; much of that detail belongs in the playbook content the agent will fetch next. A single clause per entry would have served selection equally well.

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 a one-parameter catalog lookup with no output schema, the description supplies a full value legend and a minimal statement of what is returned. It would be more complete if it noted the guide's expected shape (ordered steps, expected approvals) so the agent knows how to act on the result.

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 0% and the single `name` property has no schema-level description, so the description must carry the load — and it does, describing the scope of all 29 allowed values in prose. It stops short of 5 because the enum values themselves are already self-describing strings and no format or matching guidance is added.

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 opening sentence gives a specific verb and resource: a step-by-step guide for a common job, written for the agent to follow. It is immediately distinguishable from siblings like run, whizzy_tools or list_jobs, though it never names a sibling or explicitly states the boundary between fetching a playbook and executing one.

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 per-entry summaries double as scenario triggers (a site is flooded by bots, a site does not answer, a shop needs updating), so the agent can infer which playbook applies to a given situation. There is no explicit 'use this before X' or exclusion against alternatives, so it falls short of a 5.

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.

Resources