P220 · Tool use

Resolve opaque IDs within their scope

Translate human names into service IDs while retaining parent scope.

Editorially reviewed

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Update Budget inside Finance while another list has Budget. Teaching Finance=L7/Budget=T9 and L8 has T2. Names, opaque IDs and parents must agree across scope.

Mechanism

Resolve workspace/parent then child IDs and ambiguity. Use returned identities/actual schema under operation scope and read back. Nonunique matches remain candidates/questions, not display labels as IDs/default parents.

Bad example

Pass Finance/Budget asIDs or update global L8/T2 despite the requested parent.

Good example

Resolve teaching Finance→L7, thenBudget→T9 inside L7. Use L7/T9 under authorized schema and verify result identity. Ambiguous names do not become guessed/default/cross-workspace cached IDs.

Why the change matters

Labels describe; IDs identify service objects and parent scope disambiguates them. Scoped resolution/readback links action to the user’s target.

Observable expectation

Correct request uses L7/T9, not labels/L8/T2. Duplicate names remain unresolved instead of first-match choice.

Inspect current returned IDs and separate read/write permission. No task is updated.

Limits

IDs/access can expire and hierarchies differ. Frozen formats/defaults are not universal, and lookup authorizes no clear/delete action.

Sources and evidence

Read the editorial criteria