| 1 |
<?php |
| 2 |
/** |
| 3 |
* mcp-core module — the agent-capability registry every MCP surface reads from. |
| 4 |
* |
| 5 |
* This module owns no capabilities and serves no endpoint. It exists so that the |
| 6 |
* things which DO — the capability modules, the WordPress Abilities API bridge, |
| 7 |
* and the native MCP server — can all share one declaration of what exists |
| 8 |
* without depending on each other: |
| 9 |
* |
| 10 |
* mcp-abilities ─┐ |
| 11 |
* mcp-fsi ───────┼──register_classes()──► mcp-core (ToolRegistry) |
| 12 |
* │ │ |
| 13 |
* │ ├──► wp-abilities-api (iff Abilities API / mcp-adapter) |
| 14 |
* │ └──► mcp-server (always) |
| 15 |
* |
| 16 |
* Splitting this out is what keeps that graph acyclic. Before the split the |
| 17 |
* registry lived beside the abilities, so the native server had to depend on the |
| 18 |
* ability module and the ability module had to depend on the server's |
| 19 |
* `ToolDescriptor` for its access levels — a cycle the module-dependency gate |
| 20 |
* (spec 004 US6) cannot express and boot ordering cannot satisfy. |
| 21 |
* |
| 22 |
* Nothing is registered here at boot. `ToolRegistry` is a lazy singleton and |
| 23 |
* resolves its descriptors on first use (see ToolRegistry::$pending_classes for |
| 24 |
* why resolution must not happen during `plugins_loaded`), so a module that |
| 25 |
* boots later can still contribute capabilities. |
| 26 |
* |
| 27 |
* @package Templately |
| 28 |
*/ |
| 29 |
|
| 30 |
namespace Templately\Modules\McpCore; |
| 31 |
|
| 32 |
use Templately\Core\Module_Base; |
| 33 |
|
| 34 |
class Module extends Module_Base { |
| 35 |
|
| 36 |
public function get_name(): string { |
| 37 |
return 'mcp-core'; |
| 38 |
} |
| 39 |
|
| 40 |
/** |
| 41 |
* Intentionally empty. Consumers reach the registry through |
| 42 |
* `Registry\ToolRegistry::get_instance()`; there is no hook to install and |
| 43 |
* nothing to eagerly construct. |
| 44 |
*/ |
| 45 |
protected function init_hooks(): void {} |
| 46 |
} |
| 47 |
|
