citadelle-mcp

generate_trade_link

Generates a secure URL that opens the Citadelle web UI with the selected market and action, enabling the user to execute an option trade directly.

Instructions

Generates a URL that redirects the user to the web UI to securely execute an option trade.

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": {
      "marketId": "<marketId>",
      "action": "<action>"
    },
    "name": "generate_trade_link"
  }
}

Input Schema

Name	Required	Description	Default
`action`	Yes	The action to perform: 'buy_call', 'sell_call', 'buy_put', 'sell_put'
`marketId`	Yes	The EVM address of the Market

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.3Sep 7, 2026

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It states that the tool only generates a URL and that the trade is executed in the web UI, which rules out direct execution. However, it does not disclose whether authentication is required, whether the link is one-time, or what happens on invalid inputs.

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?

A single, front-loaded sentence states the action and outcome without fluff. Every word contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with full schema coverage, the description is nearly complete. It specifies the output (a URL), the redirect target, and the trade context. It could add error or authentication behavior, but nothing essential is missing for selecting and invoking it 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%, so the schema already documents marketId and action, including the allowed action values. The description adds only the high-level context of an option trade and does not further clarify parameter semantics; baseline 3 is appropriate.

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 ('Generates') and a clear resource ('a URL that redirects the user to the web UI to securely execute an option trade'). This is immediately distinguishable from the read-only sibling tools, which fetch market liquidity and wallet portfolio data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly conveys the use case: when the user needs to initiate an option trade through the web UI, this tool produces the redirect URL. It does not name other tools or give explicit when-not-to-use guidance, but the siblings are sufficiently unrelated that the context alone is clear.

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

Deploy Server