SM-IS-01 maxLength exemption missing from body/content fields across most tools — follow-up to #43867

[straub]

Summary

#43867 fixed create_discussion.body and create_issue.body by adding maxLength: 65536, exempting them from the SM-IS-01 global 10 KB cap. However, the same gap exists across almost every other body (and equivalent large-content) field in the tool set. The fix in #43867 was narrower than the underlying problem.

How the exemption works (recap)

From mcp_scripts_validation.cjs:

// Skip fields with an explicit maxLength — handler-level validation enforces their limit.
if (typeof schema.maxLength === 'number') {
  continue;
}

Any string field without maxLength is subject to the 10 KB global floor. Fields that should accept large content need maxLength: 65536 (or appropriate value) to delegate enforcement to the GitHub API layer.

Affected fields

These are body / large-content fields currently missing maxLength:

Tool	Field
update_discussion	body
update_issue	body
update_pull_request	body
update_release	body
update_project	draft_body
create_pull_request	body
create_pull_request_review_comment	body
submit_pull_request_review	body
reply_to_pull_request_review_comment	body
close_discussion	body
close_issue	body
close_pull_request	body
create_agent_session	body
create_project_status_update	body
create_check_run	summary, text
autofix_code_scanning_alert	fix_description, fix_code
merge_pull_request	commit_message
push_to_pull_request_branch	message
dismiss_pull_request_review	justification
noop	message
report_incomplete	details

Correct state after #43867 (for reference)

Tool	Field	maxLength
add_comment	body	65536 ✅
create_issue	body	65536 ✅
create_discussion	body	65536 ✅

Fix

Add appropriate maxLength values to all affected fields in both pkg/workflow/js/safe_outputs_tools.json and actions/setup/js/safe_outputs_tools.json. For most body fields, 65536 is the right value (matching add_comment and GitHub's GraphQL API limits). Fields with tighter natural limits (e.g. commit_message, noop.message) may warrant lower values.

Alternatively, consider inverting the SM-IS-01 logic: apply the 10 KB floor only to fields that have not been explicitly sized, and treat the lack of maxLength as "defer to the API" rather than "enforce 10 KB". This would make the safe default permissive and require explicit opt-in to tighter caps — more consistent with how the rest of the schema validation works.