I've been quietly enjoying the fact that the ERP MCP server has form tools, not just data tools. Data tools are the obvious half: read, create, update, delete. Fine. But form tools let an agent do the other thing — open a page, set a control, click an action — the way a person would, with all your posting logic and validation firing exactly as designed. No parallel API surface to build. That still feels slightly magical to me.
What I hadn't thought about until this week is that "drive the form like a user" means the agent has to find your controls. By name. And that puts a design decision I made three years ago, half-asleep, directly in the critical path of an AI workflow.
Buried in the 10.0.49 platform notes is a set of form-tool fixes that are much more interesting than their one-line summaries suggest:
FrameOptionButton = Radio and Check groups — were a control family the agent couldn't read or set at all. Not "worked badly." Couldn't touch. If a required step on your form is a radio group, that flow just didn't work.So a whole class of "the agent kind of works on this form, sometimes" was really just naming collisions and one blind spot.
This is the first time control naming has had a functional consequence for me. FormStringControl1 never hurt anyone before — it does now. Vague, duplicated, or near-identical control names are the difference between an agent completing a task and giving up in a way nobody can debug.
My takeaway: if you're building agent flows over custom forms, the fix isn't in the agent. Get onto PU73 PQU-1 (7.0.8199.29+; it's backported to 10.0.48 and 10.0.47 too), then go read your own form designs out loud. Would you know which control to click from the names alone? If not, neither will the agent.
I've got a PurchTableExt form I'm suddenly not proud of. Tomorrow's problem.
I've been quietly enjoying the fact that the ERP MCP server has form tools, not just data tools. Data tools are the obvious half: read, create, update, delete. Fine. But form tools let an agent do the other thing — open a page, set a control, click an action — the way a person would, with all your posting logic and validation firing exactly as designed. No parallel API surface to build. That still feels slightly magical to me.
What I hadn't thought about until this week is that "drive the form like a user" means the agent has to find your controls. By name. And that puts a design decision I made three years ago, half-asleep, directly in the critical path of an AI workflow.
Buried in the 10.0.49 platform notes is a set of form-tool fixes that are much more interesting than their one-line summaries suggest:
FrameOptionButton = Radio and Check groups — were a control family the agent couldn't read or set at all. Not "worked badly." Couldn't touch. If a required step on your form is a radio group, that flow just didn't work.So a whole class of "the agent kind of works on this form, sometimes" was really just naming collisions and one blind spot.
This is the first time control naming has had a functional consequence for me. FormStringControl1 never hurt anyone before — it does now. Vague, duplicated, or near-identical control names are the difference between an agent completing a task and giving up in a way nobody can debug.
My takeaway: if you're building agent flows over custom forms, the fix isn't in the agent. Get onto PU73 PQU-1 (7.0.8199.29+; it's backported to 10.0.48 and 10.0.47 too), then go read your own form designs out loud. Would you know which control to click from the names alone? If not, neither will the agent.
I've got a PurchTableExt form I'm suddenly not proud of. Tomorrow's problem.
No comments yet. Be the first to comment!