OlaOla Supplement MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.3/5 across 16 of 16 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
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.
Conciseness5/5
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description 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.
Parameters2/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and the resource '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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![olaola-supplement-mcp MCP server](https://glama.ai/mcp/servers/bxxf/olaola-supplement-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bxxf/olaola-supplement-mcp)

Score Badge

Copy to your README.md:

[![olaola-supplement-mcp MCP server](https://glama.ai/mcp/servers/bxxf/olaola-supplement-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bxxf/olaola-supplement-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bxxf/olaola-supplement-mcp'

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