AkulaCyber

Find Nova Poshta delivery points

akulacyber_find_delivery_points

Read-onlyIdempotent

Find Nova Poshta branches and parcel lockers in a Ukrainian city where an AkulaCyber order can be collected, from the directory the checkout uses. Use it when the user asks where to collect an order or which point is near them; for ship and delivery dates use akulacyber_estimate_delivery, and for delivery cost and payment akulacyber_get_store_policy. If the city name matches several places, the result lists them; call again with city_ref. At most 30 points come back; more_points true means there are more, so narrow with query. An unknown city returns an error.

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_find_delivery_points"
  }
}

Input Schema

Name	Required	Description	Default
`city`	No	City or village name in Ukrainian, Russian or English, e.g. "Київ", "Odesa", "Lviv". Give city or city_ref.
`lang`	No	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.	uk
`type`	No	branch for Nova Poshta branches, locker for parcel lockers, all for both (the default).	all
`query`	No	A branch or locker number (160) or part of the address (a street name) to narrow the list.
`city_ref`	No	The ref of a city from the cities list of an earlier result, to pick one of several matches.

Output Schema

Name	Required	Description	Default
`city`	No
`cities`	No
`points`	No
`more_points`	No
`delivery_terms`	Yes
`delivery_terms_url`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 10, 2026

changedInput schema / properties / city / description

Previous value: -"City or village name, e.g. \"Київ\", \"Odesa\", \"Lviv\"."New value: +"City or village name in Ukrainian, Russian or English, e.g. \"Київ\", \"Odesa\", \"Lviv\". Give city or city_ref."

changedInput schema / properties / city_ref / description

Previous value: -"Nova Poshta city ref from an earlier result."New value: +"The ref of a city from the cities list of an earlier result, to pick one of several matches."

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 / query / description

Previous value: -"Branch or locker number, or part of the address."New value: +"A branch or locker number (160) or part of the address (a street name) to narrow the list."

changedInput schema / properties / type / description

Previous value: -"branch for Nova Poshta branches, locker for parcel lockers, all for both."New value: +"branch for Nova Poshta branches, locker for parcel lockers, all for both (the default)."

First observedNov 9, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile needs no restating. The description adds real behavioral context beyond them: a 30-item cap, a more_points truncation flag, ambiguity handling via city_ref, and an error on unknown city. It stops short of describing result contents, but an output schema exists to carry that.

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 purpose leads, sibling routing follows, and the edge cases (multiple city matches, truncation, unknown city) come last in short declarative sentences. Every sentence carries distinct information with no restatement of the title or annotations.

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?

For a read-only lookup with full schema coverage, annotations, and an output schema, everything an agent needs to call it correctly is present: when to use it, how to disambiguate, how to paginate, and what failure looks like. Nothing material is left to inference.

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 operational meaning: city_ref is specifically for resolving multi-match city names, and query is the narrowing mechanism when results are truncated. It does not explain lang or the branch/locker distinction, which the schema already handles.

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 uses a specific verb and resource ('Find Nova Poshta branches and parcel lockers in a Ukrainian city where an AkulaCyber order can be collected') and explicitly distinguishes itself from akulacyber_estimate_delivery and akulacyber_get_store_policy. An agent can identify the tool and separate it from its siblings without opening any schema.

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 trigger conditions ('when the user asks where to collect an order or which point is near them') and routes competing questions to the correct sibling by name, covering dates and cost/payment. It also explains the follow-up paths: call again with city_ref when several cities match, and narrow with query when more_points is true.

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?