Npcink Abilities Toolkit vs SlyTranslate – AI Translation Abilities

Npcink Abilities Toolkit helps a WordPress site expose, review, and safely inspect Abilities API capabilities for AI hosts and clients. The admin page is built for site operators first. It shows whether the site’s ability package is working, which abilities are available, which abilities are read-only, and which write-like abilities require host approval. For developers and host runtimes, the plugin also provides ability registration helpers, category helpers, schema normalization, annotation normalization, REST discovery values, and optional canonical projection for Npcink AI when Npcink AI is installed. It can be used by any WordPress plugin or client that consumes the WordPress Abilities API. Npcink AI is one optional consumer, not the owner of this plugin. It does not run AI models, execute workflows, route prompts, contact model providers, manage billing or quotas, own MCP governance, or approve final WordPress writes. Read-only host composition recipe metadata may document how hosts can compose abilities, but those records do not run queues, schedule jobs, execute workflows, or create a second registry. Host composition recipe metadata is available through read-only helpers and Abilities API discovery abilities for hosts that need catalog discovery without execution ownership. External Services and Remote Requests This plugin does not automatically contact Npcink AI, model providers, analytics services, tracking services, or cloud services. Some abilities can prepare request payloads for a separate host or cloud add-on, but this plugin does not send those payloads to an external service by itself. The npcink-abilities-toolkit/upload-media-from-url ability can download a media file from a URL provided by an authenticated caller when an approved host runtime commits that ability. In that case WordPress sends an HTTP request to the caller-provided URL in order to fetch the media file for the local media library. The remote endpoint is chosen by the caller, not by this plugin. Requirements WordPress 7.0 or later. This release intentionally targets the WordPress Abilities API baseline available in WordPress 7.0+. PHP 8.0 or later. The WordPress Abilities API REST routes must be available before third-party provider plugins or external clients can discover and run abilities. Public API npcink_abilities_toolkit_register_category( $category_id, $args ) npcink_abilities_toolkit_register_readonly( $ability_id, $definition ) npcink_abilities_toolkit_register_write_proposal( $ability_id, $definition ) npcink_abilities_toolkit_normalize_schema( $schema, $default_type ) npcink_abilities_toolkit_normalize_annotations( $annotations, $risk_level ) npcink_abilities_toolkit_get_registered() npcink_abilities_toolkit_get_workflow_definitions() npcink_abilities_toolkit_get_workflow_definition( $recipe_id ) Third-Party Integration Quickstart Provider plugins should wait until plugins_loaded, check that the public helper exists, and then register their abilities through the helper functions: if ( function_exists( 'npcink_abilities_toolkit_register_readonly' ) ) { npcink_abilities_toolkit_register_readonly( 'acme/site-summary', $definition ); } Do not include files from this plugin’s includes/ directory or instantiate classes in the Npcink_Abilities_Toolkit namespace. Those are implementation details. Use npcink_abilities_toolkit_register_readonly() for read-only context and diagnostic abilities. Use npcink_abilities_toolkit_register_write_proposal() only when the callback returns a proposal, preview, diff, or handoff payload. Third-party provider callbacks should not perform final host-governed commits. Approval, audit, quota, and final write authorization belong to the consuming host runtime. REST clients should first discover the catalog through: /wp-json/wp-abilities/v1/categories /wp-json/wp-abilities/v1/abilities /wp-json/wp-abilities/v1/abilities/{namespace}/{name}/run /wp-json/npcink-abilities-toolkit/v1/contract The contract endpoint is a compatibility and boundary discovery endpoint for authenticated host runtimes. It does not replace the WordPress Abilities API catalog and does not run abilities. Full provider examples and REST client notes are maintained in the public repository: https://github.com/muze-page/npcink-abilities-toolkit If the wp-abilities/v1 REST routes are missing, enable the WordPress Abilities API baseline or compatibility plugin before connecting third-party providers or clients. Admin Page After activation with a Npcink AI host plugin, open Npcink AI -> AI Abilities in wp-admin. When this standalone package is installed without a Npcink AI host menu, open Tools -> Site AI Abilities instead. The page is designed for site operators first: it shows site ability status, groups available abilities with plain labels and risk posture, and can run two official read-only checks: site info and bounded redacted diagnostics summary. The Checks tab explains what each check proves and what it does not prove before it runs. Check results are shown as a plain summary table, with raw JSON kept behind a support disclosure. Developer Access keeps copyable REST endpoint values, raw discovery fetches, and ability ID export available for host/client setup. It does not run showcase workflows, model calls, write abilities, approval flows, or demo abilities. Built-In Abilities The plugin includes migrated low-risk WordPress read abilities, deterministic comment helpers, and host-governed WordPress write/destructive abilities using canonical npcink-abilities-toolkit/* ids. It also includes npcink-abilities-toolkit/wp-diagnostics-summary, a redacted WordPress-only diagnostics summary for Abilities API clients. This summary intentionally omits Npcink AI settings, MCP settings, API keys, database names, table prefixes, filesystem paths, error logs, and external HTTP probes. It also includes npcink-abilities-toolkit/search-posts and npcink-abilities-toolkit/search-post-meta, bounded local WordPress search helpers for keyword and explicit post-meta discovery. These are read-only helpers and do not call external search indexes or mutate content. It also includes npcink-abilities-toolkit/list-workflow-recipes and npcink-abilities-toolkit/get-workflow-recipe, read-only host composition recipe metadata discovery abilities. These expose metadata only and do not execute workflow runtime behavior. Core governance handoff docs include a catalog snapshot, permission matrix, and schema boundary audit for hosts that consume this plugin through npcink-ai-core. Developer Verification For the default local source gate, run: composer test:all When the plugin is installed in a local WordPress site, run: WP_PATH=/path/to/wordpress composer smoke:wp For isolated bounded-chain performance validation, run: composer perf:smoke

