mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-18 21:16:47 +00:00
Renzo Beux
29de8dd9c1
Tools are declared in the signed manifest, not only reported at load. plugin-host-entry composes its loaded payload AFTER onLoad runs, so a signed, sha256-pinned artifact could otherwise emit different tool text on every restart with no version bump and no re-consent. The host will advertise the intersection of the two. It also gives the admin something to read. What mcp:tools will put in front of every user is a manifest field now, so it can be shown on the consent screen before the grant is given. Rejects rather than drops, unlike most capability parsing: a malformed tool should fail the install visibly, not become a tool that silently never appears once the plugin is running. Caps and sanitising come from mcp-tool-schema.ts, so the install path and the advertise path cannot disagree about them. Declaring tools without mcp:tools is an error on both sides. Otherwise the consent screen lists tools that can never run. No migration: install/discovery.ts already persists capabilities as JSON. The SDK validator mirrors the checks it can make without the server's normaliser, so `trek-plugin validate` catches a bad declaration before publish rather than at install.