Resolve opaque IDs within their scope
Translate human names into service IDs while retaining parent scope.
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
- ComposioHQ/awesome-claude-skills · Known Pitfalls
File at this versionbe2a406907db - ComposioHQ/awesome-claude-skills · Known Pitfalls
File at this versionbe2a406907db