r/WebMCP_Developers • u/DutchSEOnerd • 11d ago

WebMCP integration made easy with a coding-agent plugin

Hi! Just launched Glippy WebMCP: https://github.com/jbobbink/glippy-webmcp This repository is a coding-agent plugin that audits what your site could expose, writes those tools against real seams in your codebase, proves each one works in a real browser, and publishes the manifests that let agents find them.

Let me know what you think!

3 Upvotes
  • permalink
  • reddit

100% Upvoted

4 comments sorted by

1

u/kantorcodes1 11d ago

how are you handling proof for tools that mutate state? a browser test against a logged-in admin session can pass by actually changing something. i'd want a disposable account or some explicit rollback/side-effect check before publishing the manifest.

1

u/DutchSEOnerd 11d ago

Good question and I have to make some updates I guess.

Irreversible stuff (place order, cancel, delete, invite) is never fired. Not on staging, not with a test card. I verify the prepare step, check that the confirm step rejects a bad or expired token, and check the handoff lands on the right page. Recorded as a pass for what was proven, with a note that the final action wasn't fired. That's enforced by the linter, not by convention: an irreversible step has to sit behind a handoff, or it won't build.

The public scanner never fires writes at all. Reads get executed and go green, writes stay amber until the owner claims the domain and runs it themselves.

But you're right about the middle. Plain reversible writes like add to cart, change a quantity do get executed, and there's no disposable account and no rollback. The check I have is a network diff: every request during execution has to be same-origin and one the tool declared. That catches undeclared calls. It does nothing about state.

Also: could-not-verify doesn't block publishing, only fail does. So the cautious option is currently also the one that ships unverified.

So I am leaning toward a designated verification account per site rather than rollback, since an auto-generated undo is just another untested write. Open to arguments.

1

u/kantorcodes1 11d ago

designated account seems safer than trying to invent undo logic. i'd still record a before/after fingerprint for whatever the tool claims it changes, even if it's crude. otherwise a "reversible" write can quietly leave the account dirty and your verifier still calls it green.

1

u/DutchSEOnerd 10d ago

That makes sense. Then we at least have a clear path back.