Skip to main content
Glama

Get AkulaCyber store terms

akulacyber_get_store_policy
Read-onlyIdempotent

Return one AkulaCyber information page as published, in Markdown, with its page URL and the store's telephone, email and contacts page. Use it for questions about delivery cost, payment methods, warranty, returns, the terms of sale, privacy or who runs the store; for ship and delivery dates use akulacyber_estimate_delivery, and for branches or lockers akulacyber_find_delivery_points. Choose topic delivery-and-payment for delivery cost and payment, warranty-and-returns for warranty and returns, public-offer for the terms of sale, privacy-policy for personal data, about for the seller; lang picks the language version of the page.

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": {
      "topic": "<topic>"
    },
    "name": "akulacyber_get_store_policy"
  }
}

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
topicYesdelivery-and-payment: delivery methods and cost, same-day cut-off, payment methods and bank details; warranty-and-returns; public-offer: the terms of sale; privacy-policy; about: the seller and contacts.

Output Schema

NameRequiredDescriptionDefault
urlYes
textYes
emailYes
titleYes
summaryYes
telephoneYes
contacts_urlYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / lang / description
      Previous value: -"Language of the answer: uk (Ukrainian), ru (Russian) or en (English). Use the language of the user."New value: +"Language 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."
    • changedInput schema / properties / topic / description
      Previous value: -"Which page to return."New value: +"delivery-and-payment: delivery methods and cost, same-day cut-off, payment methods and bank details; warranty-and-returns; public-offer: the terms of sale; privacy-policy; about: the seller and contacts."
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety needs no restating. The description adds behavior beyond that: the page is returned 'as published' in Markdown alongside its URL and the store's phone/email/contacts page. It does not mention auth or any per-topic truncation, which keeps it short of a 5.

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 purpose and output format are front-loaded, and every clause maps to a real decision (which intent, which topic, which sibling). It is a single dense run-on paragraph, and the topic enumeration partly duplicates the schema, so it is efficient but not perfectly trimmed.

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?

With an output schema present, the description need not explain return values, and it still summarizes what comes back (page content, URL, contacts). For a two-parameter, read-only retrieval tool, purpose, selection guidance and the sibling boundary are all covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are enums with their own descriptions, so the schema carries most of the meaning. The description's topic-to-intent mapping largely restates the schema enum text, adding only mild phrasing like 'privacy-policy for personal data'; baseline 3 applies.

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 states a specific verb and resource ('Return one AkulaCyber information page') plus the output format (Markdown, with page URL and the store's telephone, email and contacts page). It also differentiates itself from two named siblings, so an agent can tell it apart without opening other 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?

It gives explicit when-to-use coverage (delivery cost, payment, warranty, returns, terms of sale, privacy, seller) and explicitly routes two adjacent intents elsewhere: ship/delivery dates to akulacyber_estimate_delivery and branches/lockers to akulacyber_find_delivery_points. It then maps each intent to the correct topic value, leaving nothing to inference.

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