When you pull an existing MCP server or an OpenAI/Claude-style skill into a local agent package model, the hard part is not the install. It is turning foreign tool metadata into something reviewable: provenance and version kept intact, network/filesystem/secret needs mapped to explicit permissions, and hooks left off until someone approves them.
A credible baseline is still manual. Read the server or skill manifest, list every tool action, note undeclared filesystem or network reach, and reject or mark unsupported anything you cannot map. Auto-enable is how permanent owner-memory write and silent background behavior sneak in.
Running imports through the same validator and permission model as native packages only helps if unmappable authority fails closed and compatibility status stays visible (native, wrapped, partial, rejected).
How do you currently record provenance and permission gaps when wrapping a third-party MCP server so a later review can tell those four outcomes apart?
Top comments (1)
@infracore, the native/wrapped/partial/rejected compatibility states are a useful guard against imports silently gaining authority. I’d also persist the original manifest digest alongside the normalized permissions so a later update cannot inherit approval just because the package name stayed the same. Would you invalidate approval whenever either declared capabilities or previously undeclared network or filesystem behavior changes?