hypruse

by IlyasKhallouki

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.9.4
Disambiguation4/5
Most tools have clearly distinct purposes, but there is overlap between screenshot, zoom, and marks for visual capture. The missing use_bind tool (referenced in binds) may cause confusion. Overall, nearly all tools are well-differentiated.
Naming Consistency5/5
All tool names are single lowercase words (desktop, binds, screenshot, etc.) with no mixing of conventions. The naming pattern is simple and fully consistent.
Tool Count5/5
9 tools is well-scoped for a desktop automation server, covering state observation, input, and sequencing without being overwhelming.
Completeness2/5
Several critical tools are missing but referenced (hypr, use_bind), and there is no explicit tool for common desktop actions like focusing a window or sending compositor commands. This creates dead ends and likely agent failures.
Average 4.4/5 across 9 of 9 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 141 commits in the last 12 weeks
- Last stable release on July 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description does a good job disclosing key behaviors: size clamping, window constraint, stable waiting, lossless PNG, and coordinate transformation. However, it omits potential side effects or requirements like permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat dense and technical, mixing procedural steps with parameter details. It is front-loaded with purpose but could be more structured (e.g., bullet points) for clarity.
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?
Given the availability of an output schema, the description covers workflow and parameter behavior well. It lacks error handling or prerequisites but is adequate for a visual interaction 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?
With 0% schema coverage, the description adds significant meaning to all parameters: explains 'size' format and clamping, 'window' as address, 'stable' for frame settling, and 'lossless' for format. x/y are implied but not explicitly described, leaving minor ambiguity.
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's role as 'Native-resolution re-capture around a point: the precision step of the coarse-to-fine loop.' It explains the workflow (screenshot, estimate, zoom, re-estimate, click) and distinguishes from sibling tools like 'screenshot' by focusing on refinement.
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 implies usage within a coarse-to-fine loop but does not explicitly state when to use this tool versus alternatives like 'screenshot' or 'desktop'. No 'when-not-to-use' guidance is 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 full burden. It details what is included (windows, layers, cursor) and what is not (launchers, bars as windows), and mentions best-effort geometry. It does not explicitly state read-only behavior but the snapshot nature implies non-destructive operation.
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?
The description is a single dense sentence that efficiently packs a lot of information. It could be better structured but is not overly long or verbose, earning its content.
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?
Given the presence of an output schema (not shown), the description covers key elements: content, coordinate system, special surfaces, and usage order. It could mention limits or error scenarios, but is sufficiently complete for a snapshot 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 input schema is empty (0 parameters, 100% coverage). Following the baseline guideline for zero parameters, the description adds no parameter details, which 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 a semantic desktop snapshot including monitors, workspaces, windows with coordinates, active window, cursor, and layer-shell surfaces. It distinguishes from sibling tools like screenshot (captures image) and pointer (cursor control) by providing coordinate information for later actions.
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 explicitly advises 'Call first; act on the addresses it returns,' establishing clear usage order. While it does not list when not to use or exhaustive alternatives, the instruction implies it is the initial step for tools that require addresses.
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 provided, so description carries full burden. It discloses coordinate system, action behaviors, 'then' chaining, and auth override. However, it lacks explicit information on error handling or side effects like destructive actions.
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?
Description is a single dense paragraph that front-loads the core concept. It covers actions and special parameters efficiently. Could be more structured (e.g., list actions), but remains clear and concise.
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?
Tool has 11 parameters and an output schema (not shown). Description covers key actions and special parameters well. However, it does not fully explain parameter combinations or error handling, leaving some gaps for complex use cases.
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?
Schema coverage is 0%, but description explains parameters for each action (e.g., x,y for move, button for click). It adds meaning beyond schema titles, though scroll_dx is omitted. Overall, it compensates well for missing schema descriptions.
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 is for mouse operations in global coordinates, lists all actions (move, click, drag, scroll), and explains special parameters like 'then' and 'allow_auth'. It distinguishes itself from sibling tools like keyboard or desktop.
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 mouse input and provides context like coordinate system and action options. It mentions 'allow_auth' for authentication dialogs but does not explicitly contrast with alternative tools or specify when not to use.
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. It discloses the tool's output (combo, action, arg, description) and notes that synthetic keys from keyboard cannot trigger these compositor-specific binds. No destructive behavior is implied.
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?
The description is two sentences, front-loaded with the return value and purpose. It is clear and to the point, though the second sentence could be slightly reworded for brevity.
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?
Given zero parameters and no annotations, the description sufficiently covers the tool's purpose, output, and usage context. It is complete for a simple listing 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 baseline is 4. The description does not need to add parameter info.
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 what the tool does: it provides the user's own Hyprland keybinds (combo, action, arg, description). It also explains its role in the workflow and distinguishes it from sibling tools like keyboard and use_bind.
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 explicitly tells the agent to use `use_bind` with the combo to perform a workflow and warns against using the `keyboard` tool to trigger these binds. It provides clear guidance on when to use this tool (to get binds) and what to do next.
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 full burden. It discloses the capture behavior, reliance on accessibility tree, fallback to plain legend when ImageMagick is absent, and a note when no tree exists. It does not mention destructive actions, rate limits, or authentication, but these are not critical for a read-like capture tool.
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?
The description is moderately long but all sentences serve a purpose: core functionality, usage advice, fallback conditions. It is front-loaded with the primary action. Minor redundancy (e.g., 'Falls back...') could be more concise, but overall well-structured.
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?
Given the complexity of fallbacks (ImageMagick, no tree) and the presence of an output schema (return values not needing further explanation), the description covers all necessary context: parameters, output (JSON legend), and use case. It references sibling tools appropriately.
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?
With 0% schema description coverage, the description adds meaning: `window` is 'an address from desktop (default: focused)' and `name` 'filters the marked controls'. It does not specify the exact format of the window address, but provides enough context for the agent to use parameters correctly.
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 that the tool captures a screenshot with numbered red marks and a JSON legend mapping each mark to control details. It uses the specific verb 'capture' and resource 'Set-of-Marks', and distinguishes from siblings like 'screenshot' and 'ui' by highlighting marks and legend.
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 explicitly advises when to use the tool: to replace the 'estimate-zoom-estimate loop' for controls in the accessibility tree. It provides follow-up actions (using `click_ui(mark=N)` or `pointer`), and specifies fallbacks for missing ImageMagick or no accessibility tree, with an alternative (screenshot + zoom).
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 full burden. It discloses important behaviors: the tree may not be available for certain apps, password fields never report contents, dropdowns may lack value, and click points are global requiring window focus. It also mentions that the tool returns elements with roles, names, and click points. The description does not contradict annotations (none provided).
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?
The description is detailed and well-structured, front-loading the main purpose. Each sentence adds value, though it is slightly long. There is no redundancy, and the technical details are clearly presented. It could be slightly more concise, but overall it is effective.
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?
Given the tool's complexity (accessibility tree with varying behavior), the description is remarkably complete. It explains limitations, fallback strategies, return format, and exceptions. It covers all aspects needed for correct invocation, including implicit output schema description. No output schema is provided, but the description compensates with clear return structure.
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 description must compensate. It thoroughly explains all three parameters: 'window' (address from desktop, default focused), 'name' (filters by accessible name, case-insensitive), and 'actionable' (default true, keeps interactive roles). It also describes the return structure, adding significant value beyond the input 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?
Description clearly states it reads the accessibility tree and returns elements with click points, distinguishing it from sibling tools like screenshot (visual fallback) and pointer (clicking). It specifies the action 'Read a window's accessibility tree' and the resource 'elements...with GLOBAL click points'.
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 provides clear guidance on when to use the tool (to target a control by name without screenshot or pixel guessing), and when to fall back (when the tree is not exposed, like in terminals or Electron/Chrome). It also mentions limitations (password fields, dropdowns) and suggests alternatives (click_ui, screenshot). However, it does not explicitly state when NOT to use this tool versus specific siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears full burden. It thoroughly explains the stop_on_change behavior, detailing what structural changes are detected and what are not (e.g., notification popups, bare focus changes). It also specifies limits (20 steps, 30 seconds) and the `then` parameter's role. This provides excellent transparency.
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 concise yet comprehensive. It front-loads the core purpose, then logically explains behavior, parameters, and constraints. Every sentence adds value without redundancy, making it easy to digest.
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?
Given the tool's complexity and the presence of an output schema (not shown), the description is largely complete. It covers step structure, stop logic, and the then parameter. Minor omissions like return value details are likely covered by the output schema, keeping completeness high.
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?
Schema coverage is 0%, so description must compensate. It explains the structure of the steps array (objects with op and args) and the effects of stop_on_change and then. While it does not list every allowed op or argument detail, it references sibling tool args, which adds significant value beyond the raw 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 explicitly states the tool's purpose: 'Run an ordered list of actions in ONE call' with a concrete example of a micro-sequence. It clearly distinguishes from sibling tools like pointer, keyboard, etc. by combining multiple actions into a single round-trip.
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 indicates when to use (multi-step sequences) and contrasts with individual tool calls. However, it does not explicitly state when NOT to use or provide direct comparisons to alternatives, though the context implies that single actions should use the respective individual tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: default JPEG, lossless PNG option, stable wait up to 2s, scale downscale, and metadata details. Contradicts no 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?
Single paragraph, front-loads main verb and resource. Slightly dense with multiple details but no wasted words. Could be split for clarity.
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?
Covers input parameters comprehensively, mentions output format (image/path + JSON metadata), and provides usage advice. Output schema exists, so return details are not needed.
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 coverage is 0%, but description explains all 5 parameters: window, region, scale, stable, lossless. Each parameter's purpose and effect are clearly described beyond the 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 clearly states the tool captures a monitor, window, or region, and specifies output format. It distinguishes from siblings like 'zoom' by mentioning its purpose after screenshot.
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?
Provides context on when to use 'window' (cheapest for reading one app) and advises to follow with 'zoom' for clicking small controls. Lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: unicode-safe typing, key aliases, window focusing for reliability, that it does not trigger Hyprland binds, and the allow_auth override. This covers safety and operational traits comprehensively.
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?
Despite length, every sentence is essential and packed with information. The description is well-structured, front-loaded with core purpose, uses clear formatting (vertical bars, examples). No redundancy.
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?
Covers all parameters and usage guidelines thoroughly. Does not describe the output schema or error behavior, but given the tool's nature and existence of output schema, this is a minor gap. Overall, it provides sufficient context for effective use.
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?
With 0% schema coverage, the description compensates fully by explaining each parameter: action values ('type'/'key'), keys format and aliases, text, window, then options, and allow_auth boolean with behavioral implications. Provides examples and valid values.
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 sends keystrokes to the focused app, with actions 'type' or 'key', and can target a specific window. It differentiates from sibling tools (use_bind, hypr) for Hyprland-specific actions, establishing a distinct purpose.
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?
Explicitly explains when to use this tool (for application shortcuts) and when not to (Hyprland binds, workspace actions), directing to siblings use_bind and hypr. Also notes special case of allow_auth for password fields.
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:

[![hypruse MCP server](https://glama.ai/mcp/servers/IlyasKhallouki/hypruse/badges/card.svg)](https://glama.ai/mcp/servers/IlyasKhallouki/hypruse)

Score Badge

Copy to your README.md:

[![hypruse MCP server](https://glama.ai/mcp/servers/IlyasKhallouki/hypruse/badges/score.svg)](https://glama.ai/mcp/servers/IlyasKhallouki/hypruse)

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/IlyasKhallouki/hypruse'

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