OpenAI Agents SDK: resolve bounded literal tool-list concatenation in static binding evidence

[pengfei-threemoonslab]

Problem

A supported OpenAI Agents SDK source using Agent(name="example", tools=[read_tool] + [other_tool]) has a statically enumerable list, but the binding reader reports a dynamic tools expression and leaves the graph incomplete. A developer receives an evidence gap for syntax that requires no code execution to enumerate.

Evidence

Reproduced while implementing #561 on main c079864e8a37209a7712d74197fd1cf1b4ebf06e: two local @function_tool functions followed by the expression above produce the dynamic-tools warning in inputs/openai_sdk_static.py::_extract_agent_bindings. _resolve_name_list handles literal list/tuple/name forms and has no ast.BinOp/ast.Add branch. [read_tool, other_tool] avoids that particular warning. The example still owes any independent binding/authority evidence; removing this warning alone must not promise a passing verdict.

#561 identifies this exact parser limitation as sdk_literal_tool_list_concatenation_unsupported and gives a truthful recovery. It deliberately does not extend extraction while changing the diagnostic contract.

Scope

Add a bounded static list-concatenation resolver for literal lists of names, then resolve each element through the existing tool-identity and binding machinery. Preserve element order and existing handling of unknown symbols. Start with the demonstrated two-list shape; reject or explicitly bound nested expressions. Calls, overloaded objects, unpacking and arbitrary evaluation remain unresolved unless separately proven supported. Never import or execute user code, and do not infer deployed authority or manufacture declarations.

Acceptance

• The literal two-list example yields the same observed binding edges as the equivalent one-list form, without the unsupported-concatenation warning.
• Unknown names, runtime calls, unpacking and unsupported operands remain explicit incomplete evidence.
• Any nesting/size limits are deterministic and tested; user code is never executed.
• Recovery metadata is retired only when that specific limitation no longer applies; unrelated declaration and release obligations remain unchanged.

Sequencing

Deferred from #561 under the requested implementation discipline. Related to #328 coverage quality; this is a bounded SDK reader repair, not a new adapter or a universal static-evaluation promise. No new v1.0 gate is implied until the selected qualification cases establish that this form is required.