Summary
The SM-IS-01 global string-length cap (10 KB per string parameter, enforced in mcp_scripts_validation.cjs) is bypassed for any field with an explicit maxLength in the schema. add_comment.body correctly has maxLength: 65536 and is exempt. create_discussion.body and create_issue.body have no maxLength and are therefore silently subject to the 10 KB cap — despite both tools intending to accept much larger bodies.
Root cause
From mcp_scripts_validation.cjs:
const MAX_STRING_INPUT_BYTES = 10 * 1024;
// ...
// Skip fields with an explicit maxLength — handler-level validation enforces their limit.
if (typeof schema.maxLength === 'number') {
continue;
}
Current state of the three content-body fields:
| Tool |
body.maxLength |
Effective cap |
add_comment |
65536 |
65 KB ✅ |
create_issue |
(none) |
10 KB ❌ |
create_discussion |
(none) |
10 KB ❌ |
create_issue's 10 KB cap hasn't been noticed in practice because issue bodies are rarely that large. create_discussion is the canary — report-generating workflows that post changelogs, audit summaries, or research digests naturally produce bodies well above 10 KB.
History
The SM-IS-01 enforcement was implemented 2026-05-28. Issue #37409 (filed 2026-06-05) observed two production report workflows hitting the create_discussion limit and recommended adding documentation. PR #37421 (2026-06-06) responded by documenting "Maximum 10 KB" in the create_discussion.body description — treating it as an intended constraint rather than a gap in the maxLength escape hatch.
Fix
Add maxLength: 65536 to create_discussion.body and create_issue.body in both schema files, matching add_comment:
pkg/workflow/js/safe_outputs_tools.json (and the runtime copy actions/setup/js/safe_outputs_tools.json):
// create_discussion
"body": {
"type": "string",
"maxLength": 65536,
"description": "Discussion content in Markdown. ..."
}
// create_issue
"body": {
"type": "string",
"maxLength": 65536,
"description": "Detailed issue description in Markdown. ..."
}
The SM-IS-01 validator will then defer to handler-level enforcement (GitHub's own API limits) for these fields, consistent with how add_comment already works.
Also
The "Maximum 10 KB" guidance added to create_discussion.body in #37421 should be removed — it describes the accidental cap, not an intended limit.
Summary
The SM-IS-01 global string-length cap (10 KB per string parameter, enforced in
mcp_scripts_validation.cjs) is bypassed for any field with an explicitmaxLengthin the schema.add_comment.bodycorrectly hasmaxLength: 65536and is exempt.create_discussion.bodyandcreate_issue.bodyhave nomaxLengthand are therefore silently subject to the 10 KB cap — despite both tools intending to accept much larger bodies.Root cause
From
mcp_scripts_validation.cjs:Current state of the three content-body fields:
body.maxLengthadd_comment65536create_issuecreate_discussioncreate_issue's 10 KB cap hasn't been noticed in practice because issue bodies are rarely that large.create_discussionis the canary — report-generating workflows that post changelogs, audit summaries, or research digests naturally produce bodies well above 10 KB.History
The SM-IS-01 enforcement was implemented 2026-05-28. Issue #37409 (filed 2026-06-05) observed two production report workflows hitting the
create_discussionlimit and recommended adding documentation. PR #37421 (2026-06-06) responded by documenting "Maximum 10 KB" in thecreate_discussion.bodydescription — treating it as an intended constraint rather than a gap in themaxLengthescape hatch.Fix
Add
maxLength: 65536tocreate_discussion.bodyandcreate_issue.bodyin both schema files, matchingadd_comment:pkg/workflow/js/safe_outputs_tools.json(and the runtime copyactions/setup/js/safe_outputs_tools.json):The SM-IS-01 validator will then defer to handler-level enforcement (GitHub's own API limits) for these fields, consistent with how
add_commentalready works.Also
The "Maximum 10 KB" guidance added to
create_discussion.bodyin #37421 should be removed — it describes the accidental cap, not an intended limit.