Skip to main content
Glama
luno

Luno MCP Server

Official
by luno

create_order

Place a GTC limit order on the Luno exchange. The order stays on the order book and can fill partially or not at all; use list_orders to monitor its status.

Instructions

Place a new GTC limit order on Luno. The order rests on the book and may fill partially, fully, or not at all; this tool does not wait for or report fills - use list_orders to inspect state, or cancel_order to withdraw a working order. Not idempotent: repeated calls create duplicate orders. Prefer get_markets_info first to validate the pair's tick size and minimum volume. Write operation: requires the --allow-write-operations flag or ALLOW_WRITE_OPERATIONS=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pairYesTrading pair using Luno's symbol convention (e.g. XBTZAR for BTC/ZAR, ETHZAR, XBTEUR). BTC is automatically rewritten to XBT.
priceYesLimit price in the counter currency, as a decimal string (e.g. "500000"). Must align with the market's tick size; check get_markets_info.
typeYesSide of the order. BUY = bid (buy the base currency with the counter currency); SELL = ask (sell the base currency for the counter currency).
volumeYesOrder volume in the base currency, as a decimal string (e.g. "0.001"). Must meet the market's minimum volume and step size; check get_markets_info.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
order_idYes
Behavior5/5

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

The description adds significant behavioral context beyond annotations: non-idempotence, fill behavior (partial/full/none), and write-operation requirement. It complements the readOnlyHint=false and idempotentHint=false annotations, without contradiction.

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 four sentences, front-loaded with the core purpose. Every sentence earns its place, covering behavior, guidance, and prerequisites without redundancy. Highly concise and well-structured.

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?

Given the tool's complexity (limit order, non-idempotent, write operation), the description covers all critical aspects: order type, fill behavior, state inspection, cancellation, validation, and required flag. It is complete and self-contained.

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%, but the description adds value by explaining the order type (GTC), pair rewrite rule (BTC to XBT), and validation hints (tick size, minimum volume). This extra context justifies a score above baseline 3.

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 places a new GTC limit order on Luno, distinguishing it from sibling tools like list_orders and cancel_order. The verb 'place' and resource 'limit order' are specific, and the detailed behavior of partial/full fills further clarifies purpose.

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?

The description explicitly tells when to use this tool (placing a limit order), when not to (use list_orders for state, cancel_order to withdraw), and suggests a prerequisite (get_markets_info for validation). It also notes the require write flag, providing complete usage context.

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

Install Server

Other Tools

Latest Blog Posts

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/luno/luno-mcp'

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