You cannot write a field you cannot name. Guessing at ACF field names is the commonest way an automated edit goes wrong: the call succeeds, nothing changes, and nothing is raised, because ACF was never asked about a field that does not exist.
custom-fields/get-acf-fields removes the guess. One call returns every ACF field attached to a target, each with its name, key, type, label and hydrated value — the discovery step before any edit.
At a glance
| Ability | custom-fields/get-acf-fields |
| Toolset | Advanced Custom Fields — toolset/acf |
| Group | Field Values |
| Requires | Advanced Custom Fields (free edition is enough) |
| Capability | manage_options |
| Safety | Read-only — changes nothing |
| Repeatable | Idempotent — running it twice leaves the same result |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
How it works
ACF decides which field groups apply to a target using its own location rules, so the answer is target-specific: a page and a product can carry completely different fields even though both are posts. This ability asks ACF the same question the edit screen asks, and returns what it gets back.
Each row carries enough to act on: the name to use as a selector, the key that survives a rename, the type that tells you what shape a new value has to take, and the current value so a write can be skipped when it would be a no-op.
The same five target types apply as everywhere else in this suite — post, user, term, comment and option.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
target_type | string | No — defaults to post | What the value is attached to: post, user, term, comment or option. post covers pages and any custom post type. |
target_id | integer | string | Yes, for post, user, term and comment | The ID of the target. Optional for option, where it names a specific options page; omit it for the default options store. |
What comes back
| Name | Type | What it is |
|---|---|---|
fields | array | One row per field: name, key, type, label and hydrated value. |
count | integer | How many fields were found. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
List every custom field on page 87 and tell me which ones are still empty.
It resolves to one call:
{
"ability": "custom-fields/get-acf-fields",
"parameters": {
"target_type": "post",
"target_id": 87
}
}Worth knowing
- Run this before
custom-fields/update-acf-fields. The two are a matched pair: discover the shape, then write several values in one call. - An empty result is a real answer. It means no field group’s location rules match that target — not that the read failed.
- Values come back hydrated, which makes this heavier than a bare field list. On a target carrying large repeaters, ask for the one field you need with
custom-fields/get-acf-fieldinstead.
Related abilities
- Get ACF Field Value — one field, when you already know its name
- Update Multiple ACF Field Values — write several of them back at once
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category