Az MCP-szerver beállításai

Környezeti változók, settings.json, eszközök korlátozása, tokenhasználat, más bővítmények képességei, erőforráskorlátok.

A szerver a beállításokat környezeti változókból és egy settings.json fájlból veszi. A környezeti változók elsőbbséget élveznek, így tarthatsz egy alapfájlt, és futásidőben felülírhatsz egyes értékeket.

Környezeti változók

Változó	Kötelező	Alapérték	Leírás
`MAINWP_URL`	Igen		A MainWP vezérlőpult alapcíme
`MAINWP_USER`	Igen*		Az Application Password tulajdonosának WordPress-belépési neve vagy e-mail-címe, nem a megjelenített név
`MAINWP_APP_PASSWORD`	Igen*		WordPress Application Password
`MAINWP_TOKEN`	Nem		MainWP REST API bearer token. Az Abilities API nem fogadja el, lásd alább
`MAINWP_SKIP_SSL_VERIFY`	Nem	`false`	Az SSL-tanúsítvány ellenőrzésének kihagyása (csak fejlesztéshez)
`MAINWP_ALLOW_HTTP`	Nem	`false`	HTTP-címek engedélyezése (a hitelesítő adatok titkosítatlanul mennek)
`MAINWP_SAFE_MODE`	Nem	`false`	Minden romboló művelet blokkolása
`MAINWP_REQUIRE_USER_CONFIRMATION`	Nem	`true`	Kétlépéses megerősítés a romboló műveleteknél
`MAINWP_ALLOWED_TOOLS`	Nem		Eszközök vesszővel elválasztott engedélyezőlistája
`MAINWP_BLOCKED_TOOLS`	Nem		Eszközök vesszővel elválasztott tiltólistája
`MAINWP_SCHEMA_VERBOSITY`	Nem	`standard`	A sémák részletessége: `standard` vagy `compact`
`MAINWP_RESPONSE_FORMAT`	Nem	`compact`	Az eszközválaszok JSON-formátuma: `compact` vagy `pretty`
`MAINWP_RATE_LIMIT`	Nem	`60`	Legfeljebb ennyi API-kérés percenként (`0` kikapcsolja)
`MAINWP_REQUEST_TIMEOUT`	Nem	`30000`	Kérés időkorlátja ezredmásodpercben
`MAINWP_MAX_RESPONSE_SIZE`	Nem	`10485760`	Egy válasz legnagyobb mérete bájtban (10 MB)
`MAINWP_MAX_SESSION_DATA`	Nem	`52428800`	A munkamenet összesített adatmennyiségének határa bájtban (50 MB)
`MAINWP_RETRY_ENABLED`	Nem	`true`	Automatikus újrapróbálás átmeneti hibáknál
`MAINWP_MAX_RETRIES`	Nem	`2`	Összes próbálkozás az első kéréssel együtt
`MAINWP_RETRY_BASE_DELAY`	Nem	`1000`	Az újrapróbálások közti alapkésleltetés ezredmásodpercben
`MAINWP_RETRY_MAX_DELAY`	Nem	`2000`	Az újrapróbálások közti legnagyobb késleltetés ezredmásodpercben
`MAINWP_ABILITY_NAMESPACES`	Nem	`mainwp`	A névterek vesszővel elválasztott engedélyezőlistája

* Párban kötelező: ez a hitelesítés módja.

A hitelesítés a MAINWP_USER és a MAINWP_APP_PASSWORD párosa. Az Abilities API, az egyetlen API, amelyet a szerver hív, a natív WordPress-hitelesítést használja, és nem fogad el MainWP REST API bearer tokent. A MAINWP_TOKEN kompatibilitás miatt még beolvasásra kerül, és akkor használatos, ha nincs Application Password, de az Abilities-végpontoknál hibát ad. Használj Application Passwordöt.

A beállításfájl

Hozd létre a settings.json fájlt az alábbi helyek egyikén, ebben a sorrendben keresve:

./settings.json (a szerver munkakönyvtára)
~/.config/mainwp-mcp/settings.json

Az @mainwp/mcp 1.2.0-tól a munkakönyvtárbeli settings.json nem lazíthat a biztonsági beállításokon: a requireUserConfirmation: false, a skipSslVerify: true és az allowHttp: true értéket ott figyelmen kívül hagyja, és figyelmeztetést ír a stderr-re. Ezeket környezeti változókkal vagy a felhasználói fájlban add meg.

