LSEG AI

Accept a Market Maker's Quote and manually trigger RFQ execution. Used by the RFQ Requestor — MANUAL RFQs only (Automatic RFQs execute via the Exchange automatically; never use this tool for them). quoteRespType is fixed to HIT_OR_LIFT. ROLE CONTEXT: User is the RFQ Requestor when it owns/submits the RFQ (submit/amend/cancel it, view quotes or rejects on it, accept a quote, check status). User is a Market Maker (MM) when responding to an RFQ it received. Role is per-RFQ, not permanent — infer from the action when unambiguous, else ASK. Before acting, call get_active_quotes fresh — never use a remembered/stale quote. Also check get_latest_quote_responses and get_latest_execution_reports to confirm the selected quote/side hasn't already expired, been cancelled, or executed. If multiple quotes could match, ask the user which one to accept — never choose on the user's behalf. VALIDATION BOUNDARY: Enforce this schema only; never invent extra ownership/state/uniqueness/business validation — downstream/Exchange owns those checks. Preserve user-confirmed and Exchange-returned identifiers exactly. quoteMsgId should be unique per its field definition, but never generate/replace a user-confirmed value or block the request solely because it appears reused. TOOL-CALL INTEGRITY: 'call this tool' always means issuing a real tool/function call through the tool-calling mechanism and waiting for its actual response — never write out, guess, or pre-narrate an ack/reject/report/status as if it already came back. Do not describe, summarize, or act on an outcome for this submission until the real tool response has been returned. If the call errors or times out, report that failure verbatim — never invent a plausible success or fallback outcome in its place. Follow these steps in order before calling this tool: Step 1 — Collect required fields one at a time, in this order (see each property's own description for the exact question/validation to use): quoteMsgId (should be unique per its field definition; never generate, replace or block a user-confirmed value), rfqId, quoteRespType (must be HIT_OR_LIFT), securityId, orderQty (the quantity to execute — must be explicit; never assume full RFQ/quote size unless the user says so), parties (has its own sub-steps). Step 2 — Once all required fields are collected, ask the user: 'Would you like to provide any optional fields before submitting the quote acceptance request? (yes / no)' If YES — go through each of these top-level optional fields one at a time (see each field description for the exact question to ask). Skip any the user declines: bidId, offerId, price, side, transactTime If NO — proceed immediately to Step 3. IMPORTANT: The parties array collected in Step 1 is already complete. Do NOT re-visit, modify, or strip any fields from it during this step. IMPORTANT: side determines which identifier to use from the fresh quote — if side is BUY, use the quote's exact bidId; if side is SELL, use its exact offerId. Never invent or swap these. price, if supplied, must be the quote's exact price — never calculated or rounded. Step 3 — MANDATORY CONFIRMATION — you MUST always perform this step before calling this tool, with no exceptions: Display a summary of ALL values the user has provided, including the selected quote/side identifier, then ask: 'Please review the details above. Do you confirm the quote acceptance and execution request? (yes / no)' If YES — call this tool. If NO — ask the user which field they want to change, update it, then repeat Step 3. NEVER call this tool without receiving explicit confirmation from the user in this step. RESPONSE INTERPRETATION: success is confirmed only by a returned execution_report; a quote_status_report means the execution instruction was not accepted — never claim success merely because this tool was called. For later execution/current-state questions, re-poll get_latest_execution_reports and get_latest_quote_responses as applicable — other quotes/RFQ sides may subsequently expire and won't appear in this immediate response. Re-poll get_active_quotes fresh if the user wants to see quotes again.

lse24-accept_quote

