Strip unnecessary fields in wpcom_request response by epeicher · Pull Request #3005 · Automattic/studio

epeicher · 2026-04-08T07:47:33Z

Related issues

Fixes STU-1524

How AI was used in this PR

AI assisted with debugging the root cause (identifying that plan.features was 63K+ chars) and writing the compact extraction logic.

Proposed Changes

System prompt guidance: Add a hint instructing the agent to use _fields on wp/v2 listing endpoints (templates, posts, pages, etc.) to request only lightweight fields and exclude heavy ones like content. This is the generic solution for large responses.
Special case for plan.features: Add a compactResponse() function that strips plan.features (60K+ chars) from /sites/{id} responses, keeping only product_id, product_slug, product_name_short, expired, and is_free. This can't be solved via query params because the v1.1 API doesn't support sub-field filtering (e.g. fields=plan.product_slug). The function includes a clear comment explaining this is a special case, not a pattern to follow.

Testing Instructions

Apply these changes and run npm run cli:build. Then start studio ai by running node apps/cli/dist/cli/main.mjs ai
Connect to a remote WordPress.com site by pressing down arrow and then right arrow
Ask the agent a question that triggers wpcom_request (e.g., "What's the current name, tagline, and active theme of this site?")
Verify the response succeeds without exceeding the MCP output limit, i.e. you don't see the error: Error: result (96,907 characters) exceeds maximum allowed tokens. Output has been saved to…
Ask the agent to modify a block theme template on a remote site → verify it uses wp/v2 endpoints
Ask the agent for design changes on a free WP.com site → verify it explains the paid plan limitation

Before	After

Pre-merge Checklist

Have you checked for TypeScript, React or other console errors?

The WP.com /sites/{id} endpoint returns a plan object whose features sub-field alone is 60K+ characters, pushing the total response past Claude Code's ~100K character MCP tool result limit. The agent only needs product_slug, is_free, and expired to gate features, since the system prompt hardcodes what each plan tier can and can't do. Strip plan.features and keep only essential plan properties.

wpmobilebot · 2026-04-08T11:28:21Z

📊 Performance Test Results

Comparing b7eca66 vs trunk

app-size

Metric	trunk	`b7eca66`	Diff	Change
App Size (Mac)	1261.52 MB	1261.53 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	`b7eca66`	Diff	Change
load	1908 ms	1927 ms	+19 ms	⚪ 0.0%

site-startup

Metric	trunk	`b7eca66`	Diff	Change
siteCreation	9110 ms	9132 ms	+22 ms	⚪ 0.0%
siteStartup	4297 ms	4941 ms	+644 ms	🔴 15.0%

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

List endpoints like GET /templates can return 80K+ chars of block markup. Strip content and _links from array items when the response exceeds 80K chars — the agent can still identify items by slug/title and fetch individual ones for full content.

youknowriad · 2026-04-08T12:36:24Z

apps/cli/ai/wpcom-tools.ts

