Storyboard 5.13 activate_signal scenario uses wrong field name and wrong type for signal identifier

[EvgenyAndroid]

Subproject: adcontextprotocol/adcp-client (routed to adcp by default — maintainer can move if needed)

Summary

The activate_signal storyboard scenario in scenarios/signals.js (5.13) sends { signal_id, destination, options } but the normative 3.0 GA schema has two bugs relative to the spec:

1. Wrong field name: signal_id is not a valid field. The required field is signal_agent_segment_id (per /schemas/3.0.0/signals/activate-signal-request.json, required: ["idempotency_key", "signal_agent_segment_id", "destinations"]).

2. Wrong type: The storyboard echoes the full SignalID object { source, agent_url, id } returned by get_signals directly into activate_signal. But signal_agent_segment_id is typed as a plain string (x-entity: "signal_activation_id"), not an object. The correct flow is to extract the string ID from the get_signals response and pass that string.

Schema reference

/schemas/3.0.0/signals/activate-signal-request.json:

• Required: idempotency_key, signal_agent_segment_id, destinations
• signal_agent_segment_id: { type: "string", x-entity: "signal_activation_id" }
• No signal_id field exists anywhere in the signals/* schema set

Expected fix

In scenarios/signals.js, the activate_signal call should:

1. Use signal_agent_segment_id (not signal_id)
2. Pass the string ID extracted from the get_signals response (not the full object)
3. Use destinations (not destination) — verify plural form matches schema

Impact

Any signals-only agent correctly implementing the spec will fail or silently ignore the storyboard's activate_signal call, making the storyboard an unreliable compliance signal for this task.

[bokelley]

Thanks for filing!

Triage

Classification: Conformance failure (bug)
Bucket(s): addie (training agent), spec / protocol (schema descriptions)
Status: drafting-pr

What the experts said:

• ad-tech-protocol-expert: signal_id and signal_agent_segment_id are intentionally distinct concepts — the former is a catalog reference object, the latter an opaque activation-handle string. Passing the object in place of the string fails on both field name and type. The compliance storyboard YAMLs in this repo were already correct. Weak schema description was a nit worth fixing.
• code-reviewer: Confirmed the training agent's handleActivateSignal had explicit signal_id/destination shims that masked the bug. Also flagged missing idempotency_key in the tool inputSchema and empty required array — both fixed before merge.

My take: The adcp storyboard YAMLs are clean; the bug lives in two places: (1) the training agent was silently accepting the wrong fields instead of rejecting them — fixed in #3356; (2) the adcp-client scenarios/signals.js sends the malformed payload — that fix must go to adcp-client directly (this issue can be moved there or a new one filed).

Drafting PR #3356 covers the adcp-side fix. The adcp-client scenario fix is tracked separately.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_011S9bnPFjuLTCyPPEUD2AoD

---

Generated by Claude Code