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., "@OlaOla Supplement MCP Recommend an energy stack under 900 Kč"
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.
Finding the right supplements is rarely just a search problem. What makes sense depends on what you are trying to solve, what you already take, your diet, budget, medication risks, labs, and whether you are trying to avoid specific ingredients.
OlaOla already makes supplement discovery fairly approachable for Czech customers, and they have a chatbot on olaola.cz. The limitation is that the shop bot only has storefront context. It does not know what you have already discussed in ChatGPT, what is in your current supplement stack, or the constraints you gave elsewhere. It can also get stuck on shallow recommendations. For example, if you ask for something for energy without ashwagandha, it may keep recommending the same ashwagandha-containing product through different bundles.
This MCP server connects a model to OlaOla product data, product composition details, account order history, anonymous shadow carts, and quick-buy links. The connector retrieves facts; the model keeps the personal context, asks follow-up questions, checks ingredients, compares doses, and decides what is worth recommending.
This project is an independent, community-built MCP server. It is not affiliated with, endorsed by, sponsored by, or officially connected to OlaOla, olaola.cz, or their owners/operators. Product names, trademarks, and links are used only to identify the public storefront and account workflows this connector interacts with.
Related MCP server: AIVA MCP Server
Use your existing chat context and ask for recommendations that respect your real constraints:
"What should I buy on OlaOla if I am constantly tired?"
"Find something for energy, but avoid ashwagandha."
"I already take vitamin D and magnesium. What still makes sense?"
"Compare OlaDen with magnesium malate for fatigue and value."The model can search OlaOla, use public product-content text from olaola.cz for extra context, fetch the actual product composition, check ingredient amounts, and explain why a product is a good fit, bad fit, or only a maybe.
The MCP is useful when the question is not just "what is popular?", but "what fits with what I already have?":
"Can I combine these supplements?"
"Is there duplicated vitamin D in this stack?"
"Which products in my planned cart contain ashwagandha?"
"What should I skip until I have blood tests?"The model should ask about current supplements, medication risks, goals, budget, and labs before making confident recommendations.
With local OlaOla credentials configured, the MCP can read your account order history on demand:
"What did I already buy from OlaOla?"
"Did my last OlaOla order already include magnesium?"
"Use my previous OlaOla purchases as context for this recommendation."The server does not store this history. It logs in, fetches the requested account page, returns normalized results, and keeps authenticated cookies in memory only for that request.
You can build an anonymous planning cart, read your real OlaOla account cart when credentials are configured, or export a recommended stack as a quick-buy link:
"Create a simple energy stack under 900 Kč."
"Add the best candidates to a planning cart."
"What's currently in my OlaOla cart?"
"Generate a quick-buy link for this stack."Use the hosted MCP endpoint directly in ChatGPT:
Enable developer mode for custom MCP connectors in your workspace.
Create a new app/connector.
Provide this MCP endpoint: https://olaola-mcp.bxxf.dev/mcp.
Enable the connector in a new chat and test the tools.
ChatGPT custom connectors use the remote HTTP endpoint directly. Do not put OlaOla credentials into ChatGPT prompts.
Use this for local MCP clients that connect to the hosted endpoint through mcp-remote, such as Codex, Claude Desktop, Cursor, or other clients that expect a local command.
Public product lookup only:
{
"mcpServers": {
"olaola": {
"command": "npx",
"args": ["mcp-remote", "https://olaola-mcp.bxxf.dev/mcp"]
}
}
}With per-user OlaOla account tools, pass credentials from local environment variables as headers:
{
"mcpServers": {
"olaola": {
"command": "npx",
"args": [
"mcp-remote",
"https://olaola-mcp.bxxf.dev/mcp",
"--header",
"olaola-email: ${OLAOLA_EMAIL}",
"--header",
"olaola-password: ${OLAOLA_PASSWORD}"
],
"env": {
"OLAOLA_EMAIL": "you@example.com",
"OLAOLA_PASSWORD": "your-password"
}
}
}
}Only use headers with an HTTPS endpoint you control or trust. The remote MCP server receives the password on every request that includes the header.
Add this to ~/.codex/config.toml:
[mcp_servers.olaola]
command = "npx"
args = [
"mcp-remote",
"https://olaola-mcp.bxxf.dev/mcp",
"--header",
"olaola-email: ${OLAOLA_EMAIL}",
"--header",
"olaola-password: ${OLAOLA_PASSWORD}"
]
[mcp_servers.olaola.env]
OLAOLA_EMAIL = "you@example.com"
OLAOLA_PASSWORD = "your-password"Add the JSON config above to Claude Desktop's MCP config file, then restart Claude Desktop.
Use this for local MCP clients that can start a stdio server, such as Claude Desktop, Cursor, Codex, or native AI apps with MCP support.
Install dependencies, build the project, and run a typecheck:
cd /Users/bxxf/projects/ola-ola
npm install
npm run build
npm run typecheckTo run the built stdio server directly:
cd /Users/bxxf/projects/ola-ola
npm startFor local development without building first:
npm run devThe server speaks MCP over stdio, so most local MCP clients need a command plus args rather than a URL.
To run MCP over HTTP locally:
npm run dev:httpThe HTTP MCP endpoint is available at:
http://localhost:3000/mcpAfter building, add this server to your MCP client config:
{
"mcpServers": {
"olaola": {
"command": "node",
"args": ["/Users/bxxf/projects/ola-ola/dist/server.js"]
}
}
}To enable OlaOla account order history, add credentials as environment variables in the MCP client config:
{
"mcpServers": {
"olaola": {
"command": "node",
"args": ["/Users/bxxf/projects/ola-ola/dist/server.js"],
"env": {
"OLAOLA_EMAIL": "you@example.com",
"OLAOLA_PASSWORD": "your-password"
}
}
}
}Do not put credentials into prompts or tool arguments. Keep them in the local MCP client configuration only.
The server supports Streamable HTTP at /mcp, so it can be deployed behind a public HTTPS URL.
This repository deploys to the custom domain olaola-mcp.bxxf.dev. For your own deployment, replace every endpoint example with:
https://YOUR_CUSTOM_DOMAIN/mcpThe domain's Cloudflare zone must be in the selected Cloudflare account or available to that account.
For local HTTP testing:
npm run build
npm run start:httpFor Cloudflare Workers, copy the example config and replace the route with your own domain:
cp wrangler.example.toml wrangler.tomlwrangler.toml is intentionally gitignored because it is deployment-specific.
Then deploy:
npm run deploy:cloudflareFor account tools, a shared hosted deployment must not use one global OlaOla account. Do not set OLAOLA_EMAIL or OLAOLA_PASSWORD as Cloudflare secrets on a public deployment, because every user would operate through that same account.
For local-only usage, stdio can still read credentials from the MCP client environment.
olaola_get_auth_status: check whether OlaOla login is configured and working.
olaola_get_order_history: fetch authenticated OlaOla order summaries.
olaola_get_order_detail: fetch one authenticated order detail.
olaola_read_account_cart: fetch the real authenticated OlaOla cart.
olaola_add_to_cart: add to the real account cart when credentials are configured, otherwise create/use a shadow cart. Real account cart changes require confirmed=true.
olaola_update_cart_item: update an existing cart line item by cartItemId. Real account cart changes require confirmed=true.
olaola_remove_from_cart: remove an existing cart line item by cartItemId. Real account cart changes require confirmed=true.
olaola_add_to_account_cart: add a product to the real authenticated cart. Requires confirmed=true.
olaola_get_product: parse a public product URL or slug.
olaola_get_product_details: fetch product composition, ingredient amounts, warnings, and dosing text when available.
olaola_search_products: search OlaOla for real product candidates using storefront search plus the product sitemap.
olaola_search_product_content: search public WP product-content text for extra semantic context. These results are not directly cartable products.
olaola_create_shadow_cart: create an anonymous cart session.
olaola_add_to_shadow_cart: add a product variant or URL to a shadow cart.
olaola_read_shadow_cart: read normalized cart items from a shadow cart.
olaola_update_cart_item: update a shadow-cart line item when mode="shadow" and cartId are provided.
olaola_remove_from_cart: remove a shadow-cart line item when mode="shadow" and cartId are provided.
olaola_generate_quick_buy_url: generate an OlaOla quick-buy URL from variant IDs or product URLs.
Credentials are read only from local environment variables. Passwords and cookies are never returned by tools. Authenticated cookies stay in memory for the request.
Supplement history, owned products, medication context, ingredient exclusions, and product feedback can be sensitive. This MCP does not store those details in a database or local profile. The model should use personal information from the active chat context, and account history should be fetched live from OlaOla only when credentials are configured and the user asks for it.
The only server-side state is short-lived process memory for anonymous shadow carts and authenticated request cookies. It is not durable and is not returned to the model.
Tools that modify the real OlaOla account cart require explicit confirmation. For planning, prefer shadow carts or quick-buy links until the user is ready to change their actual cart.
HTTP deployments are stateless per request. That is good for product lookup, product details, order history, account cart reads, account cart mutations, and quick-buy links. Anonymous shadow carts are best for local stdio or a single long-running local process; a globally deployed Worker should treat quick-buy links as the portable planning output unless a durable session store is added intentionally.
The server does not currently maintain its own indexed copy of the OlaOla catalogue. Product discovery uses live olaola.cz search, the public product sitemap, and then fetches details for selected products. This keeps the connector simple and fresh, but it is not as accurate as a proper product index with embeddings or RAG over product names, ingredients, descriptions, use cases, and composition tables.
The WP product-content data is available only as optional context. It can mention benefits, ingredients, and use cases, but it does not reliably expose the real product URL, variant ID, price, or cart identifier. Treat it as discovery context and verify real products through product pages and product details before recommending or buying.
Because of that, the best results usually come from asking the model to search a few focused angles, inspect promising product details, and then compare actual ingredient amounts instead of trusting the first search result.
supplement_intake: reusable intake prompt for supplement recommendation and cart audit workflows. It instructs the model to collect current supplements, doses, medications, relevant medical context, goals, diet/lifestyle, labs, and budget before making recommendations or checking combinations.
Prompts are client-invoked templates. They guide the model when used, but they do not replace application-level policy or validation.
The MCP process can create an anonymous OlaOla cart session for planning and comparison. The cookie stays inside the MCP process and is not shared with the user or the model.
With OLAOLA_EMAIL and OLAOLA_PASSWORD configured, the MCP can read the real OlaOla account cart live. It can also add products to the real cart, but only when the tool call includes confirmed=true.
The server can also generate an OlaOla quick-buy link such as:
https://www.olaola.cz/?quick-buy=43%2C16The user's browser creates its own cart after opening the link. No session cookie is shared.
MIT License
Copyright (c) 2026 bxxf
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Log into OlaOla with local env credentials, add a product to the real account cart, and return the updated cart. Requires confirmed=true.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | No | ||
| confirmed | Yes | ||
| variantId | No | ||
| productUrlOrSlug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits: it logs in with local credentials, adds a product (mutation), and requires confirmed=true. Since no annotations are provided, the description carries the full burden. It could mention whether the action is reversible or has rate limits, but the disclosure is adequate.
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 sentence, concise and front-loaded, covering the main actions. It avoids waste but could improve structure by separating parameters or adding a second sentence for clarity.
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 four parameters, no output schema, and the tool's complexity (authentication and mutation), the description is incomplete. It does not explain parameter roles, return value structure, or differentiate from sibling tools. Essential context is missing.
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 description provides no information about any of the four parameters (quantity, confirmed, variantId, productUrlOrSlug) beyond the required 'confirmed'. With schema description coverage at 0%, the description fails to compensate, leaving the agent without guidance on parameter usage.
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 the tool logs into OlaOla, adds a product to the real account cart, and returns the updated cart. It uses specific verb-resource combination ('add to account cart') and mentions the return value. However, it does not explicitly distinguish from the sibling tool 'olaola_add_to_cart', which likely has a different scope.
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 specifies that 'confirmed=true' is required, implying a precondition. However, no guidance is given on when to use this tool versus alternatives like 'olaola_add_to_cart' or 'olaola_add_to_shadow_cart'. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a product to the user's OlaOla cart. In auto mode, use the real account cart when credentials are configured; otherwise create/use a shadow cart. Real account cart changes require confirmed=true.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| cartId | No | ||
| quantity | No | ||
| confirmed | No | ||
| variantId | No | ||
| productUrlOrSlug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the conditional behavior of auto mode and the confirmed flag requirement for real cart changes. However, it omits many behavioral traits: whether adding is destructive (appends or replaces), authentication needs, rate limits, or side effects. The information provided is useful but incomplete.
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 concise (two sentences) and front-loads the main purpose. However, given the complexity (6 parameters, 3 modes), it sacrifices needed detail. It could be expanded without becoming verbose.
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 6-parameter tool with no output schema and no annotations, the description is highly incomplete. It does not explain the return value, error scenarios, or how the tool interacts with other cart operations. The presence of sibling tools increases the need for contextual guidance, which is lacking.
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 description coverage is 0%, so the description must explain all 6 parameters. It only mentions 'confirmed' indirectly and does not describe mode values, cartId, quantity, variantId, or productUrlOrSlug. This is a critical gap; the agent cannot understand how to populate the parameters 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 action ('Add a product to the user's OlaOla cart') and resource, and introduces three modes (auto, account, shadow) that distinguish behavior. However, it does not explicitly differentiate from sibling tools like olaola_add_to_account_cart or olaola_add_to_shadow_cart, which serve more specific purposes.
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 provides context for when auto mode is appropriate ('when credentials are configured' vs. shadow), and states that 'Real account cart changes require confirmed=true'. However, it does not give explicit guidance on when to use this unified tool versus the more specific sibling tools, nor does it 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.
Add a product variant or public product URL to an anonymous planning/simulation cart. Do not use this for the user's real cart; use olaola_add_to_cart or olaola_add_to_account_cart for that.
| Name | Required | Description | Default |
|---|---|---|---|
| cartId | Yes | ||
| quantity | No | ||
| variantId | No | ||
| productUrlOrSlug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states it adds to a shadow cart but doesn't disclose error behavior, idempotency, or lack of persistence. Adequate but lacks depth for a mutation tool.
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, front-loaded with key info, no fluff. Could be slightly improved by listing parameters, but still 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?
No output schema, 4 params with 0% coverage. Description misses return value, error cases, and parameter interplay. Incomplete for a tool with no other documentation.
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 0%. Description implies variantId or productUrlOrSlug but doesn't explain which is required or how they relate, nor does it describe cartId or quantity. Little added value over 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?
Description clearly states verb 'Add', resource 'product variant or public product URL to an anonymous planning/simulation cart', and distinguishes from siblings by specifying it is for shadow cart only.
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 'Do not use this for the user's real cart; use olaola_add_to_cart or olaola_add_to_account_cart for that', providing when-not and naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an anonymous OlaOla planning/simulation cart. Use only when the user wants a shadow cart or credentials are unavailable; the cookie stays internal to this MCP process.
| Name | Required | Description | Default |
|---|---|---|---|
| seedUrl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It states that the cookie stays internal to the MCP process and the cart is anonymous, which discloses key behavioral traits. However, it does not mention side effects or idempotency.
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 concise: a single sentence followed by a clause. It is front-loaded with the purpose and immediately provides usage guidance. Every word is necessary.
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 single parameter, no output schema, and no annotations, the description is fairly complete. It covers purpose, usage context, and a behavioral note. It could elaborate on return value or conflicts with existing carts, but is adequate for a creation 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?
The description does not explain the 'seedUrl' parameter beyond what the schema provides (format: uri). With 0% schema description coverage, the description should compensate but fails to add meaning to the parameter.
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 'Create an anonymous OlaOla planning/simulation cart,' which is a specific verb+resource combination. It distinguishes from sibling tools like olaola_add_to_shadow_cart, olaola_read_shadow_cart, and olaola_add_to_account_cart by emphasizing anonymity and creation.
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 use only when the user wants a shadow cart or credentials are unavailable, providing clear context. It does not explicitly mention alternatives or when not to use, but the 'only when' phrasing offers sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a public OlaOla quick-buy URL from variant IDs and/or product URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| variantIds | No | ||
| productUrlsOrSlugs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits, but it only states the action. It does not indicate whether this is a read or write operation, side effects, authentication needs, or any constraints. The lack of transparency is critical for a tool that generates a public URL.
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 sentence with no unnecessary words. It is concise and front-loaded with the action and resource. Every word serves a purpose.
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 absence of an output schema and annotations, the description is too sparse. It does not explain the nature of the returned URL, usage context, or potential errors. For a tool with two parameter arrays, more details are needed for safe and effective use.
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 description coverage is 0%, so the description must compensate. It mentions 'variant IDs and/or product URLs' but does not explain format, constraints (e.g., that variantIds must be positive integers), or that at least one input is likely required. The addition is minimal and insufficient for correct parameter usage.
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 verb 'Generate' and the resource 'public OlaOla quick-buy URL'. It also specifies the inputs ('variant IDs and/or product URLs'), making the tool's purpose distinct from siblings like olaola_add_to_cart. However, it does not explain what the quick-buy URL is used for, slightly reducing clarity.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., olaola_add_to_cart or olaola_search_products). There is no mention of scenarios where a quick-buy URL is needed, prerequisites, or when not to use it. This leaves the agent uncertain about context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether OlaOla account credentials are configured and whether login succeeds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full behavioral burden. It explains the tool checks configuration and login success, implying a read-only operation with no side effects. Could be clearer about return values, but sufficient.
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?
Single sentence, front-loaded, no wasted words. Every word 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?
No output schema, and description doesn't mention return format or potential error conditions. Given the tool's simplicity, it's adequate but could be more complete about what 'success' means or error handling.
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?
No parameters exist in the schema, so baseline is 4. The description doesn't add parameter info, but that's appropriate given no parameters.
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 checks credential configuration and login success. It uses specific verb 'check' and resource 'OlaOla account credentials'. It distinguishes from siblings that handle orders, carts, products, etc.
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?
No explicit guidance on when to use this tool vs alternatives. It implies use before other operations to verify auth, but no when-not-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log into OlaOla with local env credentials and fetch one order detail.
| Name | Required | Description | Default |
|---|---|---|---|
| orderNumber | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description mentions 'Log into OlaOla' which suggests an authentication side-effect not explained. It does not clarify if the operation is read-only or has other side effects.
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 short but includes unnecessary detail ('Log into OlaOla with local env credentials') that adds length without clarity. The core purpose is efficient, but could be trimmed.
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 1 parameter and no output schema, the description lacks details on response structure, error handling, or prerequisites. It feels incomplete for a single-order fetch 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?
The parameter 'orderNumber' has no description in schema or tool description. With 0% schema coverage, the description does not compensate by explaining format, source, or constraints.
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 'fetch one order detail', specifying the verb and resource. It distinguishes from siblings like 'olaola_get_order_history' which suggests multiple records.
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 implies use for fetching a single order, but does not explicitly state when to use versus alternatives like 'get_order_history' or any prerequisites beyond implicit login.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log into OlaOla with local env credentials and fetch account order summaries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions login with local credentials, which is important behavioral info. But it doesn't disclose side effects, rate limits, or behavior if not authenticated.
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 sentence that front-loads the action. However, 'Log into OlaOla' could be misinterpreted as performing login vs. requiring prior auth, slightly reducing clarity.
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, so description should explain return values. It only says 'fetch account order summaries', which is vague. The tool has 0 params and no nested objects, but the return information is insufficient.
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?
No parameters exist, so schema coverage is 100% and description adds no parameter info. Baseline for 0 params is 4, and nothing is needed beyond what's already clear.
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 fetches account order summaries, distinguishing it from siblings like olaola_get_order_detail for specific orders. However, it could be more specific about what summaries include.
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?
No guidance on when to use this tool vs alternatives like olaola_get_order_detail or olaola_get_auth_status. The description implies it requires prior authentication but doesn't clarify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and normalize public OlaOla product facts from a URL or product slug.
| Name | Required | Description | Default |
|---|---|---|---|
| urlOrSlug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'normalize' but does not explain what normalization entails, nor does it disclose any side effects, authentication needs, or rate limits. The 'public' hint is minimal.
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?
One sentence, no redundant words. Clearly states purpose and input type.
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 tool with no output schema, no annotations, and only one parameter, the description is too minimal. It does not describe return values, what 'normalize' means, or any other behavioral details needed for an agent to use it confidently.
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 single parameter 'urlOrSlug' is given context in the description ('from a URL or product slug'), which adds meaning beyond the schema's minLength constraint. However, no format details are provided, and schema coverage is 0%, so the description only partially compensates.
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 specifies the action ('Fetch and normalize'), the resource ('public OlaOla product facts'), and the input source ('from a URL or product slug'). It differentiates from sibling tools by focusing on 'public product facts' and normalization, though the presence of 'olaola_get_product_details' could cause 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?
No explicit guidance on when to use this tool versus alternatives like 'olaola_get_product_details' or search tools. The description implies use for fetching product facts from a URL or slug, but lacks conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch normalized product facts plus OlaOla specification and usage modal text, including composition, ingredient amounts, warnings, and dosing when available.
| Name | Required | Description | Default |
|---|---|---|---|
| urlOrSlug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. The description only states what data is fetched but does not disclose whether it is read-only, requires authentication, or has any side effects.
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 sentence, which is concise, but it lists many items making it a bit dense. It is adequately structured but not exceptionally concise.
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 one parameter and no output schema, the description covers the main purpose reasonably well. However, it lacks explanation of parameter format and error conditions, which are important for a complete definition.
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 description coverage is 0%. The only parameter 'urlOrSlug' is not explained in the description; it is unclear whether it expects a URL or a slug. The description adds no meaning beyond 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 clearly states it fetches normalized product facts plus OlaOla specification and usage modal text, including specific fields like composition, warnings, dosing. This distinguishes it from sibling tools like olaola_get_product (likely simpler) and olaola_search_products.
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 provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where a simpler fetch (olaola_get_product) would suffice or when to use search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log into OlaOla with local env credentials and read the real account cart.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. It states that the tool logs into OlaOla using local env credentials, but it does not clarify whether the tool is read-only, what side effects (if any) occur, or what happens upon failure (e.g., if credentials are invalid). The behavioral disclosure is insufficient.
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 sentence that is front-loaded with the action and resource. Every word is necessary; there is no redundancy or fluff. It is appropriately concise.
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?
The tool has no parameters and no output schema. The description fails to describe the return value or what the 'real account cart' contains (e.g., items, quantities, prices). Given the absence of an output schema, the description should provide enough context for the agent to understand the output, but it does not. The sibling context is also not leveraged for differentiation.
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 input schema has zero parameters, and schema description coverage is 100% by default. The description adds context by mentioning 'local env credentials', which are not formal parameters but are relevant for usage. Since there are no parameters, the baseline is 4, and the description adequately addresses the implicit credential requirement.
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 action ('read') and resource ('real account cart'). The mention of 'real account cart' hints at a distinction from the shadow cart sibling, but it does not explicitly differentiate from similar tools like 'olaola_read_shadow_cart'. This is a minor gap.
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?
No guidance is provided on when to use this tool versus alternatives such as 'olaola_read_shadow_cart' or 'olaola_add_to_account_cart'. The description does not include when-not-to-use scenarios or prerequisites beyond mentioning credentials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the latest normalized snapshot of an anonymous shadow cart.
| Name | Required | Description | Default |
|---|---|---|---|
| cartId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only says 'read', implying idempotence, but lacks details on side effects, rate limits, auth requirements, or handling of non-existent cartId.
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 clear sentence. It is concise, though it could be expanded with necessary details without becoming verbose.
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?
The tool has one required parameter, no output schema, and no annotations. The description lacks information about return values, error conditions, and whether the cart must exist. It is incomplete for an agent to successfully invoke the 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 description coverage is 0%. The description does not explain the 'cartId' parameter beyond what the schema states (UUID format). No additional meaning or context is provided.
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 'Read' and the resource 'normalized snapshot of an anonymous shadow cart'. It distinguishes from sibling tools like olaola_read_account_cart by specifying 'shadow cart'.
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?
No guidance is provided on when to use this tool versus alternatives like olaola_read_account_cart or write tools. No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an existing OlaOla cart line item. Read the cart first, then pass the item's cartItemId. In auto mode, use the real account cart when credentials work; real cart changes require confirmed=true.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| cartId | No | ||
| confirmed | No | ||
| cartItemId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses destructive nature, mode behavior, and confirmed flag necessity, but fails to explain account and shadow modes or return value/error handling.
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 concise sentences front-load the purpose with no wasted words, efficiently conveying the core usage.
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?
While it covers basic workflow, no output schema and missing details on error states, return values, and full mode explanations make it incomplete for fully autonomous agent use.
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 0%, so description must compensate. It explains cartItemId source and mode/confirmed meaning for auto, but does not describe cartId or other mode semantics, leaving gaps.
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 ('Remove an existing OlaOla cart line item') and identifies the specific resource, differentiating it from sibling tools like add or update.
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?
It provides clear guidance: read the cart first, use the cartItemId, and explains auto mode behavior and confirmed flag. However, it does not explicitly state when not to use this tool or directly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public OlaOla WP product_content entries for supplemental text context. Use short Czech queries such as energie, únava, hořčík, psychická pohoda, ashwagandha. Results are text context only, not directly cartable products.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| queries | No | ||
| maxHints | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear full burden. It states results are text context only, but does not disclose authentication requirements, rate limits, response format, or whether the search is read-only. This leaves significant behavioral gaps.
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 two concise sentences with no wasted words, front-loading purpose and then providing usage hints. It earns its sentences.
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 annotations, no output schema, and 0% schema description coverage, the description should be more complete. It lacks details on response format, search behavior (e.g., fuzzy matching), and does not fully explain all parameters. Incomplete for agent decision-making.
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?
With 0% schema description coverage, the description adds some meaning by suggesting short Czech queries, but does not explain the maxHints parameter or the distinction between query and queries. Important parameter semantics remain undocumented.
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 searches public OlaOla WP product_content entries for supplemental text context, distinguishes it from product search tools by noting results are text context only and not directly cartable, and provides example Czech queries.
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 advises using short Czech queries and explains the type of input expected, guiding the agent on appropriate usage. It lacks explicit when-not-to-use or alternatives, but the context from sibling tools helps differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search OlaOla for real product candidates using storefront search plus the product sitemap. Product candidates can be opened, inspected, or added to carts. WP product-content context is disabled by default and must be explicitly requested.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | ||
| maxPerQuery | No | ||
| includeContentHints | No | ||
| maxContentHintsPerQuery | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the source method and the default disabling of content hints, which is useful. However, it does not mention auth requirements, rate limits, side effects, or output behavior beyond candidates being inspectable/addable.
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 concise sentences with front-loaded purpose: first sentence defines the action and method, second sentence states capabilities, third adds a behavioral default. No filler 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?
Given 4 parameters, no output schema, and no annotations, the description is incomplete. It lacks parameter details, output format, and guidance on inputs like queries or maxPerQuery. The sibling context hints at complementary tools but the description doesn't leverage that.
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 has 4 parameters with 0% description coverage. The description only explains includeContentHints ('disabled by default, must be explicitly requested'). It does not explain queries, maxPerQuery, or maxContentHintsPerQuery. This leaves significant gaps for agent understanding.
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 the verb 'search' and the resource 'real product candidates' using specific methods (storefront search and product sitemap). It distinguishes itself from siblings like olaola_search_product_content and olaola_get_product by specifying the search source and that candidates can be opened/inspected/added to carts.
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?
Description implies usage for searching product candidates but does not explicitly state when to use this tool vs alternatives like olaola_get_product or olaola_search_product_content. It provides one guideline (WP content context disabled by default) but no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the quantity for an existing OlaOla cart line item. Read the cart first, then pass the item's cartItemId. In auto mode, use the real account cart when credentials work; real cart changes require confirmed=true.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| cartId | No | ||
| quantity | Yes | ||
| confirmed | No | ||
| cartItemId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions that real cart changes require confirmed=true, implying mutability, but does not disclose idempotency, destructive nature, authorization needs, or error states. Partial coverage.
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 with key steps, no redundancy. Could be more structured (e.g., bullet points) but remains clear 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?
Provides basic workflow but lacks details on success/error responses, mode differences, and cartId usage. With 5 parameters and no output schema or annotations, the description should be more comprehensive.
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 description coverage is 0%, so description must compensate. It adds meaning for cartItemId (read first) and confirmed (real cart requirement) and mode (auto mode behavior). However, cartId and quantity parameters are not elaborated. Partial but not full compensation.
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 ('Set the quantity') and resource ('existing OlaOla cart line item'), using specific verbs and distinguishing from sibling tools like add_to_cart or remove_from_cart.
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 explicit workflow: 'Read the cart first, then pass the item's cartItemId.' Also explains mode behavior and the confirmed parameter requirement for real cart changes. Lacks explicit when-not-to-use or alternatives, but sufficient guidance.
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.
v0.1.0olaola_add_to_account_cartolaola_add_to_cartolaola_add_to_shadow_cartolaola_create_shadow_cartolaola_generate_quick_buy_urlolaola_get_auth_statusolaola_get_order_detailolaola_get_order_historyolaola_get_productolaola_get_product_detailsolaola_read_account_cartolaola_read_shadow_cartolaola_remove_from_cartolaola_search_product_contentolaola_search_productsolaola_update_cart_itemTools are mostly distinct but some overlap exists between cart addition tools (add_to_cart, add_to_account_cart, add_to_shadow_cart). Descriptions help clarify, but an agent might still select incorrectly without careful reading.
All tools use a consistent `olaola_` prefix followed by a verb_noun pattern (e.g., get_product, add_to_cart, read_shadow_cart). Minor variation between 'get' and 'read' is acceptable as they differentiate types of operations.
16 tools is well-scoped for an e-commerce supplemental store MCP. Each tool serves a distinct purpose across authentication, orders, cart management, product info, and search, without being overwhelming.
Covers core CRUD for cart, product retrieval and search, order history, and shadow cart. Minor gaps like lack of checkout or user profile tools, but these are optional for the server's stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect your wearables, rings and training apps, then ask your AI about your own health data.
Connect e-commerce and marketing data to AI assistants via MCP.
Connect your Oura Ring account securely in minutes. Enable authorized access to your sleep, activi…
Supplement research, biomarker effects, drug interactions, and brand quality data
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bxxf/olaola-supplement-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
