mac-use

by stevederico

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Each tool serves a distinct purpose: status, screen info, capture, cursor movement, clicking, dragging, typing, key events, and scrolling. There is no overlap in function; even mouse_move and click are clearly separated by action type.
Naming Consistency4/5
Most tools follow a verb_noun pattern like get_screen_size, mouse_move, type_text, but a few are single verbs (click, key, scroll) or nouns (screenshot, mac_use_status). All use consistent snake_case, so the minor deviations are acceptable.
Tool Count5/5
Nine tools is a well-scoped set for GUI automation on macOS, covering the essential input and display actions without redundancy. The count is within the ideal 3-15 range and each tool earns its place.
Completeness4/5
The set provides comprehensive coverage of mouse, keyboard, screen capture, and status checking. Minor gaps include no explicit right-click or double-click, and no clipboard interaction (though type_text covers typing), but these are workable limitations.
Average 3.9/5 across 9 of 9 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses a key behavioral constraint: destructive chords require confirmed=true. However, it omits other behaviors such as how key strings are interpreted, what happens when confirmed=false, and whether modifiers must be specified in any particular order. This is a moderate level of disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, then the key usage constraint. Every word earns its place without redundancy.
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?
Given four parameters, no annotations, and no output schema, the description is insufficient for fully reliable invocation. It lacks critical details like acceptable key string formats, how modifiers combine, and behavior when confirmed is false. The safety note about destructive chords is valuable, but the tool still has major unexplained surface area.
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 0%, so the description must compensate. It adds value by defining the default for direction ('press') and explaining the confirmed flag's necessity for destructive chords. However, it does not clarify the format or expected values for the 'key' parameter, which is the primary input, leaving a significant gap.
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 states that the tool sends a 'Key event to the focused app', clearly indicating it simulates keyboard input. It distinguishes from sibling tools like mouse_move and type_text by focusing on key events, though the verb is implicit rather than explicit.
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?
No explicit guidance is provided on when to use this tool versus alternatives. For example, it does not mention that this should be used for key combinations/shortcuts as opposed to type_text for normal text input. The only instruction is about direction and confirmed for destructive chords, which is parameter-level guidance, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It adds useful behavior context: clicking at specified coordinates, fallback to current cursor when x/y omitted, and coordinate alignment with screenshots. However, it omits behavioral details like default button, click count behavior, or side effects, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence conveys the core action and parameters, and the second clarifies coordinate alignment. Every sentence earns its place; concision is excellent.
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?
The tool has four optional parameters, no annotations, and no output schema. The description provides only x/y behavior and coordinate system context. It does not address button options, click counts, defaults, or potential effects, leaving the tool under-specified for robust use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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. It explains x and y semantics (coordinates and optional omission) but completely ignores 'button' and 'clicks', leaving those parameter meanings to be inferred from the schema alone. This is insufficient for full parameter understanding.
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?
The description states the tool performs a click at screen coordinates or current cursor, with a specific verb ('click') and resource ('screen points'). It also distinguishes from sibling tools like mouse_move and mouse_drag by clarifying the click action and coordinate system.
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?
The description gives no explicit guidance on when to use this tool versus alternatives such as mouse_move, mouse_drag, or scroll. It implies usage through the verb 'click' but does not provide context, exclusions, or mention scenarios where the click tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses dy direction but leaves dx direction undefined, and does not clarify whether the pointer is moved to (x,y) before scrolling or how coordinates are interpreted (screen vs window). This is a significant gap for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and location, no wasted words. Highly efficient.
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?
A simple tool but under-described: dx semantics are missing, coordinate system is ambiguous, and no behavioral details beyond dy direction. Without annotations or output schema, the description should provide more context to be fully usable.
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 0%. The description adds meaning for x and y as coordinates and for dy (dy>0 scrolls down), but dx is only marked optional without explaining its direction or effect. Partial compensation, but incomplete.
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?
Description states a specific action (HID scroll wheel), the target location (x, y), and directional behavior (dy>0 scrolls down). This clearly distinguishes it from sibling tools like mouse_move, click, and mouse_drag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: scroll when you need to wheel-scroll at a position, distinct from moving or clicking. However, no explicit when-to-use or alternative comparisons are provided, so it earns an implied-usage score rather than a stronger one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. The verb 'Report' implies a read-only operation, which is useful, but the description does not disclose whether it performs active checks or merely returns cached status, nor does it specify any side effects or permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to specifying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the agent can expect in the response. It names the categories reported but does not indicate the format (e.g., booleans, versions, strings) or how readiness is represented, leaving some ambiguity for a simple status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema already covers everything. The description needs no parameter detail, and the baseline of 4 applies because there are no parameter semantics to document.
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?
The description uses a specific verb ('Report') and clearly names the resource scope ('platform, Accessibility / Screen Recording, and Mac Use readiness'). It distinguishes itself from the sibling action-oriented tools by announcing itself as a status/readiness check.
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?
No explicit guidance is given for when to use this tool versus alternatives. It is implied that this is a pre-flight check for the screen-control sibling tools, but the description never states that usage context or contrasts it with any other tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it is a left-button HID-level drag and uses screen points, which is useful. However, it does not mention details like coordinate origin, drag speed, whether the button is released at the end, or any side effects beyond the drag itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys the essential action and parameters with no wasted words. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-parameter input tool with no output schema and no annotations, the description is mostly complete: it states the action, the input points, and that coordinates are screen points. It lacks guidance on alternative tools, but the core functionality is well-covered.
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 0%, so the description must compensate. The phrase 'from (fromX, fromY) to (toX, toY)' clearly maps the four parameters to endpoints, but it does not define the coordinate system origin or units beyond 'screen points'. Parameter names are self-explanatory, but deeper semantics are missing.
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?
The description uses a specific verb ('drag') and identifies the exact resource and action: a left-button HID drag from one coordinate to another. It clearly distinguishes from sibling tools like mouse_move or click by specifying the left-button press-and-move behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (whenever a drag action is needed) but does not explicitly state when not to use it or compare it to alternatives like mouse_move or click. It provides no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description fully carries the burden. It discloses the coordinate origin (top-left), movement modes, and the return value (position and display size). However, it omits behavior when no parameters are passed or whether absolute and relative can combine.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main action ('Move the cursor'), containing no filler. Each clause delivers distinct information: movement modes, coordinate origin, and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 4 optional parameters and no output schema, the description covers core semantics (absolute vs. relative, return value) and coordinate origin. It lacks edge cases like multi-display behavior or no-parameter invocation, but is otherwise complete enough for basic use.
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?
The schema has 0% description coverage, so the description must explain parameters. It does clarify that x/y are absolute global points and dx/dy are relative, adding meaning beyond the schema. Still, it leaves out units, precedence, and optionality details.
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?
The description states 'Move the cursor' with a specific verb and resource, and clearly distinguishes absolute (x, y) from relative (dx, dy) movement. This uniquely identifies it among sibling mouse tools like click or mouse_drag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose implies when to use it (when cursor movement is needed), but there is no explicit when-not-to-use guidance or comparison to alternatives like mouse_drag. The absolute/relative distinction hints at parameter choice, but no direct exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses output format (PNG) and a critical behavior (pixels match screen points), which is essential for subsequent clicks. It does not mention side effects or permissions, but for a read-only capture tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no fluff. The critical information (PNG output and coordinate alignment) is front-loaded and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is nearly complete. It explains output format and coordinate mapping, but does not specify whether the PNG is returned as data or a path. Given the low complexity, this minor gap is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific detail, but none is needed. It appropriately implies that no configuration is required.
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?
The description clearly states a specific verb ('Capture') and resource ('main display as PNG'), distinguishing it from sibling tools like mouse_move or click. It also adds a unique detail about pixel-to-screen point mapping, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for visual context and coordinate reference, but does not explicitly contrast with alternatives like get_screen_size. The coordinate-mapping hint provides clear context, and no exclusion criteria are needed given the tool's unique role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the output units (screen points) and coordinate origin (top-left), which are behavioral details beyond the tool name. It doesn't mention any side effects, but for a read-only getter no such disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word adds value. No fluff or repetition.
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 tool with no parameters and no output schema, the description provides all necessary context: what it returns, units, origin, and relationship to sibling tools. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none exists, and the schema is empty. This is appropriate.
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?
The description clearly states the tool returns main display width/height in screen points, using a specific verb ('Return') and resource ('main display'). It also distinguishes itself from sibling tools by noting the coordinate space aligns with screenshot and click, making it uniquely about display dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it doesn't explicitly say 'use when needing coordinate space,' it provides context by stating 'Same space as screenshot and click,' which implies when to use it for coordinating with other tools. No alternatives are mentioned, but for a simple query tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals key traits: operates via HID, types into the focused app, and does not use the clipboard. This is helpful but could go further by noting limitations, such as how keyboard layout or special characters are handled, though for a simple tool it adequately covers the essentials.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences each earning their place. It front-loads the core purpose, then adds essential guidance and a key exception, with zero wasted words.
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 tool with a single parameter, no output schema, and no annotations, the description is sufficiently complete. It covers purpose, prerequisite, behavioral traits (HID, no clipboard), and alternative tool usage. No major gaps remain for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'text' parameter with no description (coverage 0%), so the description must compensate. It does so by stating that the tool 'types unicode' and explicitly mentions 'No clipboard', clarifying that the text is typed directly via HID rather than pasted. This adds meaningful context beyond the bare schema.
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?
The description uses a specific verb and resource: 'Type unicode into the focused app (HID).' It clearly states what the tool does and distinguishes it from the sibling 'key' tool by specifying that shortcuts should use 'key' instead.
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?
The description provides explicit usage guidance: 'Click the field first' instructs the user on the required prerequisite. 'For shortcuts use key' explicitly names an alternative tool and specifies when this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mac-use MCP server](https://glama.ai/mcp/servers/stevederico/mac-use/badges/card.svg)](https://glama.ai/mcp/servers/stevederico/mac-use)

Score Badge

Copy to your README.md:

[![mac-use MCP server](https://glama.ai/mcp/servers/stevederico/mac-use/badges/score.svg)](https://glama.ai/mcp/servers/stevederico/mac-use)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/stevederico/mac-use'

If you have feedback or need assistance with the MCP directory API, please join our Discord server