You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Inspecting WordPress data currently means either invoking wp db query through wp_cli (returns stdout, must be parsed) or opening Adminer in a browser. A typed read-only query tool gives agents a structured way to inspect data without leaving the agent loop.
Proposal
query_database(siteId?, sql) → restricted to SELECT / SHOW / DESCRIBE / EXPLAIN; returns structured rows; rejects DML/DDL with a clear error
Write queries stay manual or behind explicit confirmation in a separate tool (out of scope for this issue).
Scope rationale
This overlaps with wp_cli (wp db query), but:
Server-side enforcement of read-only is safer than relying on the agent to remember
Structured row returns vs. stdout parsing is a real ergonomics win
Problem
Inspecting WordPress data currently means either invoking
wp db querythroughwp_cli(returns stdout, must be parsed) or opening Adminer in a browser. A typed read-only query tool gives agents a structured way to inspect data without leaving the agent loop.Proposal
query_database(siteId?, sql)→ restricted toSELECT/SHOW/DESCRIBE/EXPLAIN; returns structured rows; rejects DML/DDL with a clear errorWrite queries stay manual or behind explicit confirmation in a separate tool (out of scope for this issue).
Scope rationale
This overlaps with
wp_cli(wp db query), but:LocalApi additions
None strictly required — can run via the existing MySQL connection used by
wp_cli, with a SQL parser to enforce read-only.Acceptance criteria