Skip to main content
Glama

Create an AkulaCyber cart link

akulacyber_create_cart_link
Read-onlyIdempotent

Create a link to the AkulaCyber store cart with the chosen products and quantities already in it, at live prices in UAH, for the user to open, review and check out on the site. Use it when the user is ready to buy or wants several products in one cart; identify products with akulacyber_search_products first, and for a single piece of one product the cart_url of akulacyber_get_product is enough. Nothing is ordered, reserved or paid here. Repeated products are added together (at most 99 each); out-of-stock products are left out and listed in unavailable; an unknown product, or none in stock, returns an error.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "items": "<items>"
    },
    "name": "akulacyber_create_cart_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoLanguage of the texts and page URLs in the answer: uk (Ukrainian, the default), ru (Russian) or en (English). Use the language the user writes in.uk
itemsYesOne to ten products, e.g. [{"product": "gl-rm1", "quantity": 2}, {"product": "gl-atx"}].

Output Schema

NameRequiredDescriptionDefault
urlYes
linesYes
currencyYes
unavailableYes
goods_total_uahYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint and idempotentHint true, and the description reinforces this with 'Nothing is ordered, reserved or paid here', which resolves the otherwise ambiguous question of whether a 'create' call causes side effects. It goes further with concrete edge-case behavior: duplicates merged with a 99-per-product cap, out-of-stock items omitted and reported in 'unavailable', and errors for unknown or fully unavailable products.

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 tight sentences: purpose first, routing second, behavioral caveats last. Every clause carries information an agent needs — there is no restatement of the name or title and no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still names the 'unavailable' field and the error cases, which is exactly the extra context an agent needs to set user expectations. For a 2-parameter, flat-schema tool this leaves nothing material missing.

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?

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine semantics not in the schema — that repeated product entries are summed rather than treated as separate lines, and that out-of-stock items are silently dropped rather than rejected. It does not add format detail for the lang enum, which the schema already covers well.

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?

States a specific verb and resource — creating a store cart link pre-filled with chosen products and quantities, at live UAH prices — and makes clear it is a link for the user to open and check out on the site. That distinguishes it cleanly from akulacyber_get_product and akulacyber_search_products without needing their schemas.

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?

Gives explicit when-to-use ('ready to buy or wants several products in one cart'), a prerequisite ('identify products with akulacyber_search_products first'), and a named alternative with its selecting condition ('for a single piece of one product the cart_url of akulacyber_get_product is enough').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources