Add MCP integration and Developer Environments skill (v1.2.0)

[scottisloud]

Summary

• Unify hooks and MCP in the existing 1password Cursor plugin at v1.2.0
• Add mcp.json pointing at the local 1password-mcp binary
• Add skills/1password-environments/SKILL.md for agent MCP workflows
• Update README for combined hooks + MCP setup; add assets and .gitignore

Test plan

• Install plugin via /add-plugin 1password or local copy
• Confirm beforeShellExecution hook appears in Settings → Hooks
• Run agent shell command (echo hello); verify allow/deny in Execution Log
• Enable 1Password Labs MCP Server; confirm MCP connects in Cursor
• List environments and variables via MCP tools

[scottisloud]

Adjusted scope slightly for expected agent behaviours to account for differences in how Cursor Agents work compared to some other agent clients.

Ready for review. Testing is a bit fiddly...

[JillRegan]

Tested and works as expected! Left some comments.

Another thing I want to mention is the .cmd wrapper on Windows (you'll notice we have this for validate-mounted-env-files which was implemented here). Essentially cursor tries to run the bash hook commands, and without .cmd file it can attempt the bash script and fail badly which opens the file in the editor. The .cmd stub just returns allow since mounts aren’t supported on Windows anyway.

So if on Windows and the plugin is installed and these new hooks execute it will be an unpleasant user experience because the bash scripts will fail and open in the editor. While I don't think we should address in this PR I do think we should work on a quick follow up. But we may need more discussion with the Cursor team to see how other folks are handling this, as a .cmd file for every hook is not ideal.

[scottisloud]

Confirmed, Cursor seems to not have recognized it was failing to correctly load the plugin while I was developing it. As as a result, it implemented a TON of additional scaffolding that isn't required.

I'll make local changes to the marketplace-installed version of the plugin (which Cursor abides by) so I can accurately assess what's required for the desired behaviour, pull out what isn't, and port that over here.

[JillRegan]

This looks cleaner without the added extra hooks! I do have a question though about design - I might not have all the context. With this change we don't enforce that the agent read the skill here, but I did test all plugin still works as expected.

Is there major risk if the agent does not read the skill pre mcp execution? I guess the risk here would just be a broken flow, correct?

[scottisloud]

Looks like there were a couple issues that cropped up mostly from the repo-hopping. I'll tidy those things up "upstream" and bring them into this PR, along with the other tweaks called out.

[scottisloud]

This looks cleaner without the added extra hooks! I do have a question though about design - I might not have all the context. With this change we don't enforce that the agent read the skill here, but I did test all plugin still works as expected.

Is there major risk if the agent does not read the skill pre mcp execution? I guess the risk here would just be a broken flow, correct?

Initially I had introduced rather aggressive hooks to force an agent to read, which no other of our IDE integrations required, largely to combat misbehaviours induced by a policy in our own cursor account.

After testing in a way that wasn't blocked by the policy, the agent seemed to perform as reliably as in any other IDE we've worked with, so at this time, was satisfied not shipping a hook.

As for the risk, that also factored into the decision to not include a hook to read the skill. In my initial testing, Cursor was failing to read the skill files (per the policy blocking that). The consequence was minor, mostly in the form of agents just taking ages to figure out what to do, or leaning heavily on the rather sparse documentation the MCP server itself provides the agent.

I didn't observe any behaviours that could have any security consequences, which is largely a result of protections baked into the MCP server itself.

Long story short, in the event the agent fails to read the accompanying skill for some reason, the most likely outcome is just an agent bumbling around, and which will do as it's asked, but maybe slower.

[scottisloud]

Ready for re-review. This is functionally identical to the version in the internal test marketplace.

[scottisloud]

@rishiy15 if I am reading OS-267 correctly, we actually need to omit this, right?

[rishiy15]

I think this only matters if we named the skills directory something else. The docs state:

If a manifest field is specified (e.g., "skills": "./my-skills/"), it replaces folder discovery for that component. The default folder is not also scanned.

So as of now, it is a no-op since the folder name specified is the default name. I do not have a strong preference for either keeping or removing it.

[rishiy15]

LGTM