Advanced Custom Fields does not store a field the way it looks on the edit screen. A repeater is one meta row per index per sub-field. An image is an attachment ID. A relationship is a serialised array of post IDs. Read those rows directly and you get storage, not values.
custom-fields/get-acf-field reads one field the way ACF itself would — through get_field() — from a post, a user, a term, a comment or the options store. What comes back is the hydrated value plus the field’s name, key, type and label, so an assistant knows what it is holding before deciding what to do next.
At a glance
| Ability | custom-fields/get-acf-field |
| 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
Every ACF field is addressed by a selector: either the field name you see in the ACF admin (hero_title) or the underlying field key (field_abc123). Both work here. The name is the one a human recognises; the key is the one that survives a rename.
The target pair decides where to look. target_type: "post" with a post ID covers posts, pages and every custom post type. user, term and comment take their own IDs, and option reads the options store — the one place where target_id is optional.
Because the read runs through ACF, complex types come back in their proper shape: repeaters as arrays of row objects, flexible content with its layout names intact, post objects and relationships as real post data rather than bare IDs.
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. |
selector | string | Yes | Field name (e.g. hero_title) or field key (e.g. field_abc123). The name is what you see in the ACF admin. |
What comes back
| Name | Type | What it is |
|---|---|---|
field | object | The field’s name, key, type, label and hydrated value. |
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:
What’s in the hero_title field on post 412?
It resolves to one call:
{
"ability": "custom-fields/get-acf-field",
"parameters": {
"target_type": "post",
"target_id": 412,
"selector": "hero_title"
}
}Worth knowing
- Reading first is what makes a later write idempotent. Ask for the current value, compare, and skip the write when nothing would change.
- A selector that names no field on the target returns a typed error rather than
null, so a typo is visible instead of looking like an empty field. - Need everything at once?
custom-fields/get-acf-fieldsreturns every field on the target in a single call.
Related abilities
- Get All ACF Field Values — every field on the target in one call
- Update ACF Field Value — the write that should follow this read
- Delete ACF Field Value — clear the value once you have a copy of it
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category