{
  "dashboardUrl": "https://a-te-vezerlopultod.hu",
  "username": "admin",
  "appPassword": "xxxx xxxx xxxx xxxx xxxx xxxx",
  "skipSslVerify": false,
  "safeMode": false,
  "schemaVerbosity": "standard",
  "rateLimit": 60
}

A hitelesítő adatokat tartalmazó fájlhoz szűkítsd a jogosultságokat:

chmod 600 ~/.config/mainwp-mcp/settings.json

A csomag settings.schema.json néven JSON-sémát is tartalmaz a fejlesztőeszközök automatikus kiegészítéséhez.

Mezők megfeleltetése

settings.json	Környezeti változó	Típus
`dashboardUrl`	`MAINWP_URL`	szöveg
`username`	`MAINWP_USER`	szöveg
`appPassword`	`MAINWP_APP_PASSWORD`	szöveg
`apiToken`	`MAINWP_TOKEN`	szöveg
`skipSslVerify`	`MAINWP_SKIP_SSL_VERIFY`	logikai
`allowHttp`	`MAINWP_ALLOW_HTTP`	logikai
`safeMode`	`MAINWP_SAFE_MODE`	logikai
`requireUserConfirmation`	`MAINWP_REQUIRE_USER_CONFIRMATION`	logikai
`allowedTools`	`MAINWP_ALLOWED_TOOLS`	szövegtömb
`blockedTools`	`MAINWP_BLOCKED_TOOLS`	szövegtömb
`schemaVerbosity`	`MAINWP_SCHEMA_VERBOSITY`	szöveg
`responseFormat`	`MAINWP_RESPONSE_FORMAT`	szöveg
`rateLimit`	`MAINWP_RATE_LIMIT`	szám
`requestTimeout`	`MAINWP_REQUEST_TIMEOUT`	szám
`maxResponseSize`	`MAINWP_MAX_RESPONSE_SIZE`	szám
`maxSessionData`	`MAINWP_MAX_SESSION_DATA`	szám
`retryEnabled`	`MAINWP_RETRY_ENABLED`	logikai
`maxRetries`	`MAINWP_MAX_RETRIES`	szám
`retryBaseDelay`	`MAINWP_RETRY_BASE_DELAY`	szám
`retryMaxDelay`	`MAINWP_RETRY_MAX_DELAY`	szám
`abilityNamespaces`	`MAINWP_ABILITY_NAMESPACES`	szövegtömb

Ha mindkét hitelesítési mód jelen van, a felhasználónév és Application Password páros elsőbbséget élvez az apiToken-nel szemben.

Több vezérlőpult

Adj minden vezérlőpultnak külön mappát a saját settings.json fájljával, és az AI-kliens konfigurációjában a cwd beállítással mutass minden szerverbejegyzést a megfelelő mappára:

{
  "mcpServers": {
    "mainwp-staging": {
      "command": "npx",
      "args": ["-y", "@mainwp/mcp"],
      "cwd": "/path/to/staging-credentials"
    }
  }
}

Mivel a ./settings.json fájlt keresi először, minden szerverpéldány a saját munkakönyvtárából veszi a hitelesítő adatokat.

Első indítás (telepítési mód)

Az @mainwp/mcp 1.3.0-tól a vezérlőpult címe és hitelesítő adatok nélkül indított szerver nem áll le. Telepítési módban csatlakozik az AI-klienshez: a MainWP-eszközök rejtve maradnak, helyettük két telepítőeszköz jelenik meg, így a beállítást a beszélgetésben fejezheted be.

A mainwp_get_setup_status megmondja, mi hiányzik, és telepítési útmutatót ad, amelyet az asszisztens átad neked. Ha a hitelesítő adatok megvannak, de a vezérlőpult induláskor nem volt elérhető, a hívás újra megpróbálja a kapcsolatot a már betöltött adatokkal.
A mainwp_configure a vezérlőpult címét, a felhasználónevet és az Application Passwordöt kéri, ellenőrzi őket a vezérlőpulton, és elmenti.

