Mantis Immersive Commerce MCP

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
Tools are mostly distinct, with clear separation between setup/installation, debugging, and store creation workflows. Some overlap exists among debugging tools (e.g., testMantisEvent vs. simulateUserFlow, getPerformanceMetrics vs. analyzeEventFlow), but each has a specific focus that reduces ambiguity.
Naming Consistency5/5
All tools follow a consistent camelCase verb-noun pattern (e.g., checkBrowserCompatibility, installMantisSDK, analyzeConsoleErrors). This provides a predictable and intuitive naming structure across the entire toolset.
Tool Count4/5
With 14 tools, the count is slightly on the higher end but still within a reasonable range for the server's scope, which covers SDK setup, debugging, and store creation. Each tool seems to serve a distinct purpose, though some consolidation of debugging utilities could have been made.
Completeness3/5
The toolset covers the core workflows of importing, creating, and publishing a store, as well as SDK installation and debugging. However, there are notable gaps, such as no update or delete operations for stores/catalogs, and no tool to list or manage existing stores, which could limit full lifecycle management.
Average 2.9/5 across 12 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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. 'Simulate' implies a non-destructive dry-run, but the description never states that it does not mutate live store state, whether it requires a prior setup, or what happens after execution. The one-line text leaves side effects and environmental requirements entirely unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, which is efficient in isolation. But for a tool with two parameters (one a nested-object array with defined steps), it is under-specification rather than disciplined conciseness. The brevity sacrifices the behavioral and usage detail an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested objects, no output schema, and no annotations, so the description must compensate — one vague sentence is not enough. The flow parameter's enumerated steps offer some support, but there is no information about return values, execution semantics, or prerequisites. The definition is incomplete for correct invocation.
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%: 'flow' lists its valid steps and 'timing' explains 'Delays between actions'. The description adds no additional parameter meaning, but with high schema coverage the baseline of 3 applies. The description earns no extra credit here, yet the schema carries the burden adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Simulate') and resource ('user interactions with Mantis experience'), so it is not a tautology. However, 'Mantis experience' is vague, and the description gives no hint of the flow-based nature that the schema's flow parameter reveals (load-experience, click-model, open-cart, add-item). It does not meaningfully distinguish from sibling testMantisEvent or analyzeEventFlow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings like testMantisEvent, analyzeEventFlow, or debugPostMessage. There are no stated exclusions, prerequisites (e.g., does the SDK need to be installed via installMantisSDK first?), or conditions selecting this tool over its alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. 'Analyze' weakly implies a read-only operation, but the description does not state whether the tool mutates state, what it computes, or what it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, which is efficient. However, it is under-specified rather than informatively concise, especially given two optional nested parameters and no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should indicate what the analysis produces or how results are returned. It does not, and it leaves the shape of sessionData and timeRange unclear, making it hard for an agent to invoke the tool confidently.
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?
Both parameters have schema descriptions and schema coverage is 100%, so the baseline is 3. The tool description itself adds no detail about the structure of timeRange or sessionData, but the schema already provides minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'analyze' and identifies resources 'event flow and user behavior', so it is not a tautology. However, it is vague about what kind of analysis is performed or what output is produced, and it does not differentiate itself from sibling tools like simulateUserFlow or analyzeConsoleErrors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage conditions, contexts, or exclusions are given. The sibling list contains closely related tools such as simulateUserFlow and testMantisEvent, but the description provides no guidance on when to choose this tool over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavior. It only states 'check browser compatibility issues,' which implies a read-only operation but does not confirm it, nor does it describe what the output looks like, whether it makes network calls, handles errors, or has side effects. The agent is left without any behavioral expectations beyond the vague verb 'check.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in length (one sentence) and front-loads the core action, but it is so minimal that it borders on under-specification rather than effective conciseness. No extraneous words, but also no meaningful content beyond a restatement of the name. Structure is acceptable but lacks substance.
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 absence of an output schema and annotations, the description must explain return values and behavior, but it does not. It also omits what 'compatibility issues' means and how the optional userAgent parameter affects results. The tool likely works on a list of features, but the description gives no clue about expected output or edge cases, making it incomplete for an agent to call 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?
The schema covers both parameters (features and optional userAgent) with descriptions, so the baseline is 3. The tool description adds no additional meaning or context about these parameters—it doesn't explain how the userAgent affects results or what kinds of features are expected. It neither enhances nor contradicts the schema, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'check' and the resource 'browser compatibility issues,' which gives a general sense of the tool's purpose. However, it is vague about what specific aspects of compatibility are assessed (e.g., CSS features, APIs, specific browsers) and does not differentiate it from sibling tools. It is not a tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like analyzeConsoleErrors or testMantisEvent. No context is provided about typical scenarios, prerequisites, or when another tool would be more appropriate. The description does not help an agent decide between this and any sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden, but it only says the tool 'generates' code. It does not disclose whether code is returned, written to files, executed, or what responseMode changes, and it does not mention any side effects or setup requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant words. It is concise, though perhaps too terse for the tool's complexity.
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?
For a code-generation tool with 4 parameters, no output schema, and no annotations, the description is incomplete. It omits the output format, the effect of responseMode and storeType, and how this tool relates to the install/validate siblings.
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 covers 100% of the parameters with clear descriptions, including enums for storeType and responseMode. The description adds only the phrase 'for your framework,' which maps to the framework parameter, so it does not meaningfully improve on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action, 'Generate,' and a resource, 'Mantis integration code,' so an agent can tell this is a code-generation tool. However, 'integration code' is broad and does not distinguish it from siblings like generateEventHandler or installMantisSDK, and it never explains what Mantis integration entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over its siblings, such as installMantisSDK or validateSetup. It does not state prerequisites, typical use cases, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only says 'Debug' without revealing that it captures messages for a captureTime duration, filters by origin, or what the output/return format is. This is too sparse for an agent to understand the tool's actual 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 a single, front-loaded sentence with no filler or redundancy. While it is under-specified, it is concise and each word contributes to identifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should provide more context about behavior, return values, or side effects. The schema's parameter descriptions hint at message capture, but an agent still cannot tell what calling this tool returns, how results are presented, or whether it operates on the current page or only on the provided URL.
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 baseline is 3 even though the description adds no parameter-specific insight. The schema already documents url, captureTime, and filterOrigin adequately, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific domain ('postMessage communication issues') and a verb ('debug'), so it is not tautological. However, 'debug' is broad and does not explain what the tool actually does—capturing, filtering, or inspecting messages—nor does it clearly differentiate from siblings like analyzeEventFlow or analyzeConsoleErrors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its alternatives, and no exclusions, prerequisites, or context are mentioned. The only implied usage is the generic one in the description, which leaves an agent to infer when to select it among 13 sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The verb 'test' implies it triggers events or validates responses, but it does not state whether this is a read-only operation or if it mutates state, requires authentication, or has side effects. The description is too terse to convey the operational impact, leaving the agent guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence, which is concise. However, it is so brief that it omits critical context, making it under-specified rather than effectively concise. It earns a middle score because it is direct but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a minimal description, the tool is incomplete for an agent. It does not state what a successful test returns, whether the SDK must be pre-installed, or how to interpret the 'expectedResponse' validation. For a tool with nested object parameters, this is insufficient for reliable invocation.
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%, meaning all three parameters (event, data, expectedResponse) have descriptions. The tool description adds no extra meaning beyond these field descriptions, so it does not enhance parameter understanding. Per the rubric, the baseline is 3 when schema coverage is high and the description does not compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Test') and resource ('Mantis SDK events and responses'), which is clear and matches the tool name. However, it does not distinguish this from potential siblings like analyzeEventFlow or debugPostMessage, which could also involve event handling. It is specific enough but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus siblings such as validateSetup or debugPostMessage. It does not mention any prerequisites (e.g., SDK install) or conditions that would select this tool over alternatives. An agent is left without contextual cues for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It says 'analyze' and 'suggest fixes,' which implies a read-only, advisory operation, but it does not state whether the tool modifies anything, what the output format is, or how browserInfo is used. Essential behavioral details such as side effects, response structure, or prerequisites are absent.
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 sentence that is concise and front-loads the core action ('Analyze console errors') followed by the purpose ('suggest fixes'). There is no filler or redundancy; every word contributes to the message. This is an example of effective minimalism.
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?
For a tool with two parameters, one nested object, and no output schema, the description leaves too much uncertainty. It does not explain the nature of 'fixes' (e.g., are they code snippets, recommendations, links?), how browserInfo might influence analysis, or any limitations. Combined with a lack of annotations and sibling differentiation, an agent cannot fully anticipate the tool's behavior or results.
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 describes both parameters (errors array and browserInfo object) fully, so schema coverage is 100% and the baseline is 3. The description does not add any extra meaning beyond what the schema already provides—it simply restates the resource. There is no enrichment of parameter semantics beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Analyze console errors and suggest fixes.' This is a specific action on a specific input, making the purpose evident. However, it does not distinguish itself from sibling tools like analyzeEventFlow or debugPostMessage; an agent might need to infer which tool applies to console-specific issues. Still, 'console errors' is a distinct enough resource for most cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus its siblings. Given the sibling list includes analyzeEventFlow, debugPostMessage, and other diagnostic tools, an agent lacks criteria to decide between them. No context is provided about scenarios that warrant this tool specifically, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states 'generate event handler code' without indicating whether this is a read-only operation, whether it modifies files, or what the output format is. The absence of side-effect clarity is a significant gap for a code-generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, unambiguous sentence conveys the purpose without unnecessary words. It is compact and front-loaded, though it omits details that would enhance usability, which prevents a perfect score.
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 code generation tool with no output schema, the description is minimally sufficient but lacks essential context about the output type, examples, or any side effects. An agent would understand what it does but not what to expect in return, which is incomplete for a non-trivial operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all three parameters (event, action, framework), each with a brief explanation. The description adds no additional meaning beyond what the schema provides, so the baseline of 3 applies given 100% schema coverage.
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 verb 'generate' and the resource 'event handler code for Mantis SDK events', making it distinguishable from sibling tools like testMantisEvent or analyzeEventFlow. However, it does not explicitly differentiate itself beyond the core action, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. Without mentioning sibling tools or usage context, an agent has no basis for selecting this over createMantisIntegration or testMantisEvent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Get performance metrics' without revealing whether it actively loads a URL, monitors over the duration, requires prior SDK setup, or has side effects. The metrics and duration parameters imply ongoing collection, but that behavior is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and object, with no filler. It is appropriately terse, though brevity comes at the cost of important behavioral context. The structure is clean and immediately scannable.
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?
No output schema and no annotations exist, so the description must explain invocation context and return behavior. It omits return format, prerequisites such as installMantisSDK or validateSetup, and how url and duration affect monitoring. For a tool with three parameters, this is too sparse to support confident invocation.
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 the URL, metric list, and duration semantics. The tool description adds no additional parameter meaning beyond restating the general purpose. Since the schema handles parameter documentation, the baseline 3 is appropriate.
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?
States a clear verb+resource: retrieves performance metrics for a 3D experience. It is distinct from all sibling tools, which focus on SDK setup, events, store management, and debugging. Though somewhat generic, it is not tautological or misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance about when to use this tool versus alternatives, and no prerequisites are mentioned. There are no sibling performance tools, so intended usage is implied only by naming and context. It does not state whether it should be called after setup, during development, or in a specific environment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It reveals that the tool installs and configures the SDK and touches .npmrc, but it does not disclose whether it overwrites an existing .npmrc, requires an auth token for private registries, installs packages, or what side effects occur on the project.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with the action front-loaded. The phrase 'proper .npmrc setup' is slightly vague but not wordy, and no sentence is wasted.
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?
For an installation tool with no output schema and no annotations, an agent needs more context: prerequisites like Node/npm, whether the .npmrc is created or modified, whether authToken is required for private packages, and how to verify success (e.g., referencing validateSetup). The description only covers the high-level action.
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?
All three parameters (authToken, framework, projectPath) already have descriptions in the input schema, so the schema provides 100% coverage, which is the baseline 3. The description adds no meaningful parameter-level meaning beyond the schema, such as how authToken interacts with the npmrc setup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Install and configure') and resource ('Mantis SDK') with a concrete detail: 'proper .npmrc setup'. This clearly identifies what the tool does and is distinct from sibling tools like validateSetup or createMantisIntegration, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as validateSetup or createMantisIntegration. The description provides no exclusions, prerequisites, or contextual conditions, so the agent must infer usage solely from the word 'install'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself, but 'Validate Mantis SDK installation and configuration' does not say whether the tool performs checks only, modifies any state, requires authentication, makes network calls, or how it reports failures. The read-only nature is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. It is not verbose, and the core action is front-loaded, though it could use some of its saved space for behavioral or usage detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what the agent should expect after calling it (e.g., success/failure signals, what is checked). It does not. It also omits when to call it relative to installMantisSDK, leaving the context incomplete.
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 three optional parameters. The description adds no parameter-level detail beyond labeling the overall area as 'installation and configuration', which only loosely maps to checkAuth, projectPath, and checkOrigins.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear action, 'Validate', and a specific target, 'Mantis SDK installation and configuration'. However, it does not distinguish this from the sibling checkBrowserCompatibility, which also sounds like a verification/checking tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to run validateSetup as opposed to installMantisSDK, checkBrowserCompatibility, or the debugging siblings. The context of a post-installation sanity check is only implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full behavioral burden. It only states the import action and sources, without disclosing whether existing catalog data is replaced, whether authentication is required, or what side effects occur on the store.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening clause is concise and front-loaded. However, 'high-converting 3D commerce store' is promotional rather than operational, and the second sentence is vague about the actual usage boundary, so not every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no annotations, and no output schema, the description should tie source-specific parameters together and indicate expected outcomes. It does neither, leaving an agent unsure about prerequisites, success conditions, or side effects.
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 the baseline of 3 applies. The description restates the source enum but does not explain conditional dependencies such as Shopify requiring shopifyStore and shopifyAccessToken, or CSV requiring csvData.
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?
States a clear verb and resource: 'Import product catalog' from Shopify, CSV, or manual input. This distinguishes it from siblings like createStore and publishStore, but the clause 'create or improve an e-commerce store' broadens the scope and could cause mis-selection.
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?
Provides an explicit trigger ('Use this when...') but it is overbroad and does not mention alternatives or exclusions. It doesn't clarify that store creation likely belongs to createStore or publishing to publishStore, leaving selection partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'create' a store and does not mention side effects, required setup, permissions, whether the store is immediately published, or if this can be called repeatedly. This is insufficient for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but part of it is filler and marketing language ('converts better than traditional e-commerce', 'drives sales'). The useful operational instruction 'Use this after importing products' is included, but the promotional phrases do not earn their place in a tool description.
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?
This is a complex tool with 5 parameters, nested objects, no output schema, and no annotations. The description does not explain expected config/product shapes, return values, or any post-creation behavior. An agent would have to rely entirely on the schema and infer expectations from sibling context, which is not enough.
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 baseline is 3. The description adds a small amount of context by implying products should already exist, but it does not clarify the structure of the nested config or product objects beyond what the schema already provides.
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 uses a specific verb ('create') and identifies a distinct resource ('3D commerce showroom' / store). It clearly distinguishes this from import and publish siblings by focusing on the creation step. However, it does not explicitly contrast itself with related tools like publishStore or importCatalog beyond sequencing.
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 gives clear usage context: 'Use this after importing products.' This implies a workflow ordering relative to importCatalog and publishStore. It does not explicitly mention when not to use the tool or name alternatives, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does state that the tool changes store state from unpublished to public, with customers able to shop. It does not disclose permissions, reversibility, or side effects on existing published versions, so it only partially covers the behavioral surface.
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, with the primary action front-loaded and the lifecycle context in the second sentence. No filler or duplicated schema 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?
For a simple three-optional-param publish action, the description plus schema give the core call shape and final-step context. It is missing details on residues such as whether republishing is idempotent or if domain configuration must exist, so it is adequate but not thorough.
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 baseline applies; each parameter is described in the schema. The description adds no parameter syntax or selection guidance beyond that, but none 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 opens with a concrete action verb and resource: 'Publish the 3D showroom live.' It positions the tool at the end of a lifecycle ('Final step to launch a high-converting store'), which clearly separates it from sibling creation/validation tools like createStore and validateSetup.
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?
It provides temporal guidance ('Final step to launch') that tells an agent this runs after setup and validation. It does not name alternatives or list explicit when-not-to-use conditions, but the launch context is clear enough to route an agent here.
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:

[![mantis-mcp MCP server](https://glama.ai/mcp/servers/kahlilashanti/mantis-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kahlilashanti/mantis-mcp)

Score Badge

Copy to your README.md:

[![mantis-mcp MCP server](https://glama.ai/mcp/servers/kahlilashanti/mantis-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kahlilashanti/mantis-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/kahlilashanti/mantis-mcp'

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