"wordpress" matching MCP tools:

• search_docsA

  RoxyAPI Docs MCP Server (keyless, for coding agents)A

  Search the RoxyAPI knowledge base and get back ranked documentation snippets, each with a source URL. It covers API endpoints with their request and response fields, SDK usage for TypeScript, Python, PHP, C#, and the WordPress plugin, authentication and API keys, UI components, and step by step integration guides. Call this first whenever you need to integrate RoxyAPI into an app: to find which endpoint or SDK method to use, what parameters a call takes, how to authenticate, or how to wire a feature end to end. Pass the user question verbatim as `query`. If the first results miss, rephrase once and retry.

  ConnectorNo auth

• add_siteA

  BorealHostA

  Provision a site into a slot a plan you ALREADY PAY FOR includes. Two different things can be meant by "create a site". Buying one is the checkout flow (create_checkout → update → complete). This is the other: most plans include several sites, and this uses one of them at no extra cost. site_starter includes 5, site_plus 8, site_pro 12, and the agency plans more. `whoami` and `list_sites` show what the account already holds. ⚠ Prefer this over buying a second subscription when a slot is free. Sites under ONE subscription share one CPU pool, one disk quota and one rate-limit bucket — that shared budget is what the plan sells. Two subscriptions split it, so the customer pays twice for capacity they had. Requires: API key with write scope, on the account that owns the plan. Args: slug: Sub-domain for the new site (lowercase, digits, hyphens) subscription_id: The subscription whose slot to use client_name: Display name for the site (optional) domain: Custom domain; defaults to <slug>.borealhost.ai site_type: wordpress (default) | php | php-nodb | static-site. Choose here rather than provisioning WordPress and calling set_site_type afterwards — that installs a WordPress you then abandon in the docroot, and it costs a minute of provisioning. Returns: {"subscription_id": "uuid", "provisioning_job_id": "uuid", "slug": "my-second-site", "domain": "my-second-site.borealhost.ai", "status": "provisioning"} Poll get_site_status(slug) until it reports active. Errors: VALIDATION_ERROR: Plan includes a single site, slug taken, or every slot is in use (the message reports used/total) NOT_FOUND: Unknown subscription, or it belongs to another account

  ConnectorNo auth

• set_site_typeA

  BorealHostA

  Change what a site's docroot IS, without deleting anything. Types: wordpress WordPress, PHP and a database (the default) php PHP and a database, no WordPress php-nodb PHP, no database static-site HTML/CSS/JS only, no PHP and no database ⚠ NON-DESTRUCTIVE. Existing files stay on disk and existing databases are not dropped. They remain the customer's data and keep counting against their plan's quota — this changes how the site is SERVED, not what it holds. Converting back later finds everything where it was. ⚠ Moving to a type without PHP does not merely stop executing .php — it stops serving them. The vhost returns 404 for php/phtml, because falling through to the static handler would return the file's SOURCE, and a docroot converted from WordPress still contains wp-config.php with the database password in it. Shared hosting only. On a VPS the whole container is the customer's and they reconfigure it with the tools inside it. Requires: API key with write scope. Args: slug: Site identifier site_type: One of the four values above Returns: {"from": "wordpress", "to": "static-site", "database_created": false, "placeholder_seeded": false, "pool_removed": true} `placeholder_seeded` is true only when the docroot was EMPTY — an existing site's content is never overwritten. Errors: VALIDATION_ERROR: Unknown type, or the site is not on shared hosting NOT_FOUND: Unknown slug or not reachable by this account

  ConnectorNo auth

• update_checkoutA

  BorealHostA

  Set buyer email and desired site slug on a checkout session. The checkout must be in "not_ready" status. Setting requested_slug transitions status to "ready" (required before completing). Args: checkout_id: Checkout session ID from create_checkout buyer_email: Optional email — if omitted, a synthetic agent identity (agent-{uuid}@api.borealhost.ai) is created at completion requested_slug: Desired site identifier. Must be 3-50 chars, lowercase alphanumeric + hyphens, cannot start/end with hyphen. Must be globally unique. site_type: What the docroot should serve — wordpress (default), php, php-nodb or static-site. ⚠ Set it HERE: the checkout locks once buyer info is set, so choosing later means provisioning a WordPress you then convert away from, abandoning its tree in the docroot and paying a minute of provisioning for nothing. Returns: {"id": "uuid", "sku": "...", "plan_slug": "...", "billing_period": "monthly", "status": "ready", "buyer_email": "...", "requested_slug": "my-site", "created_at": "iso8601"} Errors: VALIDATION_ERROR: Invalid slug format or slug already taken FORBIDDEN: Missing checkout_secret NOT_FOUND: Unknown checkout_id

  ConnectorNo auth

• create_ftp_accountA

  BorealHostA

  Create an SFTP account on a site. The account is chrooted to /var/www and lands in home_dir. Password must be at least 8 characters. Username must be lowercase alphanumeric. Requires: API key with write scope. Args: slug: Site identifier username: SFTP username (lowercase, max 32 chars) password: Password (min 8 chars) home_dir: Landing directory inside /var/www. Leave empty to land at /var/www itself, which lists every site directory. Returns: {"success": true, "username": "sftpuser", "home_dir": "/wordpress", "protocol": "sftp"}

  ConnectorNo auth

• upgrade_to_clusterA

  mcpA

  THE WAY TO MAKE AN EXISTING APP HIGHLY AVAILABLE. If the user asks for high availability, redundancy, no single point of failure, surviving a host or VM failure, or 'stay up if a machine dies', this is the tool: point it at their running VM and pass high_availability:true. It needs no rebuild and no redeploy, and the URL does not change. Turns a single running instance into a horizontally-autoscaling cluster: snapshots the instance and puts your SOURCE VM behind a load balancer as its ALWAYS-ON BASELINE MEMBER, then an autoscaling group adds EXTRA members (booted from that snapshot) on CPU load and scales them back down to zero. FLAVOR — LEAD WITH A MEMORY-OPTIMIZED SMALL-DISK FLAVOR (m1.mem16/m1.mem32) for the cluster, and ideally have the SOURCE VM on one too: clustering snapshots the source VM's FULL disk, so DISK size (not RAM) drives how long the cluster takes to build and to add each member under load — a 40 GB mem flavor is several times faster to snapshot and scale than a 160 GB standard flavor (m1.xlarge) and costs less for the same RAM. If the source VM is on a big-disk flavor, RECOMMEND migrating the app onto a mem-flavor VM first (a root disk cannot be shrunk in place), even though it is extra work — it pays off on every scale-out, and a clustered app is stateless anyway (state in the managed DB) so the lean disk fits. Expect a DRASTICALLY better clustering experience on a mem flavor: far faster cluster-create, snapshots, and every scale-out. The user can override with any flavor. At rest ONLY your source VM serves — there is NO idle extra VM to pay for (the source VM is the cluster's minimum, so the floor is 0 extra members). Use it to LOAD-SCALE a stateless app tier while managed services hold state: it becomes highly-available UNDER LOAD (multiple members behind the LB), but at rest a SINGLE source VM serves — and that source VM is a plain VM, not an autoscaled member, so it is NOT auto-replaced if it fails while idle (only the autoscaled extra members are ASG-managed and self-healed). If you need always-on redundancy, keep the app under enough load to hold >=1 extra member, or use a separate always-on setup. BILLED — at rest it costs just your source VM (which you already run) plus the load balancer; under load it adds up to max_size EXTRA members at the member flavor (flavor_id), billed only while they run. In guided mode show the cost that way (now: source VM already running + the LB; under load: up to max_size x the member flavor) and get the user's explicit go first. redu automatically repoints the extra members from the old single-VM URL to the load-balancer URL across app config. It REFUSES a STATEFUL VM with 409 cluster_needs_stateless unless confirm_stateless:true. To have redu FIX a stateful VM for you instead of refusing, pass auto_restructure:true — for a single_vm Postgres it fully-automatically provisions a managed DB + migrates the data + repoints the members; for a compose-stack DB it provisions the matching managed DB (set restructure_engine, e.g. 'mysql'/'mariadb' for WordPress) and returns migration commands to run from the app VM. WordPress/WooCommerce is not generic autoscaling: managed DB alone is not enough because wp-content/uploads is file state. Use app_profile:'wordpress'/'woocommerce', cluster_media_mode:'media_space', and either media_space_id or create_media_space:true so all members mount the same uploads filesystem; otherwise the backend refuses with 409 cluster_needs_media_space. PUT THE CLUSTER ON THE SAME private network as the managed DB and media space. HA: cluster members are spread across DIFFERENT physical hosts automatically, and an autoscaled member that is destroyed is REBUILT AUTOMATICALLY in 1.5 to 5 minutes depending on how it failed with no action from you (the always-on source/hero VM is a plain VM and is NOT covered by that). CRITICAL for members: the app must start on EVERY boot (systemd unit or container restart policy) - if it only starts from a first-boot cloud-init script, a rebooted or resized member comes back with no app, silently never rejoins the load balancer, and the cluster quietly loses capacity with nothing reporting an error. Pass startup_command if the app does not already auto-start on boot, and have it bind its port only once it is genuinely ready to serve (the health check can only see whether the port is open). SEQUENCING - this catches people: the snapshot is taken IMMEDIATELY, and every member boots from it, so the source VM's app must already be RUNNING before you call this. Clustering a freshly-created VM whose cloud-init has not finished captures an image with no enabled service, and all members then come up ACTIVE while failing the load-balancer health check forever - a cluster that looks built and serves nothing. Verify the app answers on its port first (get_ssh_command, or just fetch the VM's URL). The snapshot upload can take several minutes; poll list_clusters until CREATE_COMPLETE.

  ConnectorNo auth

• create_relational_databaseA

  mcpA

  Provisions a managed MySQL (or MariaDB) database on a dedicated VM on your private network — the relational-database resource (use this instead of create_database when the app needs MySQL/MariaDB, e.g. WordPress, NextCloud, Matomo, many PHP/LAMP apps). Requires a recent plan_managed_datastore. For app deployments, prefer deploy_app database:'managed' with db_engine mysql/mariadb so plan_deploy includes and wires the DB automatically. It is PRIVATE — reachable only from another instance on the same private network, via the DB's internal/private IP (port 3306), not a public address. Get the ids from plan_managed_datastore/list_flavors/list_private_networks/list_keypairs. Provisioning takes ~5 min; poll list_relational_databases until status='ready', then the connection details (private_ip, port 3306, db_name, db_user) are populated. MySQL is created with mysql_native_password auth so older clients/apps connect cleanly. (ClickHouse is a separate resource — use create_clickhouse / list_clickhouse_databases.)

  ConnectorNo auth

• deploy_composeA

  mcpA

  Deploys a MULTI-CONTAINER app — a repo that ships docker-compose.yml / compose.yaml — onto ONE VM via podman-compose, and exposes one or more services at redu.cloud URLs. Use this instead of deploy_app when the repo is a compose stack. Same prereqs + source modes as deploy_app; always run plan_deploy first. PORT is the HOST port for the exposed service. DB: 'compose' uses the stack's own db container; 'managed' provisions a separate managed Postgres/MySQL/MariaDB VM and appends connection env. For WordPress/WooCommerce cluster intent, do not leave the compose db service/local uploads as state: pass app_profile, cluster_target:true, database:'managed', db_engine:'mariadb' or 'mysql', cluster_media_mode:'media_space', and either media_space_id or create_media_space:true. Redu writes an override file that points the WordPress service at managed DB env and mounts the media space into /var/www/html/wp-content/uploads. Poll get_deployment until ready.

  ConnectorNo auth

• start_loginA

  elevai Commerce DemoA

  Startet eine Anmeldung im Shop. Gibt eine Adresse und einen Pruefcode zurueck. Die Person oeffnet die Adresse selbst im Browser, meldet sich dort bei WordPress an und bestaetigt. Frag NIE nach einem Passwort und nimm keines entgegen — dieses Werkzeug hat kein Feld dafuer, und der Shop erwartet es nur auf seiner eigenen Seite. Gib die Adresse und den Pruefcode unveraendert aus und sage, dass der Code auf der Seite derselbe sein muss. Danach mit get_login_status nachfragen.

  ConnectorOAuth

• export_pageA

  Postclick by PPC.io: Landing Page CROA

  Free. Packages a finished page as a zip that runs on any static host: index.html with every image it uses pulled into assets/, plus a README and metadata.json. Returns a download link. This is the one for a user who wants the files. share_page is the one for a user who wants something to look at. It also returns implementation_prompt: step by step instructions for putting this page live on the user's own site. Postclick does not host pages, so this is how a page ships. If you have access to their site, you can carry those steps out yourself; otherwise hand the prompt to whoever does. Pass platform when you know where the site lives, because the steps for WordPress and for Webflow are genuinely different. Ask if you do not know. Every variant stops at a draft and never publishes without the user confirming.

  ConnectorNo auth

• intel_stackA

  TunnelMind Data APIB

  Fetches up to 32KB of the domain's HTML and response headers from the edge, then fingerprints the content for known CMS platforms, JavaScript frameworks, CDN providers, and analytics tools. Detection is based on meta generator tags, script src patterns, response headers, and cookie names. Use this tool when: - You need to know what CMS (WordPress, Drupal, Shopify) a site runs. - You are assessing a domain's infrastructure before a security review. - You want to identify analytics or marketing tools a site embeds. Do NOT use this tool when: - You want HTTP headers and security posture — use `intel_http` instead. - You want tracker database classification — use `get_domain` instead. - You need robots.txt AI policy — use `intel_robots` instead. Inputs: - `domain` (query, required): Domain to fingerprint. Returns: - `cms`: detected content management system, or null. - `frameworks`: JavaScript/backend frameworks detected. - `cdn`: CDN provider detected, or null. - `analytics`: analytics and tracking tools detected. - `meta_generators`: raw meta generator tag values. Cost: - Free. No API key required. Latency: - Typical: 2-4s (HTML fetch), p99: 7s.

  ConnectorNo auth

• aeo_list_sitesA

  mcpA

  Liste les sites WordPress connectés au compte (plugin Everlange Connect) : domaine, statut, modules actifs, version du bundle.

  ConnectorNo auth

• deploy_appA

  mcpA

  Deploys an app to a VM and exposes it at a public https://<name>-<id>.redu.cloud URL. The container is built ON the VM. PREREQS — run check_deploy_prerequisites first for network_id + keypair_name, then plan_deploy for cost approval. Source can be git repo or prepare_upload source_token. PORT must be the real app listen port. To wire a DB, pass database:'managed' (dedicated managed datastore VM on the same private network, reused on same-name redeploy) or database:'single_vm' for Postgres on the app VM. Choose db_engine ('postgres' default; 'mysql'/'mariadb' for WordPress/Matomo/LAMP, managed only). For WordPress/WooCommerce cluster intent, do not use generic stateless deploy: pass app_profile, cluster_target:true, database:'managed', db_engine:'mariadb' or 'mysql', cluster_media_mode:'media_space', and either media_space_id or create_media_space:true. Redu mounts the media space into wp-content/uploads and refuses unsafe local uploads. Build+provision takes minutes; poll list_deployments/get_deployment.

  ConnectorNo auth

• estimate_auditA

  WebsiteIQA

  Before audit crawling, reads robots.txt and a bounded same-host sitemap tree—including namespaced, WordPress, and Yoast-style indexes—then returns page scope plus standard and white-label USDC quotes. Up to 10 pages cost $0.01 standard or $0.02 white-label; each additional page costs $0.001 or $0.002. A payable quote includes the quoteId required by start_paid_audit.

  ConnectorNo auth

• aeo_list_sitesA

  mcpA

  Liste les sites WordPress connectés au compte (plugin Everlange Connect) : domaine, statut, modules actifs, version du bundle.

  ConnectorNo auth

• get_ability_infoA

  WordPress MCP ServerA

  Get the full input schema and details for a single ability, when discover_abilities isn't enough. Pass the exact ability_name from discover_abilities.

  ConnectorOAuth

• basile_search_companiesA

  BasileA

  Cherche des ENTREPRISES (registre légal + LinkedIn + Google My Business) dans Basile. Renvoie { total, establishmentsTotal, leads[], pagination.nextToken }. limit défaut 25, max 1000. `total` = sociétés (dédupliquées par domaine) ; `establishmentsTotal` = POINTS DE VENTE (fiches Google). Pour exporter les points de vente : basile_export avec mode:"locations". ⚠️ COÛT : 1 crédit par fiche renvoyée (limit=25 → 25 crédits), à chaque appel. Compte d'abord avec basile_count (gratuit et exact) ; le `total` renvoyé ici est plafonné à 100 000. FORME DES FILTRES : - Filtre texte = {"include":[...], "exclude":[...]} — include = OR, exclude = NOT. - Plusieurs filtres différents = ET entre eux. - People : filtres numériques = range objet {">=":n,"<=":n} (ops >, >=, <, <=). - Companies : filtres numériques = champs simples `_min` / `_max` (ex. capital_min, headcount_max). FILTRES COMPANIES (POST /companies/find) : Généraux (3 sources Legal+LKI+GMB) : name (contains), activity (métier unifié — le plus puissant ; IDs via basile_activity_suggest), with_email (bool, uniquement les entreprises dont le domaine a au moins un email crawlé). Legal-only : naf_code (préfixe ".x" possible, ex "41.x"), headquarters_naf_code, headquarters_department_code (ex "75","13"), headquarters_postal_code, legal_form (accepte code court SARL/SAS/SASU/EURL/SA/SCI…, code INSEE 5710, OU libellé complet), legal_category (code INSEE), siren, capital_min/capital_max, publishable (bool), creation_date_min/creation_date_max (année ex "2015"), created_since_months (nombre — entreprises créées dans les N derniers mois, ex 3 ; plus précis que creation_date pour « créées récemment »). Région : utiliser region (NOM canonique, ex "Île-de-France") ou headquarters_department_code (ex "75"). ⚠️ headquarters_region_code (code INSEE) est IGNORÉ (no-op, pas de résolveur) — ne pas l'utiliser. Legal+LKI (exclut GMB) : headquarters_city, headquarters_country_code (ex "FR"), headcount_min/headcount_max (effectif). LinkedIn-only : domain (contains), tech_stack (techno du site, ex "Shopify"/"WordPress"). ⚠️ followers : pas de données → ne pas utiliser. ⚠️ industry_main / company_type = LinkedIn, lacunaires/peu fiables → pour un secteur préférer activity ou naf_code. GMB-only : rating_min/rating_max (0-5), reviews_min/reviews_max, is_opening (bool, ouvert dimanche). Spécial : company_ceased (bool) — METTRE false par défaut (entreprises actives uniquement). Pilotage source : source ("Legal"|"LKI"|"GMB"), with_legal_data (bool), with_linkedin_page (bool). CONSEILS : métier → activity (IDs via basile_activity_suggest) sinon naf_code. France → headquarters_country_code:{include:["FR"]} ou headquarters_department_code.

  ConnectorOAuth

• list_filesA

  BorealHostA

  List files and directories in a site's container. Path scoping depends on the plan: - Shared plans: rooted at wp-content/ (WordPress content directory) - VPS/dedicated plans: full filesystem access Requires: API key with read scope. Args: slug: Site identifier path: Relative path to list (empty for root of accessible area) Returns: {"path": "/", "entries": [{"name": "index.php", "type": "file", "size": 1234, "modified": "iso8601"}, {"name": "uploads", "type": "directory", "modified": "iso8601"}]} Errors: NOT_FOUND: Unknown slug or path doesn't exist

  ConnectorNo auth

• database_search_replaceA

  BorealHostA

  Search and replace in WordPress database (e.g. URL migration). Handles serialized data safely. Use dry_run=true first to preview changes. Requires: API key with write scope. Args: slug: Site identifier old: String to search for (e.g. "http://old-domain.com") new: Replacement string (e.g. "https://new-domain.com") dry_run: Preview only without making changes (default: true) Returns: {"replacements": 42, "tables_affected": 5, "dry_run": true}

  ConnectorNo auth

• list_media_spacesA

  mcpA

  Lists Redu media spaces: private NFS media VMs backed by persistent volumes. For WordPress/WooCommerce clusters, reuse one on the app's private network for wp-content/uploads, or pass create_media_space:true to deploy_app/deploy_compose/upgrade_to_cluster so Redu creates one.

  ConnectorNo auth

• citerank_get_wp_healthA

  CiteRank MCPA

  Check the health of all deployments on your connected WordPress site. Returns post-level schema status (active/missing/modified/deleted) and file-level checks for llms.txt, a2a.json, toolcatalog.json, and robots.txt rules.

  ConnectorNo auth