A beállítást kétféleképpen fejezheted be. Az ajánlott mód, hogy magad adod meg az adatokat: a MAINWP_URL, MAINWP_USER és MAINWP_APP_PASSWORD értéket írd az MCP-kliens konfigurációjában a szerver bejegyzésének env blokkjába, vagy a ~/.config/mainwp-mcp/settings.json fájlba, majd indítsd újra a klienst. Így a jelszó sosem megy át a beszélgetésen. A csevegésbe beírás is lehetséges: az asszisztens összegyűjti a három értéket, és meghívja a mainwp_configure eszközt. A szerver ellenőrzi őket, a ~/.config/mainwp-mcp/settings.json fájlba írja csak a tulajdonos számára hozzáférhető jogosultsággal (0600, 0700-as mappában), és a jelszót törli a saját naplóiból és minden válaszából. Az Application Password független a WordPress belépési jelszavadtól, és bármikor visszavonhatod a profilodban.

Mielőtt választasz: a csevegésbe írt jelszó a beszélgetés előzményeibe is bekerül, amelyet az AI-kliens és a szolgáltatója megőrizhet. Ha később ez zavar, vond vissza a jelszót, és hozz létre újat.

Sikeres beállítás után a teljes eszközlista ugyanabban a munkamenetben megjelenik azoknál a klienseknél, amelyek követik az MCP list-changed értesítéseit. Amelyik kliens magától nem frissít, ott újracsatlakozás vagy újraindítás kell. A mainwp_configure visszautasítja a mentést, ha az eredményt úgyis figyelmen kívül hagynák vagy felülírnák:

Valamelyik kapcsolati környezeti változó (MAINWP_URL, MAINWP_USER, MAINWP_APP_PASSWORD, MAINWP_TOKEN) be van állítva. A környezeti változók erősebbek az általa írt fájlnál, ezért ott fejezd be a beállítást.
A szerver munkakönyvtárában van settings.json. Azt töltené be elsőként, és tartósan elfedné a mentett hitelesítő adatokat.
A szervernek már vannak betöltött hitelesítő adatai, akár működnek, akár nem. Lásd a következő részt.

Csak a három kapcsolati mezőt írja, biztonsági beállítást soha. Ha a mainwp_configure eszközt a blockedTools beállításban tiltod, a csevegésalapú beállítás teljesen megszűnik, a kézi mód viszont megmarad.

Elutasított hitelesítő adatok

Ha a vezérlőpult induláskor vagy egy telepítési kapcsolatellenőrzésnél elutasítja a betöltött hitelesítő adatokat, a szerver credentials_rejected állapotba kerül, és a MainWP-eszközök rejtve maradnak. A mainwp_get_setup_status hívás a hitelesítő adatok újraküldése nélkül jelenti a problémát. A mainwp_configure a csevegésből nem tudja lecserélni őket. Az állapotjelentés ezt tartalmazza:

Mező	Mit ellenőrizz
`username`	A beállított WordPress-belépési név vagy e-mail-cím. Az Application Passwordhöz hasonlító értéket visszatartja, és figyelmeztet, hogy a felhasználónév és a jelszó fel lehet cserélve.
`connectionSources`	Honnan jött az egyes kapcsolati értékek: `env` vagy `settings.json`. A különböző értékek különböző forrásból is jöhetnek.
`overriddenSettingsKeys`	A környezeti változók által felülírt fájlbeli értékek. Ha csak a fájlt szerkeszted, ezek tényleges értéke nem változik.
`problem` és `guidance`	Az elutasítás részletei és a helyreállítási útmutató. Jelszót vagy tokent nem tartalmaz.

Javítsd az értéket a connectionSources által mutatott forrásban (a fájlbeli nevekhez a mezők megfeleltetését használd), majd indítsd újra az MCP-klienst. A WordPress-belépési nevet vagy e-mail-címet, és a felhasználó profiljából egy Application Passwordöt használj, ne a megjelenített nevet vagy a fiók belépési jelszavát. Ha a diagnosztika szerint az Application Passwordök le vannak tiltva, a csatlakozás előtt állítsd vissza az elérhetőségüket a vezérlőpulton. A HTTP 401 hitelesítő adat elutasításnak számít. Más HTTP 4xx válasz csak akkor, ha a WordPress invalid_username, invalid_email, incorrect_password, application_passwords_disabled vagy application_passwords_disabled_for_user hibát jelez. A hálózati hiba, a TLS-hiba, a HTTP 5xx és a puszta HTTP 403 degraded állapotban hagyja a szervert, ahol a mainwp_get_setup_status újra próbálkozhat a betöltött adatokkal.

