Skip to main content
Glama
Sign In
Raycast MCP Server

Raycast MCP Server

by ExpertVagabond
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

raycast_open

Open Raycast commands or extensions from your AI assistant to access clipboard history, emoji, calculator, and other tools quickly.

Instructions

Open specific Raycast commands or extensions

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "raycast_open"
  }
}

Input Schema

NameRequiredDescriptionDefault
argsNoAdditional arguments for the command
commandNoRaycast command to open (e.g., "clipboard-history", "emoji", "calculator")
extensionNoExtension name to open

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about side effects (does it launch the Raycast app? steal focus?), failure behavior for unknown commands, or whether an extension must be installed first. For an action tool with zero annotation coverage this is a significant 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?

A single short sentence with the core verb and resource front-loaded; there is no filler. It is arguably too terse for the tool's ambiguity, but that is a completeness issue rather than a structural one.

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

Completeness2/5

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

With three optional parameters, no output schema, and no annotations, the description should explain how command, extension, and args relate (mutually exclusive? combined?) and what happens by default. None of that is covered, leaving the agent unable to call it confidently in edge cases.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters (args, command, extension) are already documented in the schema with examples. The description adds no meaning beyond that, so the baseline 3 applies — it neither compensates nor detracts.

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

Purpose4/5

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

The description names a specific verb ('Open') and a concrete resource ('Raycast commands or extensions'), so the core action is unambiguous. However, it offers no differentiation from siblings like raycast_search or raycast_extensions, leaving the agent to guess whether 'open' and 'search' overlap.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus raycast_search or raycast_extensions, both of which plausibly share its territory. No prerequisites, no mention of whether the target command or extension must already exist.

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