Skip to main content
Glama
pironjulien

NexusWindows for Antigravity

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

launch

Destructive

Opens applications, folders, documents, or Windows Settings pages like a double-click, reads back the result, and passes arguments to executables without taking the user's foreground.

Instructions

Open an application (name such as "notepad.exe", or path), a folder or a document, like a double-click; the opening is read back. Settings page: app="ms-settings:display" (opened behind the user's window, read back). Refused: web addresses http, https, ftp (web pages: nexus-browser). args: arguments of a .exe program (a file to open…), never for a document, a folder or an address; also accepted after the program in app, a path with spaces is never split. Chromium/Electron apps: files only, never a switch. Example: {"app": "notepad.exe", "args": "C:\Dev\notes.txt"}

Input Schema

NameRequiredDescriptionDefault
appYes
argsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.6.0
    • addedInput schema / properties / args
      Added value: +{
+  "default": "",
+  "title": "Args",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Adds substantial context beyond annotations: the opening is read back, settings pages open behind the user's window, web URLs are refused, paths with spaces are not split, and Chromium/Electron apps accept files only. These constraints materially affect invocation and are not covered by the annotations.

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?

Front-loaded and dense with useful constraints, with a concrete example. However, the phrasing is compressed and somewhat run-on, making it slower to parse than ideal.

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?

No output schema exists, but the description explains the read-back behavior. It covers the main invocation modes, exclusions, argument semantics, special settings behavior, and app-specific restrictions, leaving little an agent would need to infer.

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%, so the description must compensate, and it does: `app` accepts executable names, paths, or protocol URIs, while `args` is restricted to .exe arguments, never documents/folders/addresses, and can also follow the program inside `app`.

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: opens an application, folder, or document like a double-click. It also clearly distinguishes the tool from web-opening alternatives by explicitly refusing http/https/ftp and pointing to nexus-browser.

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?

Provides explicit when-to-use examples, including a settings URI case, and explicit exclusions for web addresses. It also gives detailed guidance on when to use `args` and when not to, plus Chromium/Electron restrictions.

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