Miért nem cseréli le a telepítés a meglévő adataidat?

A csevegésalapú telepítés az első csatlakozást megoldja, de a magad beállította kapcsolatot soha nem írja felül. Ez szándékos. Az asszisztens szöveggel dolgozik, a szöveg pedig olyan helyről is jöhet, amelyre nem számítasz: egy olvasott oldal, egy webhelynév vagy egy szervertől kapott képességleírás nem neked, hanem az asszisztensnek szóló utasítást is hordozhat. Ha a telepítés felülírhatna egy működő konfigurációt, egy ilyen utasítás észrevétlenül egy idegen vezérlőpultra irányíthatná a szervert, és minden ezután kiadott parancsod oda menne. Ha a telepítés csak ott működik, ahol nincs mit felülírni, ez a lehetőség kizárt, mert az üres hitelesítő adatú szervernek nincs mit ellopni.

Kézenfekvőnek tűnne megengedni a cserét, ha a mentett adatok bizonyíthatóan rosszak, mert a vezérlőpult hitelesítési hibával elutasította őket. Ezt azért nem tesszük, mert így a távoli oldal döntené el, mikor írható felül a helyi konfigurációd: egy feltört vezérlőpult vagy egy meghamisított kapcsolat szándékosan elutasíthatna egy érvényes belépést, hogy megnyissa a cserét, anélkül hogy a jelszavadat ismerné. Ha az Application Passwordöt a WordPressben cserélted, vagy a mentett jelszó más okból hibás, a szerver egy megerősített elutasítás után nem küldi tovább. Az elutasított hitelesítő adatok diagnosztikája szerint frissítsd a jelszót adó forrást, majd indítsd újra a klienst.

Működési beállítások

A safeMode a szerveren blokkol minden romboló műveletet. Részletek a biztonsági fejezetekben.
A requireUserConfirmation a romboló műveletek kétlépéses előnézet-megerősítés folyamatát szabályozza (alapból be van kapcsolva).
Az allowedTools és a blockedTools az eszközkatalógust szűri, lásd lent.
A schemaVerbosity az eszközleírások részletességét cseréli a kontextus tokenjeire, lásd lent.
Az abilityNamespaces azt szabályozza, mely bővítmények képességei jelennek meg, lásd lent.
A responseFormat az eszközválaszok JSON-ját váltja compact (alapértelmezett) és pretty között.

Erőforráskorlátok

Ezek a megszaladt műveletek és a túl nagy válaszok ellen védenek.

Beállítás	Alapérték	Mi történik, ha túllépik
`rateLimit`	60/perc	A hívások addig hibásak, amíg az ablak le nem telik; a `0` kikapcsolja
`requestTimeout`	30000 ms	A kérés megszakad
`maxResponseSize`	10 MB	Az adott választ elutasítja
`maxSessionData`	50 MB	A további hívások `RESOURCE_EXHAUSTED` hibával elbuknak a szerver újraindításáig

Bemeneti korlátok

Az eszközbemenetekre a válaszadatoktól külön korlátok vonatkoznak. Minden szövegnél a hívott képesség bemeneti sémája deklarálhat pozitív, biztonságos egész maxLength értéket. Ez az érték helyettesíti az alapértéket, akkor is, ha kisebb, a lent megadott szerverplafonig. Hiányzó vagy érvénytelen deklarációnál az alapérték marad. Az ellenőrzés a beágyazott properties és a tömbök items sémáit is követi.

Bemenet	Korlát
Érvényes sémabeli `maxLength` nélküli szöveg	10 000 karakter
Érvényes sémabeli `maxLength` értékű szöveg	A deklarált érték, legfeljebb 67 108 864 karakter
Tömb	Tömbönként 1000 elem
Beágyazott objektumok és tömbök	Legfeljebb 5 szint mélység a legfelső szintű argumentumok alatt

