mcpField
U
ui-context

ui-context

github.com/allthingsidaDevelopment4947 installsUpdated 3w ago
Repository

About ui-context

ui-context is an idasql skill for capturing and interpreting the active IDA interface state. It guides agents to report the current view, selection, and code anchor without inventing missing context.

Key features

  1. 01Capture active UI state
  2. 02Identify view type and title
  3. 03Report selection and preview
  4. 04Extract code address anchors
  5. 05Handle unavailable UI runtime

Use cases

  1. 01Answer what is shown in IDA
  2. 02Describe the current selection
  3. 03Explain a function from the active view

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/allthingsida/idasql-skills --skill ui-context

After installing, type/ui-contextin Claude Code to confirm it loaded.

Bundled filesagents/openai.yaml

Details

From the project README

Primary Query

Use this function to capture active UI state:

SELECT get_ui_context_json();

Capture once per user question, then reuse that snapshot while answering. Capture again only when the user asks to refresh/re-check, or when a new UI-referential question starts.


Trigger Patterns

Use this skill for prompts like:

  • "what am I looking at?"
  • "what is on the screen?"
  • "what's selected?"
  • "look at what I'm doing"
  • references such as "this", "here", "current", "selected", "that", "previous"

Capture Policy

  1. Call get_ui_context_json() before answering UI-referential prompts.
  2. Extract view info: widget type/title and custom-view state.
  3. Extract selection info when present: begin/end and preview text lines.
  4. Extract code anchor info when present: address, function, segment.
  5. If has_address: false, explain limits and do not invent code context.

Widget Fields (focused_widget / main_viewer)

  • type_id (int): raw IDA twidget_type_t numeric id.
  • type_name (string): the SDK macro name for the widget on the building SDK (for example "BWN_PSEUDOCODE", "BWN_TILIST"). The name at SDK slot 10 differs by IDA version (BWN_TILVIEW / BWN_TICSR / BWN_TITREE).
  • canonical_name (string): a stable cross-version name. For the "Local Types" widget (slot 10) this always reads "BWN_LOCAL_TYPES"; for every other widget it equals type_name. Prefer this for cross-version reasoning.
  • category (string): high-level grouping — one of disassembly, decompiler, hex_view, type_view, chooser, debugger, navigation, output, script, auxiliary, unknown.
  • is_address (bool): widget exposes a meaningful address anchor (true for DISASM, HEXVIEW, PSEUDOCODE, MICROCODE).
  • is_custom_view (bool): viewer-style widget with custom line content.
  • is_chooser_like (bool): row-based list/chooser widget where row selection is meaningful.
  • title (string): the widget's title as IDA reports it.

main_viewer carries the same widget fields except is_chooser_like (the main viewer is always a viewer, not a chooser).


Temporal Reference Rules

  • this / here / current / selected: capture a fresh snapshot for this question.
  • that / previous / earlier: reuse the most recent snapshot in the same working flow.
  • If the user says "refresh", capture a new snapshot immediately.

Runtime Availability and Fallback

  • get_ui_context_json() is registered in every runtime, but only the IDA GUI plugin returns live UI state.
  • The live GUI envelope carries available:true; the idalib/CLI stub carries available:false / capture.source:"cli" (no error, just no UI). So available is the reliable GUI-vs-CLI discriminator in both directions — key on it.
  • When you get the CLI stub, state this clearly and continue with non-UI queries (explicit addresses/symbols, or DB-orientation queries).

binary is database metadata only; it is not a UI context replacement.


Response Template

Use this fixed shape after reading UI context:

  • What You Are Viewing: widget/view summary.
  • What Is Selected: selection range and preview (or "no active selection").
  • Code Context: address/function/segment if available; otherwise mention non-address view.
  • Limits: runtime constraints or missing fields affecting certainty.
  • Suggested Next Query: one concrete follow-up command/query.

Examples

1) "What am I looking at?"
SELECT get_ui_context_json();

Answer with the template fields above. Include focused widget title/type and current anchor address if present.

2) "Look at what I'm doing"
SELECT get_ui_context_json();

Summarize active view and selection first, then propose the next action tied to that context (for example, decompile current function).

3) "What's selected right now?"
SELECT get_ui_context_json();

Prioritize selection begin/end and preview text. Explicitly state when there is no active selection.

4) "Explain this function"
  1. Capture UI context.
  2. If function/address context exists, pivot to decompiler.
SELECT get_ui_context_json();
SELECT decompile(0x401000);

Replace 0x401000 with the captured function/address anchor.

5) Follow-up: "What about that function?"

Reuse the most recent snapshot from the same flow (do not auto-refresh unless asked), then continue analysis from that stored anchor.

6) Non-address view (for example Local Types chooser)
SELECT get_ui_context_json();

If has_address: false, report chooser selection details and state there is no code address anchor in this view.

7) Plugin API unavailable (CLI/idalib)

If get_ui_context_json() cannot run:

  • state that UI context is unavailable in this runtime
  • ask for explicit symbol/address or continue with non-UI alternatives (for example SELECT * FROM binary for DB orientation)

Guardrails

  • Do not treat binary output as UI context.
  • Do not fabricate selection/address fields when absent.
  • Do not recapture repeatedly in one answer unless user asks for refresh.

Comments

Markdown supported