Amend an existing Quote submitted in response to an RFQ. Used by a Market Maker (MM). There is no polling method to get the active quote list submitted by the MM; related existing values must come from reliably-known user/application context or be clarified with the user. Use submit_quote for a new quote, cancel_quote to cancel, or amend_rfq for a Requestor's own RFQ amendment instead. ROLE CONTEXT: User is the RFQ Requestor when it owns/submits the RFQ (submit/amend/cancel it, view quotes or rejects on it, accept a quote, check status). User is a Market Maker (MM) when responding to an RFQ it received. Role is per-RFQ, not permanent — infer from the action when unambiguous, else ASK. CRITICAL STRUCTURE RULE: the amendment MUST preserve the original quote's side-structure. First establish whether the original quote was DUAL-SIDED, SINGLE-SIDED BID, or SINGLE-SIDED OFFER — ASK if not explicitly known, never guess. A dual-sided quote must stay dual-sided (resend BOTH bidPx/bidSize and offerPx/offerSize — changing only the value(s) requested and resending the unchanged side's exact existing price/size); a single-sided quote must stay on that same side — never switch sides, never convert single↔dual, and never fill the unused side with 0/blank/null. get_active_quotes is a Requestor-only tool and must NOT be used to look up the MM's own quote values — if an unchanged value isn't reliably known, ask the user rather than inventing it. VALIDATION BOUNDARY: Enforce this schema only; never invent extra ownership/state/uniqueness/business validation — downstream/Exchange owns those checks. Preserve user-confirmed identifiers exactly. quoteMsgId should be unique per its field definition, but never generate/replace a user-confirmed value or block the request solely because it appears reused. TOOL-CALL INTEGRITY: 'call this tool' always means issuing a real tool/function call through the tool-calling mechanism and waiting for its actual response — never write out, guess, or pre-narrate an ack/reject/report/status as if it already came back. Do not describe, summarize, or act on an outcome for this submission until the real tool response has been returned. If the call errors or times out, report that failure verbatim — never invent a plausible success or fallback outcome in its place. Follow these steps in order before calling this tool: Step 1 — Collect required fields one at a time, in this order (see each property's own description for the exact question/validation to use): quoteMsgId (should be unique per its field definition; never generate, replace or block a user-confirmed value), rfqId, securityId, parties (has its own sub-steps), accountType, orderCapacity. Step 2 — Once all required fields are collected, ask the user: 'Would you like to provide any optional fields before submitting the quote amendment request? (yes / no)' If YES — go through each of these top-level optional fields one at a time (see each field description for the exact question to ask). Skip any the user declines: bidPx, bidSize, offerPx, offerSize, orderAttributes, orderOrigination If NO — proceed immediately to Step 3. IMPORTANT: The parties array collected in Step 1 is already complete. Do NOT re-visit, modify, or strip any fields from it during this step. IMPORTANT: rfqId must reference the same RFQ to which the original quote was submitted. bidPx and bidSize must either both be provided or both be omitted; offerPx and offerSize must either both be provided or both be omitted — each included side always needs a complete price+size pair, per the original quote's structure above. For a dual-sided original Quote, both complete sides must be resent; for a single-sided original Quote, only that same complete side is sent. Party information, accountType and orderCapacity must remain consistent with the original quote; if an existing value needed to preserve the Quote is not reliably known, ASK rather than invent it. Step 3 — MANDATORY CONFIRMATION — you MUST always perform this step before calling this tool, with no exceptions: Display a summary showing the original quote's structure, what is changing, and what is being resent unchanged, then ask: 'Please review the details above. Do you confirm the quote amendment request? (yes / no)' If YES — call this tool. If NO — ask the user which field they want to change, update it, then repeat Step 3. NEVER call this tool without receiving explicit confirmation from the user in this step. RESPONSE INTERPRETATION: the returned quote_ack (ACCEPTED/REJECTED) is only the immediate outcome — never proof the amended quote remains live later; poll get_latest_quote_responses/get_latest_execution_reports for ongoing status. The Requestor only sees the amended quote via a fresh get_active_quotes call, never from this response.

lse24-amend_quote

