Skip to main content
Glama
Sign In
netcoredbg-mcp

netcoredbg-mcp

by thebtf
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ui_send_keys_focused

Send keyboard input to the focused UI element after ui_set_focus to avoid repeated searches for complex controls like DataGrid.

Instructions

Send keyboard input to the currently focused element.

Use this AFTER ui_set_focus to avoid re-searching for complex elements like DataGrid that may timeout on repeated searches.

Workflow:

  1. ui_set_focus(automation_id="MyElement") # Focus the element

  2. ui_send_keys_focused(keys="^{END}") # Send keys without re-search

Key syntax (modifiers are PREFIX characters, special keys in braces):

  • ^ = Ctrl, % = Alt, + = Shift

  • Alt+Z: "%z" Ctrl+C: "^c" Shift+Tab: "+{TAB}"

  • Special: {ENTER} {TAB} {ESC} {DELETE} {BACKSPACE}

  • Arrows: {LEFT} {RIGHT} {UP} {DOWN}

  • Navigation: {HOME} {END} {PGUP} {PGDN}

  • Combined: Ctrl+End = "^{END}", Ctrl+Home = "^{HOME}"

  • Physical keypad: {NUMPAD0} ... {NUMPAD9}, {NUMPADADD}, {NUMPADSUBTRACT}, {NUMPADMULTIPLY}, {NUMPADDIVIDE}, {NUMPADDECIMAL}, {NUMPADENTER}, {NUMLOCK} (press/release)

IMPORTANT: For Alt+Z send "%z" (NOT "{ALT}z").

Args: keys: Keys to send (see syntax above)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "keys": "<keys>"
    },
    "name": "ui_send_keys_focused"
  }
}

Input Schema

NameRequiredDescriptionDefault
keysYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.17.2

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare openWorldHint=false, so the description carries most of the burden and does disclose the key behavioral trait: input goes to the already-focused element with no element re-search. It doesn't cover error behavior (e.g. what happens if nothing is focused) or return format, leaving a modest gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the ui_set_focus workflow are front-loaded before the syntax reference. The key-syntax block is long but each line is functional reference material, not filler, so the length is justified despite being dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, no-output-schema tool, the description covers purpose, prerequisite, workflow, and full input syntax. The only untouched area is failure/error semantics, which is minor given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the sole parameter is undocumented in the schema, so the description must compensate — and it does thoroughly, with modifier prefixes, brace syntax for special keys, navigation keys, numpad keys, and a specific Alt+Z counterexample. This is richer than most schemas would provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Send keyboard input to the currently focused element') and the scope qualifier 'focused' implicitly distinguishes it from the element-searching sibling ui_send_keys. The DataGrid timeout rationale makes the distinct role concrete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit numbered workflow requiring ui_set_focus first, and states the condition that makes this tool preferable ('avoid re-searching for complex elements... that may timeout'). An agent knows when to reach for this over ui_send_keys.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools