WIP MCP tool bridge that derives AI tools from the enabled REST API classes.
Proof of concept for the direction discussed in issue #38356 ("reuse the existing
API with a dynamic scan to detect which api is enabled so which tool must be
enabled"). Instead of hand-writing one tool definition per object, this bridge:
- detects which REST API endpoint classes are available AND whose module is enabled (isModEnabled), and
- converts their read methods into MCP tool definitions (JSON Schema built from reflection + docblock parsing), and
- executes calls IN-PROCESS on the API class (no HTTP self-call), behind a central authentication bridge (DolibarrApiAccess\$user = service user), catching RestException.
Exposure model (per review feedback on the PR):
- Explicit whitelist: a method is exposed ONLY if it is listed under the 'methods' key of its endpoint entry below — nothing is exposed just because reflection finds it. The current whitelist is read-only (index/get + a few product read helpers); any write method will have to be consciously whitelisted later, behind a confirmation gate + body schemas harvested from each object's ->fields.
- Enrichment: reflection + docblock parsing give the skeleton (route, main params); each whitelisted method can carry a hand-written complement ('description' appended to the tool description, 'params' overriding per-parameter docs) merged over the derived schema, in the spirit of the hand-written getDefinitions() of the legacy ai/tools/*.class.php — but only as a complement, never a full rewrite.
Remaining WIP limitations (POC scope):
- Endpoint map is a small explicit list; TODO generalize with the same dolGetModulesDirs()/getModuleDirForApiClass() scan used by api/index.php.
- Schemas come from a light docblock parser; TODO reuse Restler's CommentParser/Routes metadata (what generates swagger.json) + cache them.
Disabled unless the constant AI_MCP_API_BRIDGE is set to 1.
Definition in file api_bridge.class.php.