Gravity Forms MCP tools pass through a site-wide allowlist and the connecting WordPress user's capabilities. A configuration can drift when an administrator enables a tool globally, changes a role, installs an add-on, or reconnects a client under a broader account. The client-visible inventory is the outcome that matters, not either settings screen alone.
Use this for reporting agents, support assistants, form builders, data managers, multisite installations, role-editor plugins, staging clones, and MCP client upgrades.
Quick answer
Define an approved tool manifest per client. For a reporting agent, list the exact read tools, required capabilities, forms or entry scope, data classes, and denied write actions. Export the site-wide MCP allowlist and the dedicated user's capabilities, then ask the named client to list its visible tools. Run one harmless success fixture and one denied fixture for each capability boundary. Diff the observed inventory against the approved manifest after every Gravity Forms, WordPress, role, add-on, or client change. Alert on any newly visible write or delete tool, not only on successful calls.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Reporting agent | Count Entries | Visible and succeeds |
| Reporting agent | Update Entry | Hidden or denied |
| Form builder | List Forms | Expected broader capability |
| Drift | Delete tool appears | Block and investigate |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Define a per-client manifest | Record Gravity Forms and WordPress versions, endpoint mode, site-wide allowlist, dedicated user, role, primitive capabilities, multisite subsite, client version, and approved tool manifest. | The client sees only approved tools for its role. |
| Export both permission gates | Classify every tool as read, write, destructive, notification, form design, feed, entry, note, settings, or add-on related, including hidden capability dependencies. | Allowed read fixtures succeed with redacted evidence. |
| Observe client-visible tools | Collect the client-visible tool list and compare it with the settings allowlist and user capability map instead of assuming the intersection is correct. | Write and delete fixtures remain unavailable or denied. |
| Test allowed and denied fixtures | Run allowed read fixtures against synthetic forms and entries, then attempt pre-approved denied fixtures that must return permission errors without changing data. | Version, role, add-on, and allowlist changes trigger a fresh diff. |
What to check first
- Record Gravity Forms and WordPress versions, endpoint mode, site-wide allowlist, dedicated user, role, primitive capabilities, multisite subsite, client version, and approved tool manifest.
- Classify every tool as read, write, destructive, notification, form design, feed, entry, note, settings, or add-on related, including hidden capability dependencies.
- Collect the client-visible tool list and compare it with the settings allowlist and user capability map instead of assuming the intersection is correct.
- Run allowed read fixtures against synthetic forms and entries, then attempt pre-approved denied fixtures that must return permission errors without changing data.
- Store a sorted manifest hash, review it after upgrades and role changes, and alert when a write or delete capability appears unexpectedly.
Field notes
- Write the expected result before changing anything and keep one repeatable synthetic fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public path and the stored server-side result, not only an admin preview, isolated command, or API response.
- Review the result again after the relevant cache, queue, cron, webhook, and observation window has completed.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
approved_tools.txt
count_entries
get_entry
get_gravity_forms_info
search_entries
# Sort the client-visible inventory and compare hashes after each change.
Why this usually happens
- The site-wide allowlist is expanded for one agent but applies to every connecting user.
- A role editor grants a Gravity Forms capability through inheritance.
- A client reconnects with an administrator account during troubleshooting.
- An add-on introduces feed tools whose second capability gate was not reviewed.
Decision rule
A read-only agent is approved only when its observed tool inventory matches the manifest, expected reads pass, writes and deletes are hidden or denied, and drift produces an alert.
Production verification checklist
- The client sees only approved tools for its role.
- Allowed read fixtures succeed with redacted evidence.
- Write and delete fixtures remain unavailable or denied.
- Version, role, add-on, and allowlist changes trigger a fresh diff.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Define a per-client manifest
- Export both permission gates
- Observe client-visible tools
- Test allowed and denied fixtures
- Hash and monitor inventory drift
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, a stable fixture, the expected result, and a tested rollback point.
- Treating one successful screen as proof while logs, stored records, background jobs, caches, emails, APIs, and downstream systems remain unchecked.
- Testing only as an administrator instead of using the role, device, locale, cache state, request path, and failure branch that users actually reach.
- Leaving debug output, temporary exclusions, helper accounts, duplicate hooks, broad permissions, or relaxed firewall rules active after verification.
Questions teams ask during testing
Can I test this directly in production?
Start with read-only evidence. Use staging for package, code, checkout, form, permission, or cache changes. If a production canary is necessary, make it identifiable, reversible, monitored, and unable to expose personal data or charge a customer.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare the browser result, stored result, and logs instead of relying on one successful screen.
What evidence should I retain?
Keep UTC time, exact versions, request or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials, tokens, and personal data.
When is the work complete?
Close it when the primary path passes, failure branches are understood, stored and downstream records reconcile, temporary changes are removed, monitoring is active, and the owner has the evidence packet.
What to tell the client or owner
Give the owner a concise packet with the affected workflow, exact versions, UTC test time, synthetic fixture ID, expected result, actual result, key logs, change made, rollback point, final result, unresolved risks, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP review Gravity Forms MCP permissions.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references