feat(security): make the response size limit configurable

[JorisOrangeStudio]

Description

The guard against oversized tool responses is a bare 100000 in wrapInStandardFormat(). The ceiling that actually matters is the calling client's context window, which differs per client and grows over time, so a site has no way to tune it without forking.

Moves it to statamic.mcp.security.max_response_size, default 100000 so behaviour is unchanged, STATAMIC_MCP_MAX_RESPONSE_SIZE to override, 0 to disable the guard.

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 🔧 Tool enhancement
• 📝 Documentation
• ♻️ Refactoring

Related Issue

None — hit it on a page-builder blueprint where statamic-blueprints get with include_format_spec returns 170KB at the default max_format_depth, so the call fails outright and there is no way to raise the ceiling for a client that could comfortably take it.

Testing

• Tests pass (composer test)
• Code quality checks pass (composer quality)
• Tested manually with Statamic

tests/Feature/ResponseSizeLimitTest.php — 4 cases: the default is still 100000, a lower limit refuses, a raised limit allows a response the default would refuse, and 0 disables the guard.

Full gate green — pint, PHPStan level 9, 1110 tests / 5610 assertions.

Environment

• Statamic: v6.31.0
• Laravel: v13.30.1
• PHP: 8.4.25

Checklist

• My code follows the project style
• I've added/updated tests if needed
• Tool responses follow the standard format

Notes

Mirrors how oauth.cimd_max_response_size is already handled, so this follows the package's own convention for size limits rather than introducing a new one.

Worth saying explicitly: raising the limit is not a fix for a large response, it just moves the wall. The underlying problem — that include_format_spec at its default depth exceeds the guard on a real page-builder blueprint, while the truncation message tells agents to raise the depth — is separate and better solved by making the payload smaller.

[JorisOrangeStudio]

Hi @sylvesterdamgaard, quick note since I've opened a fair few PRs at once.

First of all, thank you for building and maintaining this MCP 🥳

We opened PR's #43 to #51 while testing on our real installs with multi-site enabled and a replicator page builder structure, which is what surfaced most of them.

We've tried to match the project's conventions as closely as we could. Let me know if anything is unclear.