+	}
+
+	// Case 1: plan.features can be 60K+ chars — keep only essential plan properties
+	if ( ! Array.isArray( result ) && result.plan?.features ) {


For me this seems too specific to a given endpoint, Is there a way to apply a generic fix instead (like overriding the token limit or telling the agent to use the minim required properties...). I don't believe we should have specifics like that because it will be hard to scale and adapt as the endpoints evolve...

Good point about scalability. I looked into a few alternatives:

Prompt-based: Tell the agent to always use _fields (wp/v2) or fields (v1.1) to request only what it needs. Works for most endpoints but doesn't fix the plan case. Even with fields=ID,name,description,URL,plan, the plan field alone is 63K+ because features is deeply nested and the API doesn't support sub-field filtering like fields=plan.product_slug. Plus the agent might not always follow the instruction.

Increasing the token limit: Would work but the LLM ends up processing 60K+ chars of plan.features that it never reads. The system prompt already hardcodes what each plan tier can do, so the agent only looks at product_slug and is_free. Same story with array listings where content and _links get ignored when the agent is just browsing. Feels wasteful to bump the token budget for data that gets thrown away.

On the coupling concern: I don't think these endpoint shapes will change that much. plan.features has had this structure for a long time, and content/_links are standard WP REST API fields. But I get the concern about hardcoding endpoint-specific stuff.

Proposal: Add prompt guidance so the agent uses _fields/fields by default, and keep compactResponse() as a safety net for what field filtering can't solve (mainly plan.features).

That said, if you'd rather avoid the coupling I'm also fine with just increasing the token limit and updating the prompt to use fields. What do you think?

If it's just one specific case, I'm fine with it if we add a good comment to explain that it's a special case and not a pattern to follow, with the fields guidance for the generic case.

Do you think the fields guidance will solve all the other cases?

Curious about @lezama's thoughts as well as he was working on alternative solutions.

I have applied the suggestions as part of c457f53 and tested different scenarios, and I have not found the error. The suggested changes seem to do the trick.

@lezama, the approach of trimming the output suggested here is an alternative option that can be applied on top of this changes so we ensure the error is not displayed to the user. In some testing, I have found that the limit is not exact so we can add some extra margin to prevent the error.

Add system prompt hint instructing the agent to use _fields on wp/v2 listing endpoints to minimize response sizes. Scope compactResponse() to only handle plan.features stripping with a clear comment that this is a special case (the API doesn't support sub-field filtering). Remove the generic array compaction in favor of prompt-driven field selection.

sejas

I think it makes sense to remove plan features if they are 60K!. I left a couple of suggestions.

sejas · 2026-04-08T22:18:08Z

apps/cli/ai/wpcom-tools.ts

+ * the system prompt instructs the agent to use `_fields` (wp/v2) or `fields` (v1.1)
+ * query params to request only the properties it needs.
+ */
+function compactResponse( result: ApiResponse ): ApiResponse {


I wonder if we should use a more specific function name, like stripPlanFeatures.

I agree, I have renamed it as part of e21a84e

sejas · 2026-04-08T22:24:28Z

apps/cli/ai/wpcom-tools.ts

+ * system prompt hardcodes what each plan tier can do.
+ *
+ * This is NOT a pattern to follow for other endpoints. For general large responses,
+ * the system prompt instructs the agent to use `_fields` (wp/v2) or `fields` (v1.1)


Is this accurate? I didn’t see the system prompt mention fields for v1.1. Should we add that information to the system prompt?

Great catch! I have updated the system prompt as part of e21a84e as I identified that sometimes fields were failing. I have added a suggestion to use both _fields for wp/v2 or fields for v1.1 to reduce the response size. I have tested multiple scenarios and they all work fine. I have tested:

What's the current name, tagline, and active theme of this site?

Redesign my site to be more polished

Can you update the coming-soon template to have a light background instead of the current one?

And I have not obtained the error

Update system prompt to instruct the agent to use fields (v1.1) and _fields (wp/v2) to minimize response sizes, always including ID for v1.1 requests. Rename compactResponse to stripOversizedFields for clarity.

lezama · 2026-04-09T13:46:07Z

apps/cli/ai/wpcom-tools.ts


-				return textResult( JSON.stringify( result, null, 2 ) );
+				const compacted = stripOversizedFields( result );
+				return textResult( JSON.stringify( compacted, null, 2 ) );


I think it’s better to use JSON.stringify(result) instead of JSON.stringify(compacted, null, 2), since the added indentation increases token usage. I learned this in #3011. I think we can close that PR in favor of this one?

Thanks for the suggestion @lezama! I will apply that

I learned this in #3011. I think we can close that PR in favor of this one?

I think so, and we can apply the learnings on #3011 on follow-ups if required.

Hi @lezama, I went ahead and merged this. You'll want to merge trunk into #3005 to pick up the changes and continue from there or maybe just close it as discussed

…079-characters-exceeds

* Strip bloated plan.features from wpcom_request responses The WP.com /sites/{id} endpoint returns a plan object whose features sub-field alone is 60K+ characters, pushing the total response past Claude Code's ~100K character MCP tool result limit. The agent only needs product_slug, is_free, and expired to gate features, since the system prompt hardcodes what each plan tier can and can't do. Strip plan.features and keep only essential plan properties. * Also compact large array responses by stripping content and _links List endpoints like GET /templates can return 80K+ chars of block markup. Strip content and _links from array items when the response exceeds 80K chars — the agent can still identify items by slug/title and fetch individual ones for full content. * Add _fields prompt guidance and scope plan compaction as special case Add system prompt hint instructing the agent to use _fields on wp/v2 listing endpoints to minimize response sizes. Scope compactResponse() to only handle plan.features stripping with a clear comment that this is a special case (the API doesn't support sub-field filtering). Remove the generic array compaction in favor of prompt-driven field selection. * Add fields guidance for v1.1, rename stripOversizedFields Update system prompt to instruct the agent to use fields (v1.1) and _fields (wp/v2) to minimize response sizes, always including ID for v1.1 requests. Rename compactResponse to stripOversizedFields for clarity. * Remove indentation in JSON to save tokens

epeicher mentioned this pull request Apr 8, 2026

Add WordPress.com REST API support for remote sites in AI command #2992

Merged

1 task

epeicher self-assigned this Apr 8, 2026

youknowriad force-pushed the remote-site-wpcom-mcp branch from ff2e207 to a3c7f6a Compare April 8, 2026 09:43

Base automatically changed from remote-site-wpcom-mcp to trunk April 8, 2026 10:19

epeicher force-pushed the stu-1524-long-api-responses-return-error-96079-characters-exceeds branch from d6c4b3e to 5fccba7 Compare April 8, 2026 11:07

epeicher changed the title ~~Trim oversized plan field in wpcom_site_info response~~ Strip bloated plan.features from wpcom_request responses Apr 8, 2026

epeicher changed the title ~~Strip bloated plan.features from wpcom_request responses~~ Trim oversized plan field in wpcom_request response Apr 8, 2026

epeicher changed the title ~~Trim oversized plan field in wpcom_request response~~ Strip unnecessary fields in wpcom_request response Apr 8, 2026

epeicher requested review from a team and youknowriad April 8, 2026 11:49

youknowriad reviewed Apr 8, 2026

View reviewed changes

youknowriad requested a review from lezama April 8, 2026 16:19

sejas approved these changes Apr 8, 2026

View reviewed changes

Add fields guidance for v1.1, rename stripOversizedFields

e21a84e

Update system prompt to instruct the agent to use fields (v1.1) and _fields (wp/v2) to minimize response sizes, always including ID for v1.1 requests. Rename compactResponse to stripOversizedFields for clarity.

lezama reviewed Apr 9, 2026

View reviewed changes

epeicher added 2 commits April 9, 2026 17:58

Merge branch 'trunk' into stu-1524-long-api-responses-return-error-96…

42ecc04

…079-characters-exceeds

Remove indentation in JSON to save tokens

b7eca66

epeicher enabled auto-merge (squash) April 9, 2026 16:03

epeicher merged commit 770e6ba into trunk Apr 9, 2026
8 of 10 checks passed

epeicher deleted the stu-1524-long-api-responses-return-error-96079-characters-exceeds branch April 9, 2026 16:07

Conversation

epeicher commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related issues

How AI was used in this PR

Proposed Changes

Testing Instructions

Pre-merge Checklist

Uh oh!

wpmobilebot commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📊 Performance Test Results

app-size

site-editor

site-startup

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sejas left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sejas Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

epeicher commented Apr 8, 2026 •

edited

Loading

wpmobilebot commented Apr 8, 2026 •

edited

Loading

sejas Apr 8, 2026 •

edited

Loading