feat(mcp): bind the resource registry under mcp's provider key - #22
Conversation
wip commit before merging main
dappcore/mcp's McpApiController resolves its plans:// and sessions:// content from whatever is bound under Core\Mcp\Resources\Contracts\AgentResourceProvider. Nothing was, so those two endpoint families answered not-found — which I described as an interim waiting on this package to depend on mcp. It never would: this package keeps its own copy of Core\Mcp by design, so the interim was permanent and therefore a decision nobody had made. The registry is aliased under that name. A string, not ::class, because the interface cannot be named here — writing Core\Mcp\Resources\Contracts\ AgentResourceProvider::class would resolve against this repo's own Core\Mcp tree, where it does not exist. mcp accepts a provider structurally for exactly this reason, and the registry already satisfies its one method, read(). An alias rather than a second binding, so both names resolve to the same instance and cannot drift. Harmless when mcp is absent: nothing looks the key up, and binding it costs nothing. Four tests: the key is bound and resolves to the registry, it is the same instance as the registry itself, it answers read() with real plan content, and it reports null for a URI it does not serve. Suite 131 failed / 1194 passed, from 131 / 1190 — the four new tests, no change to the existing failures. Co-Authored-By: Virgil <virgil@lethean.io>
|
Warning Review limit reached
Next review available in: 6 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Warning Billing warning: we have not been able to collect payment for this subscription for more than 72 hours. Please update the payment method or pay any pending invoices in Billing to avoid service interruption. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
1 participant
Pairs with dAppCore/mcp#21 (duck-typed provider resolution). Together they turn mcp's
plans://andsessions://HTTP endpoints back on.Why this is a decision, not an interim
mcp's
McpApiControllerresolves its plan and session content from whatever is bound underCore\Mcp\Resources\Contracts\AgentResourceProvider. Nothing was, so those endpoints answered not-found. I described that as an interim waiting on this package to depend ondappcore/mcp.It never would. This package keeps its own copy of
Core\Mcpby design, so the interim was permanent — and a permanent interim is a decision nobody made.The binding
The registry is aliased under that name. A string, not
::class— the interface cannot be named here, because writingCore\Mcp\Resources\Contracts\AgentResourceProvider::classwould resolve against this repo'sCore\Mcptree, where it doesn't exist. mcp accepts a provider structurally for exactly this reason, and the registry already satisfies its one method,read().An alias, not a second binding, so both names resolve to the same instance and cannot drift. Harmless when mcp is absent: nothing looks the key up, and binding a container key costs nothing.
Verification
read()returns real plan content, null for an unserved URIExisting failures unchanged; the delta is exactly these four tests. Merged
mainin (bringing #21) and re-baselined rather than comparing against a stale number.🤖 Generated with Claude Code
Co-Authored-By: Virgil virgil@lethean.io