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
Read-only mode filters the action enum, the tool description and the annotations — but notspec.Props. Every tool advertises its full property set in both modes, so a read-only session sees parameters that only the hidden write actions use.
Measured on the current branch, comparing each spec's props against those the read-available handlers actually read:
Tool
Write-only props advertised in read-only mode
gateway_sources
config, description, type
gateway_destinations
config, description, type
gateway_connections
description, rules
gateway_issues
status
gateway_transformations
none — code, env, request and connection_id belong to run, which is a read
Nine properties across four tools.
Why it matters
The handler gate is correct — Dispatch blocks the write action regardless, so nothing can be done with these. The cost is that the schema offers affordances the session cannot use, which is the same failure the events/requests split (#360) was about: a model reading gateway_sources in read-only mode sees config and type and has no way to know they belong to actions it was not offered. The best measurement available on this (WildAGTEval, arXiv 2601.00268) found irrelevant information in an API specification the worst of 60 complexity dimensions tested, at −27.3% for strong models.
The scale is much smaller than #360 — two or three properties rather than twenty-four — so this is a follow-up rather than a release blocker.
Options
Per-property mode metadata. Add something like Prop.Write bool, and have Define filter props the same way it filters actions. Smallest change, keeps one spec per tool, and puts the two filters side by side so they cannot drift.
Per-property action metadata. Tag each prop with the actions that use it and filter to the available set. More precise, more bookkeeping, and it starts to reinvent per-action schemas.
Option 1 looks right: it matches how actions are already handled, and the mapping is one boolean per property.
Whichever is chosen, it should come with a test in the shape of the existing coverage gates — assert that no property advertised in read-only mode is unused by the read-available actions, so a new write-only property cannot be added without noticing.
What
Raised in review of #348 (comment).
Read-only mode filters the
actionenum, the tool description and the annotations — but notspec.Props. Every tool advertises its full property set in both modes, so a read-only session sees parameters that only the hidden write actions use.Measured on the current branch, comparing each spec's props against those the read-available handlers actually read:
gateway_sourcesconfig,description,typegateway_destinationsconfig,description,typegateway_connectionsdescription,rulesgateway_issuesstatusgateway_transformationscode,env,requestandconnection_idbelong torun, which is a readNine properties across four tools.
Why it matters
The handler gate is correct —
Dispatchblocks the write action regardless, so nothing can be done with these. The cost is that the schema offers affordances the session cannot use, which is the same failure the events/requests split (#360) was about: a model readinggateway_sourcesin read-only mode seesconfigandtypeand has no way to know they belong to actions it was not offered. The best measurement available on this (WildAGTEval, arXiv 2601.00268) found irrelevant information in an API specification the worst of 60 complexity dimensions tested, at −27.3% for strong models.The scale is much smaller than #360 — two or three properties rather than twenty-four — so this is a follow-up rather than a release blocker.
Options
Prop.Write bool, and haveDefinefilter props the same way it filters actions. Smallest change, keeps one spec per tool, and puts the two filters side by side so they cannot drift.Option 1 looks right: it matches how actions are already handled, and the mapping is one boolean per property.
Whichever is chosen, it should come with a test in the shape of the existing coverage gates — assert that no property advertised in read-only mode is unused by the read-available actions, so a new write-only property cannot be added without noticing.
Related