Skip to main content
Glama
luno

Luno MCP Server

Official
by luno
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
Go
Remote

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.3
  2. Removedv0.6.2
  3. Changed5 schema fields changedv0.6.1
    • changedInput schema / properties / pair / description
      Previous value: -"Trading pair (e.g., XBTZAR)"New value: +"Trading pair using Luno's symbol convention (e.g. XBTZAR for BTC/ZAR, ETHZAR, XBTEUR). BTC is automatically rewritten to XBT."
    • changedInput schema / properties / price / description
      Previous value: -"Limit price as a decimal string"New value: +"Limit price in the counter currency, as a decimal string (e.g. \"500000\"). Must align with the market's tick size; check get_markets_info."
    • changedInput schema / properties / type / description
      Previous value: -"Order type (BUY or SELL)"New value: +"Side of the order. BUY = bid (buy the base currency with the counter currency); SELL = ask (sell the base currency for the counter currency)."
    • changedInput schema / properties / volume / description
      Previous value: -"Order volume (amount of cryptocurrency to buy or sell)"New value: +"Order 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."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "order_id": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "order_id"
+  ],
+  "type": "object"
+}
  4. First observed

TDQS

A4.9/5.0
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.

Deploy Server

Other Tools