Skills, plugins, and MCP

Add components without unnecessary complexity.

Result

Every added component closes a demonstrated gap in the accepted scenario. Its source, version, permissions, data exposure, test, owner, and removal procedure are recorded before real material depends on it.

Component	Use it for	Do not use it as
Skill	A repeatable method, sequence, or quality protocol	Access to an external account
MCP server or connector	Controlled access to an external service or dataset	Proof that returned content is correct
Plugin	A distributable bundle of skills, tools, or app connections	Automatic permission to enable every bundled capability

Actions

Name the blocked workflow step and the capability it requires before searching for a component.
Prefer an existing approved skill for a repeatable method and an approved connector for service access.
Inspect the publisher, source, version, requested permissions, network destinations, stored data, and update path.
Install or enable one component at a time in the narrowest useful project or user scope.
Test discovery, one expected success, one safe failure, and removal with de-identified material.
Record the component, owner, reason, version, permissions, test evidence, update rule, and rollback procedure.
Re-run the original scenario criterion; component health alone does not prove that the research workflow works.

Check

For every component, the project record answers: why it exists; where it came from; what data it can receive; what it can read or change; which account owns it; what version was tested; how success and failure were tested; and how to disable or remove it. The original scenario passes after installation.

If it fails

Disable the last component and repeat the last known working scenario. Separate installation, authentication, authorisation, discovery, execution, and output-quality failures. Restore the accepted version or remove the component; do not broaden permissions without a demonstrated need.

Next: Publication monitoring.