mockd

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.7.1
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists: get_mock_invocations and get_request_logs both retrieve request/response data, though they differ in scope (specific mock vs. general logs). Tools like manage_mock and manage_state cover different aspects (mock endpoints vs. stateful resources), but the 'manage_' prefix groups them in a way that could cause initial confusion. Overall, descriptions help clarify boundaries, but the set isn't perfectly distinct.
Naming Consistency4/5
Naming follows a mostly consistent verb_noun pattern (e.g., clear_request_logs, export_mocks, get_chaos_config), with a few deviations like manage_mock and manage_state that use 'manage_' as a prefix for multi-action tools. The pattern is readable and predictable, though not perfectly uniform across all tools.
Tool Count5/5
With 18 tools, the count is well-scoped for a mock server that handles mocks, chaos injection, stateful resources, and verification. Each tool serves a clear purpose in this domain, such as managing mocks, configuring chaos, or tracking invocations, without feeling excessive or thin.
Completeness5/5
The tool set provides comprehensive coverage for a mock server domain, including CRUD operations for mocks and stateful resources, chaos configuration and monitoring, verification, logging, and workspace management. There are no obvious gaps; tools like import_mocks and export_mocks handle configuration lifecycle, while manage_custom_operation and manage_context add flexibility.
Average 4.3/5 across 18 of 18 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 8 of 11 community issues answered or closed in the last 6 months
- 12 commits in the last 12 weeks
- Last stable release on June 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that operations are 'stateful' and describes actions, but fails to cover critical aspects like permissions required, whether changes are reversible, rate limits, error handling, or what the response looks like. For a multi-action tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 efficiently structured in a single sentence that lists all actions and their purposes, with no wasted words. It is front-loaded with the main purpose and follows with specific actions, making it easy to scan. However, it could be slightly improved by breaking into bullet points for even clearer readability.
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?
Given the tool's complexity (multiple actions, stateful resources) and lack of annotations or output schema, the description is moderately complete. It covers the basic purpose and actions but misses details on behavioral traits, return values, and differentiation from siblings. It is adequate as a starting point but requires additional context for effective 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?
Schema description coverage is 100%, so the schema already documents all parameters (action, definition, input, name) with descriptions. The description adds some context by linking actions to parameters (e.g., 'register' requires definition, 'execute' uses input), but does not provide additional meaning beyond what the schema specifies, such as format details or examples. Baseline 3 is appropriate when the schema handles most of the documentation.
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 clearly states the tool's purpose as managing custom operations on stateful resources, specifying the five available actions (list, get, register, delete, execute). It uses specific verbs and identifies the resource (stateful resources), but does not explicitly differentiate from sibling tools like manage_state or manage_workspace, which might handle similar resources.
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 provides implied usage by listing the actions and their purposes (e.g., 'register' to create, 'execute' to run with input data), giving some context for when to use each action. However, it lacks explicit guidance on when to choose this tool over alternatives like manage_state or manage_workspace, and does not mention prerequisites or exclusions.
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 full burden. It explains that workspaces isolate mock configurations and that switching routes subsequent operations. However, it lacks details on side effects, permissions, or what the 'list' action returns. Basic transparency but significant gaps.
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 concise with two sentences plus a third listing uses. It front-loads the main purpose. While it could be more structured (e.g., separate sections for actions), it is not verbose and 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?
Despite having 3 parameters and no output schema, the description does not explain what the 'list' action returns, lacks an example, and omits the 'create' action. Error cases and output format are not mentioned, leaving significant gaps for an agent to use the tool correctly.
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 100%, so baseline is 3. The description adds context about workspaces isolating configurations and the actions' purposes, but does not add meaning beyond the schema's parameter descriptions, which already specify requirements for each action.
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 clearly states the tool lists or switches workspaces and explains that workspaces isolate mock configurations. It covers the 'list' and 'switch' actions explicitly, but omits the 'create' action that is present in the schema, making the purpose slightly incomplete.
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 provides specific guidance for using 'list' and 'switch' actions, but does not address when to use this tool versus sibling tools, nor does it mention the 'create' action or when not to use this tool. The guidance is adequate but not comprehensive.
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 must disclose all behavioral traits. It mentions persistence and lists destructive actions (reset, delete_resource), but lacks details on side effects, authorization, idempotency, or error handling, which are important for safe invocation.
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 front-loaded with a clear summary, followed by a bulleted action list and well-structured JSON examples. It is somewhat lengthy but efficient given the tool's complexity.
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 all actions and gives examples, it lacks output descriptions for each action (no output schema provided), and does not address error handling, edge cases, or data limits, leaving some gaps for a tool of this complexity.
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 description adds significant value beyond the already comprehensive schema by providing concrete examples for each action, illustrating parameter usage, relationships, and transformations, which helps agents understand how parameters combine.
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 'Manage stateful mock resources — CRUD collections that persist data across requests,' uses specific verb 'manage' with resource 'stateful mock resources,' and distinguishes from siblings like manage_mock and manage_workspace by focusing on stateful persistence.
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 implicitly indicates when to use this tool (for CRUD on stateful mock resources) and provides examples for each action, but does not explicitly state exclusions or direct comparisons to alternatives, leaving some ambiguity.
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 read-only and idempotent behavior, but the description adds valuable context beyond this: it specifies that the export includes 'all current mocks' and returns 'the full mock collection,' clarifying scope. It doesn't mention rate limits, authentication needs, or side effects, but with annotations covering safety, this provides sufficient behavioral insight.
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 followed by usage context. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse.
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 low complexity (one optional parameter, no output schema), the description is complete enough: it covers purpose, output format, and use cases. However, it could slightly improve by hinting at the output structure (e.g., 'collection' implies a list or object) or linking to sibling tools like 'import_mocks' for round-trip workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'format' fully documented in the schema (including default, enum values, and description). The description mentions 'YAML or JSON' but doesn't add meaning beyond what the schema provides, such as format implications or usage tips, so it meets the baseline for high schema coverage.
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 specific action ('Export'), resource ('all current mocks'), and output format ('as YAML or JSON configuration'). It distinguishes from siblings like 'import_mocks' (which imports rather than exports) and 'manage_mock' (which manages individual mocks rather than exporting all).
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 context for when to use this tool ('for backup, sharing, or version control'), which helps guide usage. However, it doesn't explicitly state when not to use it or mention specific alternatives among siblings (e.g., 'get_mock_invocations' for invocation data instead of configuration).
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?
The description adds context about the key format and discovery method, which is useful beyond the idempotentHint annotation. However, it does not disclose other behavioral traits like potential side effects, error conditions, or response format. With annotations covering idempotency, the description provides moderate additional value.
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 zero waste: the first states the purpose and key format, and the second provides usage guidance. It is front-loaded with essential information and efficiently 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 tool's moderate complexity (2 required parameters, idempotentHint annotation, no output schema), the description is mostly complete. It covers purpose, usage, and key semantics, but lacks details on behavioral outcomes or error handling, which could be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds minimal semantics by explaining the key format with an example ('e.g., "0:0"') and linking to get_stateful_faults for key discovery, but does not provide extra details beyond what the schema offers.
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 specific action ('manually trip or reset'), the resource ('a chaos circuit breaker'), and the mechanism ('by its state key'). It distinguishes from siblings by specifying the unique format of circuit breaker keys and referencing get_stateful_faults for discovery, making it unambiguous.
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?
It explicitly states when to use this tool ('to manually trip or reset a chaos circuit breaker') and provides a clear alternative ('Use get_stateful_faults to discover active circuit breaker keys'), ensuring the agent knows both the primary use case and how to obtain necessary inputs.
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 valuable behavioral context beyond the idempotentHint annotation. It explains that 'enabled=false' disables all chaos, describes the distinction between simple and advanced fault types, and mentions pre-built profile options. While it doesn't cover rate limits, authentication needs, or side effects, it provides meaningful operational guidance that the annotation alone doesn't convey.
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 efficiently structured in three sentences that each earn their place: first establishes the core purpose, second distinguishes simple vs. advanced usage, third covers disabling and pre-built alternatives. No wasted words, front-loaded with the main function, and appropriately sized for a complex configuration tool.
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 (9 parameters, advanced fault types) and the absence of an output schema, the description provides good contextual coverage. It explains the tool's scope, different usage modes, and key behavioral aspects. However, it doesn't describe what happens after configuration (e.g., whether changes take effect immediately, what the response looks like, or error conditions), which would be helpful for a mutation tool with no output schema.
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?
With 100% schema description coverage, the schema already documents all 9 parameters thoroughly. The description adds some semantic context by grouping parameters into 'simple chaos' (latency ranges, error rates, bandwidth) and 'advanced stateful faults' (raw rules with specific fault types), and mentions the profile parameter's purpose. However, it doesn't provide additional syntax, format, or constraint details beyond what the schema already specifies.
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 purpose: 'Configure chaos fault injection rules.' It specifies both simple chaos (latency, error rates, bandwidth throttling) and advanced stateful faults (circuit_breaker, retry_after, etc.), distinguishing it from sibling tools like 'get_chaos_config' (which reads config) and 'reset_chaos_stats' (which resets statistics).
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 context for when to use this tool: for configuring chaos injection, with guidance on simple vs. advanced usage and disabling chaos. It explicitly mentions an alternative: 'For pre-built configurations, use named profiles...' However, it doesn't specify when NOT to use this tool versus other sibling tools like 'manage_circuit_breaker' or 'manage_stateful_faults' that might overlap in functionality.
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 read-only and idempotent operations, which the description aligns with by describing a checking/assertion function. The description adds valuable behavioral context: it specifies the return format ('pass/fail status, actual call count, and invocation details') and explains the optional assertion parameters ('at_least, or at_most'), which are not covered by 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 is front-loaded with the core purpose in the first sentence, followed by return details and usage guidance. Each sentence adds value: the first defines the tool, the second specifies outputs, and the third provides context. There is no wasted 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 moderate complexity (verification with optional parameters), annotations cover safety (read-only, idempotent), and the description explains purpose, returns, and usage. However, there is no output schema, so the description partially compensates by mentioning return details, but it could be more explicit about output structure (e.g., format of 'invocation details').
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 input schema has 100% description coverage, so the schema already documents all parameters well. The description adds minimal semantics by mentioning 'Optionally assert with expected_count, at_least, or at_most parameters,' which reinforces but does not significantly expand beyond the schema. This meets the baseline for high schema coverage.
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 purpose: 'Check whether a mock was called the expected number of times.' It specifies the verb ('Check'), resource ('mock'), and scope ('expected number of times'), distinguishing it from sibling tools like 'get_mock_invocations' (which likely lists calls) or 'reset_verification' (which resets counts).
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 usage context: 'Use this to assert your application is making the right API calls.' It implies this tool is for verification/assertion purposes, but it does not explicitly state when not to use it or name alternatives (e.g., 'get_mock_invocations' for non-assertive checking).
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 must cover behavioral traits. It mentions dryRun preview and replace parameter, but does not fully disclose default behavior (e.g., merging by default), authentication needs, or side effects. Partial but not comprehensive.
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?
Four sentences efficiently convey purpose, supported formats, usage tips, and parameter hints. No unnecessary content, 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 no output schema, the description covers key aspects: input methods, formats, dryRun, and replace. It lacks details on return values or error handling but is fairly complete for an import tool.
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 100% and the description adds value beyond schema by explaining format auto-detection, dryRun for preview, and file for large specs. All parameters are well-addressed.
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 'Import mocks from inline content or a file on the mockd server's filesystem' and lists supported formats. It distinguishes from sibling tools like export_mocks and manage_mock by focusing on import functionality.
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 explicit guidance on when to use dryRun and file parameters, and notes format auto-detection. However, it does not explicitly state when not to use this tool or mention alternatives like manage_mock for individual mocks.
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 provided, the description carries the full burden of behavioral disclosure. It explains the two operations and their effects, but doesn't mention permission requirements, whether changes persist across sessions, error conditions, or what 'mockd server' represents. It provides basic operational context but lacks deeper behavioral details.
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 perfectly concise with two sentences that directly explain the tool's functionality. The first sentence states the overall purpose, and the second explains the two action modes. Every word serves a clear purpose with no redundancy.
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 no annotations and no output schema, the description provides adequate operational guidance but lacks important context. It doesn't explain what a 'context' represents, what 'mockd server' is, whether switching affects other operations, or what format the 'get' output returns. The description covers basic usage but leaves significant gaps.
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 description adds meaningful context about parameter usage: it explains that 'get' shows current and available contexts, while 'switch' requires a name parameter to change servers. With 100% schema description coverage, this supplemental guidance elevates the score above the baseline of 3.
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 purpose with specific verbs ('view' and 'switch') and resource ('active admin server context'). It distinguishes this from sibling tools by focusing on context management rather than mock management, logging, or chaos configuration.
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 guidance on when to use each action: 'get' to see current and available contexts, and 'switch' to change the mockd server. It clearly differentiates the two modes of operation without needing to reference sibling tools.
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 read-only and idempotent operations, which the description aligns with by implying safe retrieval. It adds value by specifying the tool's purpose for debugging and the types of data returned (request/response pairs), though it doesn't detail behavioral aspects like rate limits or pagination beyond the default limit in the schema.
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 front-loaded with the core purpose in the first sentence, followed by a usage guideline. Both sentences are essential—the first defines the tool's function, and the second provides context—with no wasted words, making it highly efficient.
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 (2 parameters, no output schema), annotations cover safety (read-only, idempotent), and the description explains purpose and usage. However, it lacks details on output format or error handling, which could be useful since there's no output schema, leaving minor gaps in completeness.
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?
With 100% schema description coverage, the input schema fully documents parameters (id and limit). The description does not add semantic details beyond the schema, such as explaining mock ID formats or limit implications, so it meets the baseline for high schema coverage without extra value.
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 specific action ('List all recorded invocations') and resource ('for a specific mock'), detailing what data is returned (method, path, headers, body, timestamp). It distinguishes from sibling tools like 'get_request_logs' by focusing on mock-specific invocations rather than general request logs.
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?
It explicitly states when to use this tool ('Use this to debug what requests actually hit a mock'), providing clear context for its application. This distinguishes it from alternatives like 'get_request_logs' or 'verify_mock' by specifying its debugging purpose for mock invocations.
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 idempotentHint=true, indicating safe, repeatable read operations. The description adds valuable context beyond this by mentioning 'captured' logs and the verification purpose, which helps the agent understand the tool's role in mock server testing. No contradictions with annotations exist.
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 zero waste: the first sentence states the purpose and key filtering options, and the second provides clear usage guidance. It's front-loaded with essential information and efficiently 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 tool's complexity (7 parameters, no output schema) and rich annotations (readOnlyHint, idempotentHint), the description is largely complete. It covers purpose, filtering, and usage context. However, it doesn't mention pagination behavior (implied by 'limit' and 'offset' parameters) or the 'unmatchedOnly' feature's near-miss analysis, which could be helpful for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema itself. The description mentions filtering by 'method, path, mock ID, or protocol,' which aligns with parameters like 'method,' 'pathPrefix,' 'mockId,' and 'protocol,' but doesn't add significant semantic detail beyond what the schema provides. The baseline score of 3 is appropriate given the comprehensive 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's purpose with specific verbs ('retrieve captured request/response logs') and resources ('logs'), and distinguishes it from siblings by specifying its filtering capabilities. It explicitly mentions verifying expected API calls to the mock server, which differentiates it from tools like 'clear_request_logs' or 'get_mock_invocations'.
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 guidance on when to use this tool: 'to verify that expected API calls were made to the mock server.' This directly addresses the tool's primary use case and distinguishes it from alternatives like 'get_mock_invocations' or 'verify_mock', which might serve different verification purposes.
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 valuable context beyond annotations: it specifies what gets cleared ('verification data (invocation records and counters)') and the test scenario use case. While annotations already indicate destructive and idempotent behavior, the description provides specific details about the data affected, earning a high score.
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 perfectly concise with two sentences: the first states the purpose and scope, the second provides usage guidance. Every word earns its place with zero wasted text, making it highly efficient and 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 tool's complexity (destructive operation with one parameter) and the presence of annotations covering safety aspects, the description provides good contextual completeness. It explains what data is cleared and when to use it, though it doesn't mention output behavior (no output schema exists).
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?
With 100% schema description coverage, the input schema already fully documents the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for adequate but not enhanced parameter semantics.
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 specific action ('Clear verification data') and resource ('for a specific mock or all mocks'), distinguishing it from siblings like 'clear_request_logs' (which clears logs) or 'reset_chaos_stats' (which resets chaos statistics). It provides precise scope information.
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 states when to use this tool: 'to reset counters before running a new test scenario.' This provides clear context for usage and distinguishes it from other reset/clear operations by focusing on verification data rather than logs or chaos stats.
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 full burden. It covers the actions, parameters, and stateful binding behavior. However, it does not discuss side effects like idempotency (e.g., repeated create actions) or error handling, which would be beneficial for full transparency.
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 well-structured with a summary sentence, followed by action-specific examples and stateful binding examples. It is relatively long but appropriately detailed for a complex tool with 13 parameters and multiple actions. Could be slightly more concise, but the structure aids readability.
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 complexity (13 parameters, nested objects, no output schema), the description is comprehensive. It covers all actions, parameter requirements, stateful binding, and provides numerous examples. It lacks return value details but since no output schema exists, it's not a critical gap.
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 100%, so baseline is 3. The description adds significant value beyond the schema by explaining which parameters are required for each action, showing concrete examples, and detailing stateful binding configuration. This helps the agent understand parameter relationships and usage.
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 purpose: 'Create, retrieve, update, delete, list, or toggle mock endpoints.' It specifies the actions and provides examples, distinguishing it from sibling tools like manage_state or manage_workspace, which handle state and workspace management respectively.
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 explicit guidance on when to use each action (e.g., 'For get/update/delete/toggle, provide the mock ID. For create, provide type and protocol-specific configuration.') and includes examples for all actions and stateful binding. It does not explicitly mention when not to use an action or alternatives, but the context is clear enough.
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 idempotentHint=true, indicating it's a safe, repeatable read operation. The description adds value by specifying what is returned ('active chaos config and injection statistics'), which is useful context beyond the annotations. No contradictions with 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 is two sentences, front-loaded with the core purpose and followed by usage guidance. Every sentence earns its place with no wasted words, making it efficient and 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 tool's complexity (read-only, no parameters) and lack of output schema, the description is mostly complete. It explains what is retrieved and when to use it, but could slightly improve by detailing the format of the returned config or statistics for full completeness.
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 parameters and 100% schema description coverage, the baseline is high. The description compensates by explaining the return content ('active chaos config and injection statistics'), adding semantic meaning beyond the empty 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?
The description clearly states the verb 'Retrieve' and the resource 'current chaos fault injection configuration', specifying it includes latency, error rate, and bandwidth throttle settings. It distinguishes from sibling tools like 'set_chaos_config' (for modifying) and 'reset_chaos_stats' (for resetting statistics).
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?
It explicitly states when to use this tool: 'Use this to check what chaos rules are active before modifying them.' This provides clear context for usage versus alternatives like 'set_chaos_config' for modification, making it highly actionable.
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 idempotentHint=true, so the agent knows this is a safe, repeatable read operation. The description adds valuable context about what information is returned (health, ports, statistics) and that it combines multiple data types into one response, which goes beyond the annotations. No contradictions exist.
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 perfectly concise with two sentences that each serve distinct purposes: the first states what the tool does, and the second provides usage guidance. There's zero wasted language, and it's front-loaded with the core functionality.
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 has no parameters, good annotations (readOnly, idempotent), but no output schema, the description provides excellent context about what information is returned and when to use it. The main gap is the lack of output format details, but for a diagnostic tool with no parameters, this is reasonably complete.
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 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and it focuses on the tool's output semantics instead.
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 purpose with specific verbs ('Get server health, ports, and statistics') and distinguishes it from siblings by specifying it combines multiple types of information into a single response. It explicitly identifies the resource (server) and the scope of data returned.
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 guidance on when to use this tool ('Use this FIRST when debugging connectivity or port issues') and distinguishes it from potential alternatives by noting it combines health check, stats, and port information into one response, suggesting it's a comprehensive diagnostic tool.
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 idempotentHint=true, indicating safe, repeatable read operations. The description adds valuable context by specifying what data is retrieved (e.g., state, trip count, request count) and the purpose (monitoring after configuration), which goes beyond annotations. No contradictions with 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 is front-loaded with the core purpose in the first sentence, followed by usage guidance. Every sentence earns its place by adding specific details (e.g., components monitored) and context without redundancy. It is appropriately sized for the tool's complexity.
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 has no parameters, annotations cover safety (read-only, idempotent), and no output schema exists, the description is mostly complete. It explains what data is retrieved and when to use it, but could briefly mention the return format (e.g., structured data) for better clarity, though not strictly required.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and usage. A baseline of 4 is applied since no parameters exist, and the description adds value elsewhere.
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 verb 'Retrieve' and the resource 'status of all stateful chaos fault instances', specifying the exact components: circuit breakers, retry-after trackers, and progressive degradation. It distinguishes from siblings by focusing on monitoring active fault state machines, unlike tools like 'get_chaos_config' (configuration) or 'get_request_logs' (logs).
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?
It explicitly states when to use this tool: 'to monitor active fault state machines after configuring advanced chaos rules.' This provides clear context and distinguishes it from alternatives like 'get_chaos_config' (for configuration) or 'reset_chaos_stats' (for resetting). No exclusions are mentioned, but the guidance is sufficient for selection.
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 idempotentHint=true and destructiveHint=true, which the description aligns with by describing a reset operation. The description adds value by clarifying that it resets counters without affecting configuration, enhancing context 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?
Two sentences, front-loaded with the core action and purpose, with no wasted words. Every sentence earns its place by providing essential usage guidance.
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 0-parameter tool with annotations covering idempotency and destructiveness, the description is complete enough. It lacks output details, but since there's no output schema, this is a minor gap in an otherwise well-rounded description.
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 parameters and 100% schema coverage, the baseline is 4. The description adds no parameter details, which is acceptable since there are no parameters 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 clearly states the specific action ('reset'), target resource ('chaos injection statistics counters'), and scope ('to zero without changing the active chaos configuration'), distinguishing it from sibling tools like 'get_chaos_config' or 'set_chaos_config'.
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?
It explicitly states when to use this tool: 'to start fresh measurement after modifying chaos rules,' providing clear context and distinguishing it from alternatives like 'reset_verification' or other management tools.
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 destructiveHint=true and idempotentHint=true, but the description adds valuable context: it specifies the permanence of removal ('Permanently remove'), the scope ('all captured request/response logs'), and the irreversible nature ('cannot be undone'). This enhances understanding beyond the annotations without contradicting them.
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 front-loaded with the core action, followed by usage context and warning, all in three concise sentences with zero wasted words. Each sentence earns its place by providing critical information efficiently.
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 (destructive, no parameters, no output schema), the description is complete: it covers purpose, usage guidelines, behavioral traits (permanence, irreversibility), and parameter implications. With annotations providing safety hints, no additional details are needed for effective agent use.
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 parameters and 100% schema description coverage, the baseline is 4. The description appropriately explains that no inputs are needed, as it removes all logs by default, which aligns with the empty input schema and adds semantic clarity.
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 specific action ('Permanently remove') and target resource ('all captured request/response logs'), distinguishing it from siblings like 'get_request_logs' (which retrieves logs) and 'reset_verification' (which resets verification state). The verb 'remove' is precise 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided on when to use this tool ('for test isolation between test runs') and when not to use it ('This action cannot be undone'), with clear alternatives implied (e.g., use 'get_request_logs' to view logs instead). This helps the agent choose appropriately between destructive and non-destructive operations.
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:

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

Score Badge

Copy to your README.md:

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

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/getmockd/mockd'

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