Amend ONLY the price of an already-submitted RFQ. Used by the RFQ Requestor. There is no polling method to get the active RFQ list submitted by the Requestor; related existing values must come from reliably-known user/application context or be clarified with the user. Cannot change instrument, quantity, side or parties — use amend_quote for a Market Maker's own quote, cancel_rfq to cancel, or submit_rfq for a new RFQ instead. ROLE CONTEXT: User is the RFQ Requestor when it owns/submits the RFQ (submit/amend/cancel it, view quotes or rejects on it, accept a quote, check status). User is a Market Maker (MM) when responding to an RFQ it received. Role is per-RFQ, not permanent — infer from the action when unambiguous, else ASK. 'Keep everything else unchanged' means preserve the RFQ's existing values for all applicable fields represented by the amend_rfq schema. Any existing RFQ field that must be populated in amend_rfq to preserve the RFQ unchanged MUST be carried forward using its exact reliably-known original value; only price may change. Do not make the user re-enter or re-decide an unchanged value that is already reliably known. If an applicable existing value cannot be reliably obtained, ASK the user — never invent, infer or substitute it. Only populate fields defined by this schema, and do not auto-carry-forward fields that are not applicable to the amendment (including transactTime, bidId or offerId merely because they existed previously). VALIDATION BOUNDARY: Enforce this schema only; never invent extra ownership/state/uniqueness/business validation — downstream/Exchange owns those checks. Preserve user-confirmed identifiers exactly; never generate or replace them on your own. TOOL-CALL INTEGRITY: 'call this tool' always means issuing a real tool/function call through the tool-calling mechanism and waiting for its actual response — never write out, guess, or pre-narrate an ack/reject/report/status as if it already came back. Do not describe, summarize, or act on an outcome for this submission until the real tool response has been returned. If the call errors or times out, report that failure verbatim — never invent a plausible success or fallback outcome in its place. Follow these steps in order before calling this tool: Step 1 — Collect required fields one at a time, in this order (see each property's own description for the exact question/validation to use): quoteMsgId, rfqId, quoteRespType, securityId, parties (has its own sub-steps). If the user said to keep other details unchanged, reuse exact required existing values already reliably known for this RFQ instead of asking the user to redefine them. If any required existing value is not reliably known, ASK for the existing value — never guess or copy from another RFQ. Step 2 — Once all required fields are collected, ask the user: 'All required fields are collected. Would you like to provide any optional fields before submitting the RFQ amendment? (yes / no)' If YES — go through each of these top-level optional fields one at a time (see each field description for the exact question to ask). Skip any the user declines or any already carried forward unchanged because it is reliably known and applicable: price, side, orderQty, transactTime, bidId, offerId If NO — proceed immediately to Step 3. IMPORTANT: The parties array collected/reused in Step 1 is already complete. Do NOT re-visit, modify, normalize, reorder, or strip any fields from it during this step unless the user explicitly requests a permitted change. IMPORTANT: quoteRespType must be REPLACE. price is the only field that can be amended: collect the new price for an explicit change, or omit/set to 0 only when the user explicitly intends to remove the limit price — never treat accidental omission as removal. orderQty cannot be amended and, if provided, must match the original RFQ's exact quantity; reuse it if reliably known, otherwise ask for the existing quantity — never infer. side cannot be amended and, if provided, must match the original RFQ's exact side; reuse it if reliably known, otherwise ask for the existing side — never guess BUY or SELL. transactTime is current-message metadata and must not be copied from the original RFQ merely because the user said to keep everything unchanged. bidId and offerId are not normally required and must never be auto-carried-forward from the original RFQ. Step 3 — MANDATORY CONFIRMATION — you MUST always perform this step before calling this tool, with no exceptions: Display a summary that clearly distinguishes the new amended price (or explicit limit-price removal) from unchanged carried-forward values (rfqId, securityId, parties, side/orderQty when included) and new request metadata (quoteMsgId, quoteRespType=REPLACE, transactTime when applicable), then ask: 'Please review the details above. Do you confirm the RFQ amendment request? (yes / no)' If YES — call this tool. If NO — ask the user which field they want to change, update only that field, then repeat Step 3. NEVER call this tool without receiving explicit confirmation from the user in this step. RESPONSE INTERPRETATION: the response contains a quote_status_report (ACCEPTED/REJECTED) plus a REPLACE quote_response when accepted — invoking this tool never by itself means success. For later RFQ status, poll get_latest_quote_responses and get_latest_execution_reports as applicable. If the Requestor asks to view quotes after the amendment, call get_active_quotes fresh; never reuse a pre-amendment snapshot.

lse24-amend_rfq

Cancel one or more previously submitted Quotes. Used by a Market Maker (MM). There is no polling method to get the active quote list submitted by the MM; related existing values must come from reliably-known user/application context or be clarified with the user. ROLE CONTEXT: User is the RFQ Requestor when it owns/submits the RFQ (submit/amend/cancel it, view quotes or rejects on it, accept a quote, check status). User is a Market Maker (MM) when responding to an RFQ it received. Role is per-RFQ, not permanent — infer from the action when unambiguous, else ASK. CRITICAL: quoteCancelType must be exactly one of CANCEL_FOR_INSTRUMENTS, CANCEL_ALL_QUOTES, CANCEL_BUY_QUOTE_FOR_INSTRUMENTS or CANCEL_SELL_QUOTE_FOR_INSTRUMENTS — ask if the user's intended scope isn't explicit; never guess or broaden/narrow it yourself. VALIDATION BOUNDARY: Enforce this schema only; never invent extra ownership/state/uniqueness/business validation — downstream/Exchange owns those checks. Preserve user-confirmed identifiers exactly. quoteMsgId should be unique per its field definition, but never generate/replace a user-confirmed value or block the request solely because it appears reused. TOOL-CALL INTEGRITY: 'call this tool' always means issuing a real tool/function call through the tool-calling mechanism and waiting for its actual response — never write out, guess, or pre-narrate an ack/reject/report/status as if it already came back. Do not describe, summarize, or act on an outcome for this submission until the real tool response has been returned. If the call errors or times out, report that failure verbatim — never invent a plausible success or fallback outcome in its place. Follow these steps in order before calling this tool: Step 1 — Collect required fields one at a time, in this order (see each property's own description for the exact question/validation to use): quoteMsgId (should be unique per its field definition; never generate, replace or block a user-confirmed value), quoteCancelType (must reflect the user's explicit cancellation intent), targetParties (has its own sub-steps; must contain exactly one target party object — targetPartyIdSource must be PROPRIETARY_OR_CUSTOM_CODE, targetPartyId must come from the user, never invented). Step 2 — Once all required fields are collected, ask the user: 'Would you like to provide any optional fields before submitting the quote cancellation request? (yes / no)' If YES — go through each of these top-level optional fields one at a time (see each field description for the exact question to ask). Skip any the user declines: rfqId, quoteEntries If NO — proceed immediately to Step 3. IMPORTANT: The targetParties array collected in Step 1 is already complete. Do NOT re-visit, modify, or strip any fields from it during this step. If quoteCancelType is CANCEL_FOR_INSTRUMENTS, CANCEL_BUY_QUOTE_FOR_INSTRUMENTS or CANCEL_SELL_QUOTE_FOR_INSTRUMENTS, quoteEntries (securityId per instrument) is required to identify the instruments whose quotes are to be cancelled — never invent or omit intended instruments. For CANCEL_ALL_QUOTES, quoteEntries is not required; do not invent or populate it merely because instrument information is available. rfqId only applies to a specific single-RFQ/single-instrument cancellation — never invent it for a broader mass-cancellation (the Matching Engine ignores it there). If targetPartyRole is MEMBER_ID, the cancellation is scoped at member level; if TRADER_GROUP, it is scoped at trader-group level. For user-specific quote cancellation, targetPartyRole should be TRADER_GROUP. Step 3 — MANDATORY CONFIRMATION — you MUST always perform this step before calling this tool, with no exceptions: Display a summary stating the scope (specific vs. mass), target party, rfqId if applicable, and every instrument involved, then ask: 'Please review the details above. Do you confirm the quote cancellation request? (yes / no)' If YES — call this tool. If NO — ask the user which field they want to change, update it, then repeat Step 3. NEVER call this tool without receiving explicit confirmation from the user in this step. RESPONSE INTERPRETATION: expect a quote_ack (single quote-level) or a mass_quote_acknowledgement (mass — may include per-instrument quoteSets/quoteEntries results); interpret per the actual response type. A missing entry is never a known outcome — never guess it was filled/cancelled/expired. The Requestor learns of a successful cancellation only via a fresh get_latest_quote_responses poll (quoteRespType=CANCELLED) — not from this response; get_active_quotes alone can never prove cancellation. For broader current quote state, also use get_latest_execution_reports when execution-related events may be relevant.

lse24-cancel_quote

Cancel an already-submitted RFQ. Used by the RFQ Requestor. There is no polling method to get the active RFQ list submitted by the Requestor; related existing values must come from reliably-known user/application context or be clarified with the user. quoteRespType is fixed to END_TRADE. Existence/ownership/eligibility checks belong to the Exchange — do not use get_active_rfq_requests (MM-only) to pre-validate. ROLE CONTEXT: User is the RFQ Requestor when it owns/submits the RFQ (submit/amend/cancel it, view quotes or rejects on it, accept a quote, check status). User is a Market Maker (MM) when responding to an RFQ it received. Role is per-RFQ, not permanent — infer from the action when unambiguous, else ASK. VALIDATION BOUNDARY: Enforce this schema only; never invent extra ownership/state/uniqueness/business validation — downstream/Exchange owns those checks. Preserve user-confirmed identifiers exactly. quoteMsgId should be unique per its field definition, but never generate/replace a user-confirmed value or block the request solely because it appears reused. TOOL-CALL INTEGRITY: 'call this tool' always means issuing a real tool/function call through the tool-calling mechanism and waiting for its actual response — never write out, guess, or pre-narrate an ack/reject/report/status as if it already came back. Do not describe, summarize, or act on an outcome for this submission until the real tool response has been returned. If the call errors or times out, report that failure verbatim — never invent a plausible success or fallback outcome in its place. Follow these steps in order before calling this tool: Step 1 — Collect required fields one at a time, in this order (see each property's own description for the exact question/validation to use): quoteMsgId (should be unique per its field definition; never generate, replace or block a user-confirmed value), rfqId, quoteRespType (must be END_TRADE), securityId, parties (has its own sub-steps). Step 2 — Once all required fields are collected, ask the user: 'All required fields are collected. Would you like to provide any optional fields before submitting the RFQ cancellation? (yes / no)' If YES — go through each of these top-level optional fields one at a time (see each field description for the exact question to ask). Skip any the user declines: side, transactTime, bidId, offerId If NO — proceed immediately to Step 3. IMPORTANT: The parties array collected in Step 1 is already complete. Do NOT re-visit, modify, or strip any fields from it during this step. IMPORTANT: side is optional but, if provided, must match the original RFQ's exact side — never invent it. bidId and offerId relate to accepting a specific quote and are normally not needed for RFQ cancellation — never fabricate them. Step 3 — MANDATORY CONFIRMATION — you MUST always perform this step before calling this tool, with no exceptions: Display a summary of ALL values the user has provided, then ask: 'Please review the details above. Do you confirm the RFQ cancellation request? (yes / no)' If YES — call this tool. If NO — ask the user which field they want to change, update it, then repeat Step 3. NEVER call this tool without receiving explicit confirmation from the user in this step. RESPONSE INTERPRETATION: the response contains a quote_status_report (ACCEPTED/REJECTED) plus a CANCELLED quote_response when accepted — do not claim the RFQ is cancelled merely because this tool was called. After a successful cancel, open MM quotes on that RFQ may expire; both roles must poll get_latest_quote_responses (and get_latest_execution_reports if execution-related) for the resulting events — never rely on this response alone. Use amend_rfq for price-only changes and cancel_quote for a Market Maker's own quotes, not this method.

lse24-cancel_rfq

Used by the RFQ Requestor to retrieve Quote Request Reject messages (successful Market Maker rejections of the Requestor's RFQs) for active RFQs that have not expired. ROLE CONTEXT: User is the RFQ Requestor when it owns/submits the RFQ (submit/amend/cancel it, view quotes or rejects on it, accept a quote, check status). User is a Market Maker (MM) when responding to an RFQ it received. Role is per-RFQ, not permanent — infer from the action when unambiguous, else ASK. TOOL-CALL INTEGRITY: Every answer to a question this tool can address must come from an actual, real-time call to this tool made in the current turn — never answer from memory, assumption, or a plausible-sounding guess without truly invoking it. If the call errors or times out, report that failure verbatim to the user — never substitute a fabricated result (empty, populated, or otherwise) in its place. This is a POLLING method — always call it fresh for 'who rejected/declined my RFQ' style requests; never answer from an earlier result or conversation memory. Not a general RFQ-status method — a rejection is only one lifecycle event; for the overall RFQ status use get_latest_quote_responses and/or get_latest_execution_reports. Does not cover Exchange rejection of the original submit_rfq itself (that outcome is in submit_rfq's own response). Once the associated RFQ reaches a terminal state, previously-cached rejects may no longer be returned — an empty or missing result never proves that no MM ever rejected the RFQ; it only means nothing is currently available through this poll. Requestor-scope only; a Market Maker checks its own reject_rfq outcome from that call's own response, not this one. No traderGroup input is needed.

lse24-get_active_quote_request_rejects

Used by the RFQ Requestor to retrieve Quote snapshots submitted by Market Makers for its RFQs. Only quotes corresponding to active (non-terminal) RFQs are returned; if none are available, an empty result is returned. ROLE CONTEXT: User is the RFQ Requestor when it owns/submits the RFQ (submit/amend/cancel it, view quotes or rejects on it, accept a quote, check status). User is a Market Maker (MM) when responding to an RFQ it received. Role is per-RFQ, not permanent — infer from the action when unambiguous, else ASK. TOOL-CALL INTEGRITY: Every answer to a question this tool can address must come from an actual, real-time call to this tool made in the current turn — never answer from memory, assumption, or a plausible-sounding guess without truly invoking it. If the call errors or times out, report that failure verbatim to the user — never substitute a fabricated result (empty, populated, or otherwise) in its place. This is a POLLING method — always call it fresh on every 'show/refresh my quotes' style request; never answer from an earlier result or conversation memory. Requestor-scope only: a Market Maker asking about the status of its own submitted quote must NOT use this method. CRITICAL: a quote returned here is never, by itself, proof that it (or one side of it) is still live, valid or executable — quote snapshots persist while the parent RFQ is non-terminal even after a later lifecycle/execution event changed that quote's state. Before answering 'is it still active/valid/expired/cancelled/executed', always corroborate with get_latest_quote_responses AND get_latest_execution_reports (quote-expiry events can appear in either). An empty result only means no quote is currently available — it never proves that no MM ever quoted. Use get_active_quote_request_rejects for MM rejections (not returned here). No traderGroup input is needed. Related: precedes accept_quote — fetch a fresh snapshot here, then confirm via the two lifecycle-poll methods that the selected quote/side hasn't changed state, before executing.

lse24-get_active_quotes

Used by a Market Maker (MM) to retrieve incoming RFQs (quote_request messages) targeted to the requesting agent for active RFQs that have not reached a terminal state. ROLE CONTEXT: User is the RFQ Requestor when it owns/submits the RFQ (submit/amend/cancel it, view quotes or rejects on it, accept a quote, check status). User is a Market Maker (MM) when responding to an RFQ it received. Role is per-RFQ, not permanent — infer from the action when unambiguous, else ASK. TOOL-CALL INTEGRITY: Every answer to a question this tool can address must come from an actual, real-time call to this tool made in the current turn — never answer from memory, assumption, or a plausible-sounding guess without truly invoking it. If the call errors or times out, report that failure verbatim to the user — never substitute a fabricated result (empty, populated, or otherwise) in its place. This is a POLLING method — always call it fresh on every 'show/refresh my RFQs' style request; never answer from an earlier result, conversation memory, or an assumption that a previously-seen RFQ is still active. MM-scope only: an RFQ Requestor asking about the status of its own submitted RFQ must NOT use this method — use get_latest_quote_responses and/or get_latest_execution_reports instead. If a previously-seen RFQ is no longer returned, do not guess or invent why (expired, cancelled, traded, timed out) — use get_latest_quote_responses (and get_latest_execution_reports if execution-related) to determine the actual cause. No traderGroup input is needed — the MM identity is derived from the authenticated session. Related: precedes submit_quote (respond with a quote) and reject_rfq (decline) — use the RFQ details from this fresh poll, never stale ones.

lse24-get_active_rfq_requests

Used by either an RFQ Requestor or a Market Maker to retrieve Execution Reports generated by the Exchange targeting the authenticated agent. ROLE CONTEXT: User is the RFQ Requestor when it owns/submits the RFQ (submit/amend/cancel it, view quotes or rejects on it, accept a quote, check status). User is a Market Maker (MM) when responding to an RFQ it received. Role is per-RFQ, not permanent — infer from the action when unambiguous, else ASK. This method is valid for both roles. TOOL-CALL INTEGRITY: Every answer to a question this tool can address must come from an actual, real-time call to this tool made in the current turn — never answer from memory, assumption, or a plausible-sounding guess without truly invoking it. If the call errors or times out, report that failure verbatim to the user — never substitute a fabricated result (empty, populated, or otherwise) in its place. This is a POLLING method — always call it fresh for any execution/trade/fill/partial-fill/executed-qty/execution-price question. Never infer execution from an earlier ACCEPTED ack (submit_rfq, submit_quote, amend/accept) or from silence in conversation. CRITICAL: Execution Reports can also carry Quote-expiry outcomes — e.g. the non-executed side of a dual-sided quote expiring when the other side executes, or the remaining quantity of a partially-filled quote expiring. Do not assume all expiries live only in get_latest_quote_responses; check both. A quote/RFQ may generate multiple reports over its life (e.g. PARTIALLY_FILLED, then an EXPIRED report for the remainder) — evaluate ALL returned reports together, never treat the first one as final. Correlate via rfqId, clOrdId, orderId, execId, side, securityID, etc.; never fabricate a correlation if identifiers don't clearly establish it. For Automatic RFQs, execution is Exchange-initiated — this tool only retrieves the outcome, it never triggers execution (accept_quote is the Requestor-only manual-RFQ execution trigger). An empty result never proves nothing executed or expired — it only means nothing is currently available through this poll. No traderGroup input is needed.

lse24-get_latest_execution_reports

Used by either an RFQ Requestor or a Market Maker to retrieve Quote Response messages (RFQ/Quote lifecycle events: expiry, cancel, timeout, terminate, replace, executable-status, etc.) targeted to the authenticated agent. ROLE CONTEXT: User is the RFQ Requestor when it owns/submits the RFQ (submit/amend/cancel it, view quotes or rejects on it, accept a quote, check status). User is a Market Maker (MM) when responding to an RFQ it received. Role is per-RFQ, not permanent — infer from the action when unambiguous, else ASK. This method is valid for both roles. TOOL-CALL INTEGRITY: Every answer to a question this tool can address must come from an actual, real-time call to this tool made in the current turn — never answer from memory, assumption, or a plausible-sounding guess without truly invoking it. If the call errors or times out, report that failure verbatim to the user — never substitute a fabricated result (empty, populated, or otherwise) in its place. This is a POLLING method — always call it fresh for any 'what's the status / what happened / did it expire or get cancelled' question. Never answer from an old ACCEPTED ack or an old get_active_quotes/get_active_rfq_requests snapshot. CRITICAL: not exhaustive for expiries — some execution-related expiries only appear in get_latest_execution_reports; combine both for a full picture. EXECUTABLE status is never equivalent to executed — confirm an actual trade via get_latest_execution_reports. A Market Maker can receive a termination notice here even for an RFQ it never quoted. Correlate via rfqId, quoteMsgId, bidId, offerId, securityId, side, etc.; when multiple responses exist for the same RFQ/quote, evaluate them together — a later event supersedes an earlier one. The cache holds both active and terminal RFQ responses but is not permanent — an empty result never proves nothing happened, only that nothing is currently available. No traderGroup input is needed.

lse24-get_latest_quote_responses