A szöveghosszt a JavaScript UTF-16 kódegység-számolása szerint mérik; az ASCII és a base64 karakterek egyaránt egyet számítanak. A korlátot túllépő értéket elutasítja, nem vágja le. A szöveghosszhibák megnevezik a paramétert, a tényleges maxLength értéket és a limitSource forrást (default, schema vagy ceiling). Átviteli korlátok is érvényesek:

Bejövő stdio: a puffer korlátja 72 MiB UTF-8 bájt a bejövő JSON-RPC-adatra, a kérés burkolatával és az egyéb argumentumokkal együtt. Nem ASCII szöveg, JSON-escapelés vagy több nagy érték elérheti ezt a határt a szövegenkénti korlát előtt.
GET és DELETE: a bemenet a lekérdezési szövegben van kódolva. A teljes kódolt URL legfeljebb 8000 karakter lehet, akkor is, ha a séma hosszabb szöveget engedne. A túl nagy URL-eket küldés előtt elutasítja.
POST: a bemenet JSON-törzsben megy. A képesség sémája és a vezérlőpult PHP-, webszerver- vagy proxykorlátai további megkötéseket jelenthetnek. A szöveghossz-korlát nem bináris feltöltési méretengedély: a base64-kódolás növeli a küldött adat méretét.

Ezeket a bemeneti és átviteli korlátokat a maxResponseSize és a maxSessionData nem változtatja.

Újrapróbálás

Az átmeneti hibákat (HTTP 5xx, HTTP 429, hálózati megszakadás) exponenciális visszalépéssel és véletlenszerű eltéréssel próbálja újra. Csak az olvasó műveleteket próbálja újra, így az idempotencia megmarad; az írások azonnal elbuknak. A végleges hibákat (a 429-től eltérő 4xx, hitelesítési hibák) soha nem próbálja újra. Az újrapróbálkozások teljes ideje nem haladja meg a requestTimeout értéket, és az újrapróbálások megkerülik a sebességkorlátozót a holtpont elkerülésére. Automatizáláshoz vagy teszteléshez kikapcsolhatod: retryEnabled: false.

SSL

A szerver alapból ellenőrzi a tanúsítványokat, és elutasítja a sima HTTP-t. A skipSslVerify és az allowHttp helyi fejlesztéshez való, önaláírt vagy csak HTTP-s környezethez. A skipSslVerify teljesen kikapcsolja a tanúsítványellenőrzést, az allowHttp pedig titkosítatlanul küldi a hitelesítő adatokat. Csak elszigetelt fejlesztői környezetben használd, éles környezetben vagy nem megbízható hálózaton soha.

Elérhető eszközök korlátozása

Alapból a szerver a teljes eszközkatalógust kínálja. Két beállítás szűkíti:

allowedTools: engedélyezőlista. Az AI számára csak a felsorolt eszközök léteznek.
blockedTools: tiltólista. Minden elérhető a felsorolt eszközök kivételével.

Ha mindkettő be van állítva, előbb az engedélyezőlista érvényesül, majd a tiltólista szűri az eredményt. Az eszköznevek aláhúzást használnak (list_sites_v1, nem list-sites-v1). A szűrés a tiltott eszközt mindenhonnan eltávolítja, ahol látható vagy használható: az eszközlistából, a végrehajtásból, a kiegészítésekből, az eszközönkénti súgóból és a tájékoztató erőforrásokból. Az AI nem hívhatja azt, amit nem lát.

{
  "allowedTools": ["list_sites_v1", "get_site_v1", "list_updates_v1"]
}

MAINWP_ALLOWED_TOOLS="list_sites_v1,get_site_v1,list_updates_v1"

Kész konfigurációk

Csak olvasó megfigyelés (17 eszköz). Irányítópultokhoz, jelentésekhez és minden olyan beállításhoz, ahol az AI csak megfigyelhet, módosíthat nem. Akkor nyúlj ehhez, ha a biztonságos mód nem elég szigorú: az még engedi az aktiválásokat, a 6.3 előtti vezérlőpulton pedig a frissítéseket is.

{
  "allowedTools": [
    "list_sites_v1",
    "get_site_v1",
    "get_site_plugins_v1",
    "get_site_themes_v1",
    "get_site_updates_v1",
    "list_updates_v1",
    "list_ignored_updates_v1",
    "list_clients_v1",
    "get_client_v1",
    "count_clients_v1",
    "count_client_sites_v1",
    "get_client_sites_v1",
    "get_client_costs_v1",
    "list_tags_v1",
    "get_tag_v1",
    "get_tag_sites_v1",
    "get_tag_clients_v1"
  ]
}

