Motivation
list_resources returns full objects. For agent use this is the biggest cost driver: a question like "which of my resources aren't ready" pulls every manifest into the model context when one line per resource would do.
Proposal
Additions to list_resources (and get_resource where it applies):
fields: a list of JSONPath-like projections, for example metadata.name, spec.kubernetes.version. The response contains only those fields per item.limit and continue: standard list pagination passed through to kcp.conditionSummary: opt-in flag that reduces each item to name, namespace and its failing or unknown conditions (type, reason, message). Ready resources are returned as a count.
Server-side projection keeps responses compact regardless of the model or client. Label and field selectors already exist, this completes the story for read-heavy agent workloads.
Validation notes
Verified against a live deployment: the data needed for fleet-wide checks (status conditions, spec fields) is all present in responses today, but only as full manifests.
Typical agent questions ("do all my X run multi-zone", "which resources aren't ready", "what versions are my X on") need only two or three fields per item.
Motivation
list_resourcesreturns full objects. For agent use this is the biggest cost driver: a question like "which of my resources aren't ready" pulls every manifest into the model context when one line per resource would do.Proposal
Additions to
list_resources(andget_resourcewhere it applies):fields: a list of JSONPath-like projections, for examplemetadata.name,spec.kubernetes.version. The response contains only those fields per item.limitandcontinue: standard list pagination passed through to kcp.conditionSummary: opt-in flag that reduces each item to name, namespace and its failing or unknown conditions (type, reason, message). Ready resources are returned as a count.Server-side projection keeps responses compact regardless of the model or client. Label and field selectors already exist, this completes the story for read-heavy agent workloads.
Validation notes
Verified against a live deployment: the data needed for fleet-wide checks (status conditions, spec fields) is all present in responses today, but only as full manifests.
Typical agent questions ("do all my X run multi-zone", "which resources aren't ready", "what versions are my X on") need only two or three fields per item.