SlyTranslate wires AI translation into WordPress at three different levels: the admin UI, the Gutenberg editor, and from external LLM tools via MCP. Whichever level you work at, the same language plugin integrations and translation quality controls apply. It works with any LLM available through a WordPress AI connector and natively supports Polylang, WP Multilang, WPGlobus, and TranslatePress Multilingual. What it does Translates posts, pages, and custom post types into any language managed by your active language plugin Translates selected text or entire Gutenberg blocks inline, without leaving the editor Exposes the same functionality as MCP abilities, so external LLM tools (Claude Code, Codex, and others) can drive translations programmatically Carries SEO metadata (title, description) through the same translation workflow as the post content Handles long and structured content with chunking and output validation Supports model-specific profiles that tune prompt style and retry behavior for known model families Workflow 1 — Admin UI translation (posts & pages overview, side panel) Translate full posts or pages directly inside WordPress admin — either one at a time from the editor side panel or in bulk from the list view. Requirements: language plugin + configured AI Connector From the post/page list, select one or more items and choose a translation action from the bulk-actions menu. A dialog lets you pick target language, model, and whether to overwrite existing translations. Progress updates live while the translation runs, and you can cancel at any time. From the editor side panel, the same controls appear alongside the post you are currently editing. TranslatePress users get an equivalent panel inside the TranslatePress visual editor on ?trp-edit-translation pages. The language plugin (Polylang, WP Multilang, WPGlobus, or TranslatePress) handles the translated post as it normally would — SlyTranslate creates or updates the translated entry and lets the language plugin own the relationship. Workflow 2 — Inline Gutenberg translation (block or selected text) Translate content while writing, without touching a language plugin or a full-post workflow. Requirements: configured AI Connector Select any text in a Gutenberg block and the block toolbar gains a Translate button. The selected text is replaced with the translation in place. When no text is selected, the button translates the entire block. This workflow is self-contained: it does not require a language plugin and does not create or modify translated post entries. It is useful for one-off corrections, translating imported content on the fly, or working in a single-language site where you just need AI rewriting in another language. Workflow 3 — LLM wrapper via MCP (Claude Code, Codex, and others) Drive WordPress translations from inside your LLM tool of choice. Requirements: language plugin + WordPress application password (token) + WordPress MCP Adapter plugin When a WordPress MCP Adapter is active, SlyTranslate registers its abilities over MCP. Any MCP-capable LLM client — Claude Code, Codex, custom agents — can then discover and call them. In this workflow the LLM wrapper provides the translation itself. SlyTranslate’s MCP abilities handle the WordPress side: reading content structure, checking translation status, writing translated entries, and coordinating with the language plugin. No WordPress AI Connector is needed because translation is performed by the external model, not by WordPress. A typical agent session: Call ai-translate/get-languages to find valid target language codes. Call ai-translate/get-translation-status on the source post to read source_language and single_entry_mode. Translate the content using the agent’s own LLM. Call ai-translate/translate-content to write the translated entry. This is the right workflow for automating bulk site migrations, integrating translation into a CI/CD pipeline, or building a custom translation agent that uses a model not available as a WordPress AI connector. Internal flow ┌──────────────────┐ ┌───────────────────┐ ┌────────────────────────┐ │ Admin UI │ │ Gutenberg │ │ LLM Wrapper │ │ (panel / list) │ │ (block / toolbar) │ │ (Claude Code, Codex…) │ └────────┬─────────┘ └────────┬──────────┘ └──────────┬─────────────┘ │ REST │ REST │ MCP └──────────────────────┴──────────────────────────┘ │ ┌──────────▼──────────────┐ │ SlyTranslate Ability │ │ (REST / MCP endpoint) │ └──────────┬──────────────┘ │ ┌───────────▼───────────┐ │ AI Connector │ ← UI/block workflows │ (wp_ai_client_prompt)│ only └───────────┬───────────┘ │ ┌───────────▼───────────┐ │ LLM (any provider) │ └───────────┬───────────┘ │ ┌───────────▼───────────┐ │ Chunk + Validate │ └───────────┬───────────┘ │ ┌───────────▼───────────┐ │ Language Plugin │ │ Polylang / TP / … │ └───────────┬───────────┘ │ ┌───────────▼───────────┐ │ WordPress Post │ └───────────────────────┘ In the MCP workflow the LLM Wrapper acts as the translation engine — the AI Connector and LLM steps inside WordPress are bypassed. Abilities reference ai-translate/get-languages — List languages exposed by the active language plugin ai-translate/get-translation-status — Show translation status for a content item, including `source_language` and `single_entry_mode` ai-translate/set-post-language — Change the language assignment of an existing content item (Polylang only) ai-translate/get-untranslated — Find content still missing a target translation ai-translate/translate-text — Translate arbitrary text ai-translate/translate-blocks — Translate serialized Gutenberg blocks ai-translate/translate-content — Create or update one translated post/page/CPT entry ai-translate/translate-content-bulk — Bulk-translate multiple entries ai-translate/get-progress — Return live progress for a running translation ai-translate/cancel-translation — Cancel a running translation ai-translate/get-available-models — List models from configured connectors ai-translate/save-additional-prompt — Save per-user additional instructions ai-translate/configure — Read or update persistent plugin settings MCP call sequence For reliable results in agent workflows: Call get-languages first when the correct target language code is unknown. Call get-translation-status before translate-content to read source_language, single_entry_mode, and whether a translation already exists. Omit source_language unless you intentionally pin a source variant. Set overwrite=true only when status or prior context confirms a target-language entry already exists. translated_post_id equals source_post_id in single-entry adapters (WP Multilang, WPGlobus, TranslatePress). In multi-post adapters (Polylang) the translated item has a sibling post ID. Supported plugins Language plugins Polylang WP Multilang WPGlobus TranslatePress Multilingual SEO plugins (metadata translated alongside content) Genesis SEO Yoast SEO Rank Math All in One SEO The SEO Framework SEOpress Slim SEO Supported model profiles Any LLM available through a WordPress AI connector works without configuration. The following model families have dedicated built-in profiles that tune prompt style, chunking, and retry behavior: TranslateGemma — dedicated runtime with chat_template_kwargs support via direct_api_url TowerInstruct / Salamandra — bilingual framing, conservative chunking, stricter retries Nvidia Nemotron — system-prompt-aware, reasoning-disable, provider-parameter forwarding Qwen 3.x / GLM-4.6v / Gemma 4 / Phi-4 — thinking-aware profiles EuroLLM / Llama 3.1-8B / SauerkrautLM — conservative chunking tuned for European languages Ministral-3 / Ministral-8B — optimized for the Ministral model family Additional profiles can be registered via the slytranslate_model_profiles filter.