AkulaCyber

Estimate AkulaCyber dispatch and delivery

akulacyber_estimate_delivery

Read-onlyIdempotent

Estimate whether an AkulaCyber order placed now ships today and between which dates Nova Poshta usually delivers it, from the current time in Kyiv and the store's same-day cut-off: 17:30 Monday to Friday, 16:30 on Saturday and Sunday. Use it when the user asks when an order would ship or arrive; for delivery points use akulacyber_find_delivery_points, and for delivery cost and payment methods akulacyber_get_store_policy. Delivery usually takes 1 to 3 days after shipping; dates are YYYY-MM-DD. Public holidays are not known to it, and orders paid by bank transfer ship only once the money arrives.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "akulacyber_estimate_delivery"
  }
}

Input Schema

Name	Required	Description	Default
`lang`	No	Language of the delivery terms text in the answer: uk (the default), ru or en.	uk

Output Schema

Name	Required	Description	Default
`now_kyiv`	Yes
`ship_date`	Yes
`ships_today`	Yes
`today_cutoff`	Yes
`delivery_terms`	Yes
`ship_date_cutoff`	Yes
`usual_delivery_to`	Yes
`delivery_terms_url`	Yes
`usual_delivery_from`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the safety profile, but the description adds substantial behavior beyond them: the exact cut-off schedule (17:30 Mon–Fri, 16:30 Sat–Sun), the Kyiv timezone basis, the 1–3 day post-shipping window, a YYYY-MM-DD date format, the holiday blind spot, and the bank-transfer shipping delay. These are exactly the caveats an agent needs to interpret an estimate honestly.

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 core purpose and cut-off facts are front-loaded, and the sibling routing arrives before the trailing caveats. The first sentence is dense — a timezone, a schedule, and a date-format all compressed into one clause chain — costing it a perfect score, but nothing is redundant.

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, and the remaining complexity (timezone-relative cut-off logic, holiday gaps, payment-dependent dispatch) is fully disclosed. An agent has everything needed to call it with zero arguments or override lang correctly.

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 100% and the single 'lang' parameter carries its own enum values and default, so the description need not restate it — baseline 3 applies. It adds no syntax or format detail beyond the schema, though it does implicitly frame the answer as containing 'delivery terms text', which hints at what lang affects.

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 (estimate) and a precise resource/outcome: whether an order placed now ships today and which dates Nova Poshta delivers. It also embeds the inputs used for the estimate (current Kyiv time, same-day cut-off), so an agent can immediately tell this apart from the policy and delivery-point siblings.

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 names the trigger ('when the user asks when an order would ship or arrive') and routes two other intents to named alternatives: akulacyber_find_delivery_points for delivery points and akulacyber_get_store_policy for cost and payment methods.

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

All AkulaCyber tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?