market-depth-lab-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool has a clearly distinct purpose: snapshot, fee estimation, wallet analysis, positions, top holders, TWAPs, funding rates, and cross-exchange spreads. No overlapping functionality.
Naming Consistency3/5
Most tools follow a verb_noun pattern (e.g., get_hype_market_snapshot, calculate_hyperliquid_fees), but some include the server name as prefix (e.g., hyperliquid_summarize_large_trader_positions), causing minor inconsistency.
Tool Count5/5
9 tools is well-scoped for a market depth lab covering Hyperliquid and cross-exchange analysis. Each tool serves a distinct function without redundancy.
Completeness4/5
The tool set covers major operations: snapshots, fees, wallet, positions, funding, and spreads. Minor gaps like historical data or order book depth are absent but not critical for the stated purpose.
Average 4/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on July 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint false) already disclose safety and idempotence. The description adds behavioral insight beyond annotations by revealing the data source is a subset cohort, not a full snapshot, and that positions are aggregated. This provides meaningful context about output limitations not captured in annotations.
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, no filler, front-loaded with the core action and scope. Every word serves a purpose. The structure is optimal for quick scanning by an AI agent.
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 the complexity of 7 parameters (several with enums) and zero schema descriptions, the description is insufficient for the agent to use the tool correctly. It covers purpose but fails to explain parameter selection, defaults, or how to filter results. The output schema exists but does not offset the lack of input guidance. A 2 reflects the significant missing context for a tool with this many parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter explanations whatsoever. Parameters like sort_by, direction, market_type have enums but no textual hints about their effect. The agent must infer meaning purely from names and enum values, which is insufficient for seven parameters, especially with no defaults described for behavior. This is a critical gap.
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 aggregates long and short exposure by market within a specific cohort (Market Depth Lab's rolling monitored-address cohort). It uses a specific verb ('aggregate') and resource ('exposure by market'), and explicitly distinguishes itself from a protocol-wide holder census, leaving no ambiguity about its scope.
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 negative guidance by stating what the tool does not do (not a protocol-wide census or simultaneous snapshot), helping the agent avoid misuse. However, it does not explicitly recommend when to use this tool over siblings like hyperliquid_list_top_position_holders or provide positive usage context. The clarity of exclusion earns a 4.
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?
Annotations already indicate readOnlyHint, idempotentHint, openWorldHint. The description adds that notional is estimated using live market references and clarifies that execution progress and unfilled quantity are not inferred, providing useful behavioral context.
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 purpose, and a second sentence clarifying limitations. No unnecessary words.
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?
While output schema exists, the lack of parameter documentation makes the tool difficult to use effectively. The agent cannot infer key details like what 'query' filters on or what 'hip3' market type means. Significant gaps for a tool with 7 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of any of the 7 parameters (side, limit, query, offset, sort_by, market_type, min_estimated_notional_usd). The agent has no insight into parameter meanings beyond their names and default 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 lists active Hyperliquid TWAP schedules and estimates notional, distinct from sibling tools which cover snapshots, fees, positions, etc.
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 specifies the tool is for listing publicly visible active TWAPs, implying its use case. It does not explicitly mention when not to use or alternatives, but sibling tools are clearly different in function.
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?
Annotations already declare the tool as read-only, open world, idempotent, and non-destructive. The description adds valuable context about optionally computing exact trailing-24h funding only for the returned page, which involves upstream requests, thus enhancing transparency beyond annotations.
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 consists of two concise sentences: the first clearly states the main purpose, and the second adds an important optional behavior. No redundancy or filler content.
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?
While the description covers the primary data returned and the optional trailing-24h feature, it omits details on sorting, filtering, pagination, and market type filtering. Given the 8-parameter complexity and availability of an output schema, the description is adequate but leaves gaps in parameter semantics.
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?
The input schema has 8 parameters with 0% description coverage. The description only vaguely implies the 'include_trailing_24h' parameter but does not explain 'limit', 'offset', 'sort_by', 'market_type', or other key parameters, leaving the agent to infer from default values and enums alone.
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 it lists current funding rates, open interest, 24h notional, and basis for main-perpetual and HIP-3 markets. It distinguishes itself by mentioning optional trailing-24h computation, setting it apart from siblings which focus on other aspects.
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 usage for listing funding data with optional trailing-24h calculation but does not explicitly state when to use this tool versus alternatives like hyperliquid_summarize_large_trader_positions or scan_cross_exchange_funding_spreads. No exclusion criteria 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?
The description adds behavioral context beyond the annotations (readOnlyHint, openWorldHint, idempotentHint): it notes that rankings are 'cohort-relative' and that the index 'retains only the published top positions per market'. This helps the agent understand limitations.
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 purpose, no fluff or redundant information.
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?
For a tool with 7 parameters and limited schema descriptions, the description covers the core function adequately but lacks details on filtering and sorting options. The presence of an output schema reduces the need to explain return values, but more parameter context would improve completeness.
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 only 14% (only 'market' has a description). The description does not describe any parameters, failing to compensate for the low coverage. Parameters like side, limit, offset, and sort_by are left to be inferred from their names.
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 ('List') and resource ('largest current positions'), scoped to 'one canonical market inside Market Depth Lab's monitored public-address cohort'. This clearly distinguishes it from sibling tools like list_active_hyperliquid_twaps or hyperliquid_list_funding_rates.
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?
No explicit guidance on when to use this tool versus alternatives. The usage is implied by the name and description, but no exclusions or comparative advice 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?
Annotations indicate readOnlyHint, idempotentHint, and non-destructive. The description adds that this is a transparent estimate, not an exchange quote, providing important behavioral context beyond the annotations. No contradiction.
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 concise sentences with all essential information front-loaded. No extraneous text.
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 (10 params, output schema exists), the description provides a high-level overview but lacks details on edge cases, rounding, or assumptions. It is mostly complete for a simple estimate tool.
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 description lists categories of parameters (notional, role, tier, discounts, etc.) but does not detail their meanings or constraints. Schema coverage is only 30%, so the description partially compensates but falls short of fully explaining the 10 parameters.
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 estimates Hyperliquid spot or perpetual trading fees, listing the inputs and distinguishing it from an exchange quote. The verb 'estimate' and resource 'Hyperliquid trading fees' are specific and unambiguous.
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 mentions the tool provides a transparent estimate, not a quote, but does not specify when to use this tool versus alternatives or when not to use it. Sibling tools are unrelated, so no explicit differentiation.
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not conflict. It adds value by disclosing that the tool does not place orders and that its output is not risk-free arbitrage, and it explains the pairing and normalization logic. No contradictions found.
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, containing two well-structured sentences that convey essential information without redundancy or unnecessary detail.
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 moderate complexity (6 parameters, output schema exists) and the presence of sibling tools, the description covers the main workflow and outputs (gross carry, costs, break-even time). However, it does not detail output structure or data freshness, but the output schema presumably fills that gap.
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 coverage is 50% (some parameters have descriptions, some do not). The description clarifies the overall computation (e.g., holding hours relates to break-even time, round_trip_cost_bps is 'user-supplied costs'), but it does not explicitly map to parameters like limit or minimum_annualized_spread_percent. This adds some context but is not fully compensatory.
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 ('compare') and clearly identifies the resource ('perpetual funding on Binance USD-M, OKX and Hyperliquid'). It distinguishes from sibling tools like 'scan_cross_exchange_perp_price_spreads' by focusing on funding spreads rather than price spreads.
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 states what the tool does (compare funding spreads for carry estimation) and explicitly notes what it does not do (place orders, describe as risk-free arbitrage). However, it does not provide explicit when-to-use or when-not-to-use guidance relative to alternative tools, though the sibling list implies differentiation.
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?
Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral context: it is a screening tool that subtracts configurable fees and reports top-of-book capacity, reinforcing its nondestructive, stable nature.
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?
Three sentences, no redundant information. The purpose is stated in the first sentence; additional clarification follows efficiently.
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 tool with 9 parameters and output schema, the description covers core functionality and usage boundaries. It doesn't explain every parameter in depth, but the schema and annotations fill many gaps. Overall adequate for the complexity.
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 coverage is 22%, so description must compensate. Description mentions 'selected symbols', 'taker-fee estimates', 'top-of-book capacity', and 'cross-venue' which maps to some parameters (symbols, fees, limit, venues). However, details like cost_basis, minimum_net_bps, and minimum_top_of_book_notional_usd are not elaborated, leaving gaps.
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 uses specific verbs ('Compare', 'ranks') and resources ('best bid and ask quotes for perpetual symbols on Binance USD-M, OKX and Hyperliquid'). It clearly states the tool's output (ranked cross-venue spreads with fees) and explicitly distinguishes itself from latency-arbitrage or execution tools.
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?
Description defines the tool as a 'persistent-divergence screen' and explicitly states what it is not ('not a latency-arbitrage or order-execution tool'). This gives clear guidance on when to use it. It doesn't mention alternatives but sibling tools (e.g., scan_cross_exchange_funding_spreads) provide 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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds 'live' and specific return fields but lacks additional behavioral context like data freshness or rate limits.
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, no unnecessary words, front-loaded with purpose, and no fluff.
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 zero-parameter tool with output schema and rich annotations, the description covers essential functionality and edge cases (e.g., 'when available') completely.
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?
No parameters exist, so baseline 4 applies. The description mentions conversion direction implicitly, but with zero parameters, no further semantic addition is needed.
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 fetches a live HYPE snapshot from Hyperliquid and converts between HYPE and USD, reporting specific metrics. It distinguishes itself from sibling tools which focus on fees, wallets, positions, etc.
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 quick market snapshots and conversions, and the sibling context makes differentiation easy. However, no explicit when-to-use or 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond annotations by specifying that no authentication is needed and that the tool reads public data. This reinforces the non-destructive, public nature of the operation.
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, well-structured sentence that front-loads the key purpose and then lists what data is included. No extraneous words.
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 existence of an output schema (not shown), the description effectively covers purpose, parameters, and data scope. It does not mention rate limits or pagination, but these are minor gaps for a read-only wallet state 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 schema description coverage at 50% (only 'address' has a schema description), the tool's description compensates by explaining the purpose of the 'recent_fill_limit' parameter implicitly (through listing 'recent fills' in the output) and clarifying that the 'address' must be public and on Hyperliquid. This adds meaning 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 uses a specific verb ('Read') and clearly identifies the resource (public main-account state for a Hyperliquid address). It lists the exact data components (perpetual positions, spot balances, etc.) and distinguishes from sibling tools that focus on market snapshots, fees, or top holders.
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 states this is a read-only operation requiring no private key or wallet connection, which guides appropriate use. However, it does not explicitly mention when not to use this tool (e.g., for historical data) or suggest alternative sibling tools for other tasks.
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:

[![market-depth-lab-mcp MCP server](https://glama.ai/mcp/servers/derkcc/market-depth-lab-mcp/badges/card.svg)](https://glama.ai/mcp/servers/derkcc/market-depth-lab-mcp)

Score Badge

Copy to your README.md:

[![market-depth-lab-mcp MCP server](https://glama.ai/mcp/servers/derkcc/market-depth-lab-mcp/badges/score.svg)](https://glama.ai/mcp/servers/derkcc/market-depth-lab-mcp)

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/derkcc/market-depth-lab-mcp'

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