What happened?
Custom field values are not persisted when an article is written through the generated MCP tools, even though the same values are read back correctly.
Steps to reproduce:
- Define a custom field for
com_content.article (e.g. a text field named text-field).
- Create or update an article through the
content.articles.create / content.articles.update MCP tool and supply the custom field, either at the top level ("text-field": "value") or nested ("com_fields": {"text-field": "value"}).
- The article is created/updated successfully (HTTP 2xx).
- Inspect
#__fields_values for the article: the value is missing/empty.
Reading works: an article that already has custom field values returns them as top-level attributes through content.articles.get / content.articles.list.
Version
contract-projection-chain branch (MCP contract work, __DEPLOY_VERSION__) — not a released version; the version selector above does not apply.
Expected result
A custom field supplied on create/update is stored the way the established web services REST API stores it (routed to com_fields and saved by the fields plugin), and reads back on the next request.
Actual result
The article is saved but the custom field value is dropped; #__fields_values has no row for it. Only the built-in fields persist.
System Information
Local development environment. Branch contract-projection-chain, endpoint /api/index.php/v1/mcp, internal dispatch path (ComponentApiDispatcher → existing com_content API controller).
Additional Comments
Root cause, verified in the plugin code:
The argument mapper already forwards undeclared custom fields into the request body, and the resource declares additionalProperties, so the values reach the controller. However, the system/fields plugin's onContentPrepareForm reads jform via $this->getApplication()->getInput(). During an internal dispatch that is the outer MCP application, not the internal request where ApiController::save() set jform. The custom fields are therefore not prepared into the form, $model->validate() drops the com_fields values, and onContentAfterSave has nothing to store.
This is the documented transitional limitation that third-party code reading the top-level ApiApplication observes the outer MCP request. Forwarding the values is necessary but not sufficient; the fix belongs with propagating the internal application (and its input) to plugins during dispatch, not with the argument mapper.
Related (separate, and per the templates a Discussion rather than an issue): the article options registry (attribs, the "Options" tab) is not modelled in the create/update schema either.
What happened?
Custom field values are not persisted when an article is written through the generated MCP tools, even though the same values are read back correctly.
Steps to reproduce:
com_content.article(e.g. a text field namedtext-field).content.articles.create/content.articles.updateMCP tool and supply the custom field, either at the top level ("text-field": "value") or nested ("com_fields": {"text-field": "value"}).#__fields_valuesfor the article: the value is missing/empty.Reading works: an article that already has custom field values returns them as top-level attributes through
content.articles.get/content.articles.list.Version
contract-projection-chainbranch (MCP contract work,__DEPLOY_VERSION__) — not a released version; the version selector above does not apply.Expected result
A custom field supplied on create/update is stored the way the established web services REST API stores it (routed to
com_fieldsand saved by the fields plugin), and reads back on the next request.Actual result
The article is saved but the custom field value is dropped;
#__fields_valueshas no row for it. Only the built-in fields persist.System Information
Local development environment. Branch
contract-projection-chain, endpoint/api/index.php/v1/mcp, internal dispatch path (ComponentApiDispatcher→ existingcom_contentAPI controller).Additional Comments
Root cause, verified in the plugin code:
The argument mapper already forwards undeclared custom fields into the request body, and the resource declares
additionalProperties, so the values reach the controller. However, thesystem/fieldsplugin'sonContentPrepareFormreadsjformvia$this->getApplication()->getInput(). During an internal dispatch that is the outer MCP application, not the internal request whereApiController::save()setjform. The custom fields are therefore not prepared into the form,$model->validate()drops thecom_fieldsvalues, andonContentAfterSavehas nothing to store.This is the documented transitional limitation that third-party code reading the top-level
ApiApplicationobserves the outer MCP request. Forwarding the values is necessary but not sufficient; the fix belongs with propagating the internal application (and its input) to plugins during dispatch, not with the argument mapper.Related (separate, and per the templates a Discussion rather than an issue): the article options registry (
attribs, the "Options" tab) is not modelled in the create/update schema either.