Csak frissítések (13 eszköz). Célzott frissítéskezelés karbantartási automatizáláshoz és CI-folyamatokhoz.

{
  "allowedTools": [
    "list_updates_v1",
    "run_updates_v1",
    "update_all_v1",
    "get_site_updates_v1",
    "update_site_core_v1",
    "update_site_plugins_v1",
    "update_site_themes_v1",
    "update_site_translations_v1",
    "list_ignored_updates_v1",
    "set_ignored_updates_v1",
    "ignore_site_core_v1",
    "ignore_site_plugins_v1",
    "ignore_site_themes_v1"
  ]
}

Csak webhelykezelés (30 eszköz). Teljes webhelykezelés ügyfél-, címke- és frissítéskezelés nélkül.

{
  "allowedTools": [
    "list_sites_v1",
    "get_site_v1",
    "count_sites_v1",
    "get_sites_basic_v1",
    "add_site_v1",
    "update_site_v1",
    "delete_site_v1",
    "sync_sites_v1",
    "check_site_v1",
    "check_sites_v1",
    "reconnect_site_v1",
    "reconnect_sites_v1",
    "disconnect_site_v1",
    "disconnect_sites_v1",
    "suspend_site_v1",
    "suspend_sites_v1",
    "unsuspend_site_v1",
    "get_site_plugins_v1",
    "get_site_themes_v1",
    "activate_site_plugins_v1",
    "deactivate_site_plugins_v1",
    "delete_site_plugins_v1",
    "activate_site_theme_v1",
    "delete_site_themes_v1",
    "get_abandoned_plugins_v1",
    "get_abandoned_themes_v1",
    "get_site_security_v1",
    "get_site_client_v1",
    "get_site_costs_v1",
    "get_site_changes_v1"
  ]
}

Romboló eszközök elrejtése. Minden funkció megmarad, de a törlések kikerülnek az AI látóköréből. Óvatos alapbeállítás éles környezethez.

{
  "blockedTools": [
    "delete_site_v1",
    "delete_client_v1",
    "delete_tag_v1",
    "delete_site_plugins_v1",
    "delete_site_themes_v1"
  ]
}

Minimális frissítésautomatizálás (4 eszköz). Éppen elég a frissítések ellenőrzéséhez és végrehajtásához; jól párosítható a tömör sémákkal a lehető legkisebb kontextuslábnyomért.

{
  "schemaVerbosity": "compact",
  "allowedTools": ["list_sites_v1", "get_site_v1", "list_updates_v1", "run_updates_v1"]
}

Más névterek eszközei

Ha más bővítmények képességeit is megjelenítetted, azok eszközei névtér-előtagot kapnak, és a szűrőlistákban az előtagos alakot kell használni:

{
  "allowedTools": ["list_sites_v1", "acme__do_thing_v1"]
}

Megjegyzések

Két beépített erőforrás, a mainwp://categories és a mainwp://status szándékosan szűretlen marad: a vezérlőpult-kapcsolatot írják le, nem az eszközfelületet.
A szűrés az eszközkatalógus tokenköltségét is csökkenti az AI kontextusablakában; a számokat lásd a következő részben.

Tokenhasználat csökkentése

A teljes eszközkatalógus nagyjából 13 000 tokent foglal az AI-kliens kontextusablakából standard módban (egy 62 eszközös katalógussal mérve; a pontos szám a vezérlőpult verziójától függ). Interaktív használatnál ez rendben van, hosszú munkamenetnél vagy célzott automatizálásnál viszont jelentősen csökkentheted.

Tömör sémamód

A compact mód 60 karakterre vágja az eszközleírásokat, és elhagyja a példákat. A katalógus tokenköltségének nagyjából 20%-át spórolja meg cserébe kevesebb beépített leírásért:

{
  "schemaVerbosity": "compact"
}

MAINWP_SCHEMA_VERBOSITY=compact

A tömör mód elhagyja a beépített biztonsági figyelmeztetéseket az eszközleírásokból, és az MCP szemantikai jelöléseire (readOnlyHint, destructiveHint) támaszkodik. Mielőtt olyan beállításban használod, ahol romboló eszközök is elérhetők, ellenőrizd, hogy az AI-kliensed megjeleníti ezeket a jelöléseket. A szerveroldali megerősítési kapu mindkét módban érvényes.

