Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@brainerce/mcp-server show me the checkout business flow"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Framework-agnostic domain knowledge for building on Brainerce, a headless commerce platform. This MCP server answers questions an AI coding assistant needs while building or extending a Brainerce-powered storefront — SDK reference, type definitions, business-flow sequencing, critical rules, and a given store's live capabilities.
It does not generate framework boilerplate. Use Next.js, Remix, Vite + React, Vue, Svelte, Astro, SolidStart, or whatever the surrounding project already uses — this server tells the agent what to build correctly, not how to lay out files. For opinionated scaffolding, see the companion create-brainerce-store CLI.
Claude Code (plugin):
claude plugin install brainerce-mcp@claude-plugins-communityAny MCP client (stdio, manual config):
{
"mcpServers": {
"brainerce": {
"command": "npx",
"args": ["-y", "@brainerce/mcp-server"]
}
}
}Related MCP server: SFCC Development MCP Server
Tool | Purpose |
| Live features configured for a specific store (payment providers, OAuth, discounts, shipping, i18n). Call first — it tells the agent which conditional features to build. |
| Functional coverage checklist — what users must be able to do, not which files to create. Mandatory features must exist even when currently disabled in the store (they auto-hide; owners enable them later). |
| Do's and don'ts that cause production incidents if violated — SDK usage, auth token handling, checkout invariants, i18n, type safety. |
| Non-negotiable ordered SDK call sequences: checkout, auth, password reset, OAuth, order confirmation, cart persistence, inventory reservation. |
| SDK documentation by topic — setup, API usage, best practices. |
| TypeScript types for Product, Cart, Checkout, Order, etc. |
| Short, focused snippets for tricky SDK calls (payment confirmation, reservation countdown, OAuth redirect, variant selection). |
| Live store metadata (display name, currency, language) for a sales channel. |
| Step-by-step integration walkthrough — |
sdk-types — the full Brainerce SDK type surface as a text resource.
create-store — framework-agnostic brief for building a new Brainerce-powered store; instructs the agent to call the knowledge tools above before writing code.
add-feature — focused prompt for adding one feature to an existing Brainerce store.
pnpm build
pnpm start:stdio # stdio transport, for local MCP clients
pnpm start:http # Streamable HTTP + legacy SSE, for remote clients (default port 3100)The HTTP server is a public, unauthenticated documentation oracle by design — everything behind it is public SDK/docs data. It applies allow-listed CORS, per-IP rate limiting, request size caps, and SSE session limits; see src/bin/http.ts for details.
This server serves static SDK documentation and, for the store-scoped tools (get-store-info, get-store-capabilities, get-required-features), reads public store configuration via Brainerce's public API. It does not collect or store conversation data. See brainerce.com/privacy for the full policy.
MIT — see LICENSE.
Get the non-negotiable business flows for a Brainerce store. Returns ordered SDK call sequences for checkout, auth, password reset, OAuth, order confirmation, cart persistence, and inventory reservation. Framework-neutral — no file paths, no framework-specific code. Call this before implementing any of these flows.
| Name | Required | Description | Default |
|---|---|---|---|
| flow | Yes | Which flow to retrieve. Use "all" to get every flow. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns ordered sequences and is framework-neutral, but doesn't mention rate limits, errors, authentication needs, or output structure. Adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste. The purpose is stated first, followed by specifics and usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is mostly complete. It explains what is returned, for which flows, and when to call. Slightly more detail on return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single 'flow' parameter with enum and description. The tool description adds value by listing example flows ('checkout, auth, password reset...') and noting they are 'ordered' and 'non-negotiable', moving beyond schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'non-negotiable business flows' for a Brainerce store, returning 'ordered SDK call sequences' for specific flows. This specific verb+resource combination distinguishes it from siblings like get-code-example or get-critical-rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Call this before implementing any of these flows,' providing clear when-to-use guidance. Though it doesn't mention when not to use or alternatives, the sibling context and clarity of purpose make usage intuitive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a short, focused TypeScript snippet for a specific Brainerce SDK operation. Framework-neutral — no Next.js file paths, no Tailwind, no framework-specific imports. Use this when you need the exact shape of a tricky SDK call (payment confirmation, reservation countdown, OAuth redirect, variant selection, etc.). For full SDK reference by topic, use get-sdk-docs instead.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | The SDK operation to get a snippet for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses framework-neutral behavior and that it returns a snippet, but does not discuss permissions, error scenarios, or response format. Since no annotations are provided, the description carries the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences with no wasted words: states purpose, usage guidelines, and sibling reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately complete for a simple one-parameter tool with no output schema; could further specify snippet content (e.g., imports), but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is documented. The description adds no additional meaning beyond the schema, but the enum values convey the valid operations implicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a short, focused TypeScript snippet for a specific SDK operation, and distinguishes it from the sibling tool get-sdk-docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('when you need the exact shape of a tricky SDK call') and provides an alternative ('use get-sdk-docs instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the do's and don'ts for building a Brainerce store. Returns framework-neutral rules that cause production incidents if violated — SDK usage, state management, auth token handling, checkout invariants, i18n, and type safety. Call this before writing SDK code.
| Name | Required | Description | Default |
|---|---|---|---|
| topics | No | Topics to include. Defaults to all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that returns are framework-neutral rules that cause production incidents if violated, indicating the critical nature. Missing details about response format or authentication, but acceptable for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with purpose. No extraneous content. Front-loaded with purpose, then details, then usage guidance. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (one optional enum parameter, no output schema), the description suffices. It mentions the rule categories and framework neutrality. Could briefly note return format but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage, but the description adds value by enumerating the topics beyond the schema's generic 'Topics to include.' This helps the agent understand available options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 'do's and don'ts' for building a Brainerce store, with specific topics listed. It is distinct from sibling tools like get-sdk-docs or get-code-example, as it focuses on critical rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'Call this before writing SDK code,' providing clear usage context. However, it does not explicitly exclude use cases for sibling tools, 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.
Get the Brainerce integration guide for connecting any website to Brainerce. Returns step-by-step instructions with full API endpoints, request/response examples, and code snippets. Use "core" for the main guide (products, cart, checkout, payment, orders), "optional" for extra features (accounts, OAuth, promotions), or "rules" for validation, error codes, and edge cases.
| Name | Required | Description | Default |
|---|---|---|---|
| part | Yes | Which part of the integration guide to retrieve. "core" = products, cart, checkout, payment, orders (start here). "optional" = customer accounts, OAuth, discounts, bundles, downloads. "rules" = validation, error codes, edge cases, decision trees, common mistakes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral transparency. It correctly states the tool returns documentation (no side effects). It does not mention auth or rate limits, but as a read-only retrieval tool with a single enum parameter, the description is sufficient for an agent to understand 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that immediately states the tool's purpose and then explains the parameter options. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description provides a complete picture: what the tool returns (guide with instructions, APIs, code snippets) and the three distinct parts. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter fully (100% with enum and description). However, the description adds significant value by explaining the exact content of each enum value: core covers products, cart, checkout, payment, orders; optional covers accounts, OAuth, discounts, bundles, downloads; rules covers validation, error codes, edge cases. This extra detail helps the agent choose correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an integration guide for connecting a website to Brainerce, with specific content types (step-by-step instructions, API endpoints, code snippets). It distinguishes three distinct parts (core, optional, rules), setting it apart from sibling tools like get-code-example or get-critical-rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use each part via the 'part' parameter, but does not mention when to avoid this tool in favor of siblings. However, the sibling context implies this is the primary integration guide, and the parameter guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the functional coverage checklist for a Brainerce store. Returns user-capability-level features (what users must be able to do) rather than pages or file paths. Every feature marked mandatory must exist in the finished build, even when the underlying capability is currently disabled — those features auto-hide and store owners enable them later. Pass a salesChannelId to tune the checklist to the live store; without it, returns the generic complete-store checklist.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | No | Deprecated alias of salesChannelId — kept for backwards compat | |
| salesChannelId | No | Sales channel ID (starts with vc_). Optional — without it, returns the generic checklist. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral nuance: mandatory features auto-hide when the underlying capability is disabled but must still exist in the build. This is valuable context beyond a simple read operation. It does not cover side effects, auth needs, or rate limits, but the disclosed behavior is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but concise, with five sentences each adding essential information: primary purpose, type of features, mandatory behavior, parameter guidance, and default behavior. It is front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return type (user-capability-level features) and key behavioral detail (mandatory even if disabled). It does not detail the structure of the checklist (e.g., fields), but the information provided is sufficient for an agent to understand what the tool returns and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning by explaining the tuning effect of salesChannelId and noting that connectionId is a deprecated alias. This helps the agent understand parameter purpose and consequences beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving a 'functional coverage checklist' for a Brainerce store, specifying it returns user-capability-level features (not pages or file paths). The verb 'Get' and specific resource 'required features' make the purpose unambiguous, and it distinguishes from sibling tools by emphasizing the checklist nature and user-capability focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that passing a salesChannelId tunes the checklist to a live store, while omitting it returns a generic checklist. It also notes that mandatory features must exist even if disabled. However, it does not explicitly state when not to use this tool or compare it to alternatives like get-store-capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Brainerce SDK documentation for a specific topic. Returns setup instructions, API usage, code examples, and best practices. Start with "setup" or "critical-rules", then request specific topics as needed.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The SDK documentation topic to retrieve | |
| currency | No | Store currency code (e.g., USD, ILS, EUR). Used in price formatting examples. | |
| connectionId | No | Deprecated alias of salesChannelId — kept for backwards compat | |
| salesChannelId | No | Sales channel ID (starts with vc_). Used to personalize setup code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It implies read-only retrieval of documentation but doesn't explicitly state side effects, authentication needs, or rate limits. Minimal transparency for a tool with zero annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, content summary, and usage guidance. No redundancy or unnecessary detail. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple documentation tool: covers parameters (via schema) and output nature. But lacks error handling details, and given sibling overlap, could be more explicit about when to use this vs. other tools. Output format not described beyond general content types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. Description adds value by suggesting initial topic values and explaining the purpose of currency and salesChannelId (price formatting, personalization). Exceeds baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets SDK documentation for a topic and describes content (setup, API usage, etc.). Suggests starting points but doesn't explicitly differentiate from siblings like get-code-example or get-critical-rules, which may cause overlap confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides sequential guidance ('Start with setup or critical-rules') but lacks when-not-to-use or comparisons to sibling tools. Implicit use case but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live store capabilities and configured features for a sales channel. Returns what payment providers, OAuth, shipping, discounts, and other features are set up. Use this to discover what your store supports and what pages/components to build.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | No | Deprecated alias of salesChannelId — kept for backwards compat | |
| salesChannelId | No | Sales channel ID (starts with vc_) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. States it returns live capabilities, implying non-destructive read. Does not detail side effects, permissions, or rate limits, but adequate for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences concisely deliver purpose and usage. No redundancy, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists return categories (payment providers, OAuth, etc.). Helps agent understand result coverage. Could mention structure, but sufficient for discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds no extra parameter information beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states specific verb 'Get' and resource 'store capabilities and configured features'. Differentiates from siblings like get-store-info by focusing on features and capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use this to discover what your store supports and what pages/components to build', providing clear usage context. Does not mention when not to use or alternatives, but still effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch live store information from the Brainerce API using a sales channel ID. Returns the channel display name (what the user sees in their dashboard), parent store name, currency, and language. Use this to personalize the store being built — prefer the channel name for user-facing text since a single Brainerce store can have multiple sales channels.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | No | Deprecated alias of salesChannelId — kept for backwards compat | |
| salesChannelId | No | Sales channel ID (starts with vc_) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as fetching 'live' data, implying real-time, and lists return fields. However, it does not explicitly state read-only behavior or mention side effects, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. First sentence defines purpose and output, second provides actionable usage guidance. Perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists key return fields and explains why to prefer channel name, which is sufficient for agent understanding. Lacks mention of error handling or behavior without required parameter, but context signals indicate no required params, so adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value by clarifying connectionId is a deprecated alias of salesChannelId and that salesChannelId starts with 'vc_', supplementing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool fetches live store info using a sales channel ID, lists specific return fields (channel display name, parent store name, currency, language), and clearly distinguishes itself from sibling tools like get-business-flows or get-code-example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use ('to personalize the store being built') and how to interpret results ('prefer the channel name for user-facing text'), including context about multiple sales channels. No explicit when-not, but sufficient for a simple fetch tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TypeScript type definitions from the Brainerce SDK, segmented by domain. Use this when you need to understand the exact shape of objects like Product, Cart, Checkout, Order, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain of types to retrieve. Use "helpers" for helper function signatures and common types like StoreInfo, PaginatedResponse. Use "content" for FAQ / Footer / Header / Announcement / RichText / Page. Use "regions" for Region / TaxClass admin types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., side effects, authentication, rate limits). It is a read operation, but this could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. It is front-loaded with the main action and resource, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers the purpose and usage context. However, it does not describe the return format or any potential error conditions, which would add completeness. With low complexity, a 3 is adequate but not exceptional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% with a fully described enum and description. The description adds minimal additional value beyond restating the domain segmentation and giving usage tips for 'helpers'. Per guidelines, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and the resource (TypeScript type definitions segmented by domain), with examples of objects (Product, Cart, etc.). It distinguishes well from sibling tools like get-code-example or get-business-flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage context: 'Use this when you need to understand the exact shape of objects...' It implicitly guides the agent on when to invoke this tool, though it does not explicitly mention when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v3.12.4get-business-flowsget-code-exampleget-critical-rulesget-integration-guideget-required-featuresget-sdk-docsget-store-capabilitiesget-store-infoget-type-definitionsEach tool targets a unique aspect of Brainerce store integration—business flows, code snippets, rules, guide, features, docs, capabilities, info, types—with no functional overlap.
All tool names follow the exact 'get-<noun-phrase>' pattern using snake_case, ensuring predictable and uniform naming.
9 tools is an ideal scope for a documentation/guidance server, covering all essential information retrieval needs without excess or deficiency.
The tool surface comprehensively covers guidance for building a Brainerce store—flows, rules, features, capabilities, code examples, types—leaving no obvious gaps for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Serves your design system and coding standards to coding agents, so they stop guessing.
Enable AI assistants to interact seamlessly with Feeef e-commerce stores, products, and orders usi…
Versioned documentation registry and semantic search for AI tools and coding assistants.
AI-powered commerce API for luxury skincare shopping. Enables AI agents to search products, browse collections, manage shopping carts, and generate checkout URLs for the Regenique Elegance Shopify store.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/brainerce/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