Az eszközlista szűrése

Kevesebb eszköz kevesebb tokent jelent, és ez a nagyobb kar. Az Elérhető eszközök korlátozása kész konfigurációi a katalógus költségét 53% és 94% között csökkentik, attól függően, mennyire szűkíted.

Mindkettő együtt

A tömör sémákat és a négy eszközös engedélyezőlistát kombináló célzott automatizálási beállítás a katalógus tokenhasználatát több mint 90%-kal csökkenti:

{
  "schemaVerbosity": "compact",
  "allowedTools": ["list_sites_v1", "get_site_v1", "list_updates_v1", "run_updates_v1"]
}

Ez olyan folyamatokhoz való, ahol az AI szűk, jól ismert feladatot végez, és a katalógus többi részének dokumentációja nem kell a kontextusába.

Más bővítmények képességeinek használata

Az MCP-szerver nem korlátozódik a MainWP-re. A vezérlőpult webhelyén futó szabványos WordPress Abilities API-val beszél, és bármelyik ott telepített bővítmény regisztrálhat saját képességeket. Alapból a szerver csak a MainWP képességeit mutatja, de más bővítményeket is bevonhatsz.

Mi a névtér?

Minden képességnek kétrészes neve van: mainwp/list-sites-v1, acme/do-thing-v1. A perjel előtti rész a névtér, amely rendszerint a képességet regisztráló bővítményt azonosítja. A szerver névtér szerint dönti el, mit jelenít meg: az alapértelmezett engedélyezőlista ["mainwp"], ezért csak a MainWP képességei jelennek meg.

A kívánt névtér megkeresése

Két mód van:

A bővítmény leírása: az Abilities API-t támogató bővítmény általában megadja a névterét.
Kérdezd meg a vezérlőpultot: bejelentkezve a vezérlőpult webhelyére adminként nyisd meg a https://a-te-vezerlopultod.hu/wp-json/wp-abilities/v1/abilities címet. Ez felsorolja az összes regisztrált képességet. A névtér az egyes name értékek perjel előtti része.

A névtér hozzáadása

Add az engedélyezőlistához, és hagyd benne a mainwp értéket:

{
  "abilityNamespaces": ["mainwp", "acme"]
}

MAINWP_ABILITY_NAMESPACES="mainwp,acme"

Indítsd újra az AI-klienst, és az új eszközök a MainWP-sek mellett megjelennek. A mainwp maradjon a listában: a mainwp://site/{id} erőforrás és a webhelyazonosító-kiegészítések közvetlenül MainWP-képességeket hívnak. Ha kiveszed a mainwp értéket, ezek elromlanak: az erőforrás hibaüzenetet ad, a kiegészítések üresek maradnak, a mainwp://help pedig nem listáz MainWP-eszközt. A névtereket a mainwp mellé add, ne helyette.

Az új eszközök elnevezése

A lista első névtere az elsődleges névtér, annak képességei tiszta, előtag nélküli eszköznevet kapnak. Minden más névtér {névtér}__{eszköz} előtagot kap, így a nevek sosem ütközhetnek:

Képesség neve	MCP-eszköz neve
`mainwp/list-sites-v1`	`list_sites_v1`
`acme/do-thing-v1`	`acme__do_thing_v1`
`acme-corp/do-thing-v1`	`acme_corp__do_thing_v1`

Ha allowedTools vagy blockedTools beállítást használsz, a nem elsődleges eszközöket előtagos alakban sorold fel.

A biztonsági szabályok itt is érvényesek

A biztonsági fejezetek minden szabálya a harmadik féltől származó képességekre is vonatkozik, egy fontos részlettel: az a képesség, amely nem jelzi kifejezetten, hogy nem romboló, rombolónak számít. A hiányos vagy hanyag jelölésű harmadik féltől származó képesség ezért a megerősítési kapuba (vagy a biztonságos módba) ütközik, ahelyett hogy szabadon lefutna. Ez szándékos: a szerver nem feltételezi egy ismeretlen műveletről, hogy ártalmatlan.

Készült: 2026. november 2.