Gogi

Create and Start Algorithm

create_and_start_algo

Destructive

Create algo + instance + start trading. REQUIRED: call list_brokers first, show display_label (broker · paper/demo|live · •••••last5), get the user's explicit choice, then pass that row's integer id as broker_account_id. Prefer paper/demo unless the user confirms live. Use the strategy the user (or this conversation) specified. If indicators/entry conditions were not specified, ASK — do NOT invent EMA 9/21 or any favorite indicator pair. Only pick a concrete template when the user explicitly invites you (e.g. 'you pick', 'surprise me'); then prefer diverse types such as RSI(14), MACD, SMA 50/200, or EMA 12/26 — never always the same MA pair. ALWAYS ask for capital_allocation (dollar amount from broker buying power). Cumulative allocated capital across this agent's live algos must stay ≤ policy max_total_capital. For risk, prefer the user's own numbers in strategy_params.risk (stopLossPercentage, takeProfitPercentage, riskPercentage, maxDrawdown) — those override presets. Optional risk_preset conservative|moderate|aggressive is only a shortcut when the user does not give custom numbers. Optionally risk_advanced for trailing stop / pyramiding. First call with confirm_allocation=false; on allocation_requires_confirm show broker_equity, allocation_pct_of_equity, warning_level, and risk summary; after explicit user OK retry with confirm_allocation=true (acknowledge_capital_risk still accepted as alias). On success present Instance Setup Details: instance, strategy, symbols, timeframe, broker, capital vs equity %, risk numbers, live status.

Input Schema

TableJSON Schema

Name	Required	Description
`risk`	No	Optional explicit risk: stopLossPercentage, takeProfitPercentage, riskPercentage, maxDrawdown. Overrides risk_preset when complete.
`symbols`	Yes	List of tickers to trade (e.g. ['BTC-USD'])
`algo_name`	Yes	The name of the algorithm strategy
`timeframe`	Yes	Strategy timeframe (e.g., '1m', '5m', '1h')
`risk_preset`	No	Optional shortcut: conservative \| moderate \| aggressive. Skip if strategy_params.risk has full custom numbers.
`instance_name`	No	Optional custom name for the started trading instance
`risk_advanced`	No	Optional if user wants advanced: trailingStopEnabled, trailingStopAmount, allowPyramiding, maxPyramidPositions
`strategy_params`	Yes	Required shape: { strategy_type: 'RSI_OVERSOLD_OVERBOUGHT' \| 'MA_CROSSOVER' \| 'MACD' \| 'BOLLINGER_BANDS' \| 'CUSTOM' \| ..., indicators: [{type: 'RSI'\|'SMA'\|'EMA'\|'MACD'\|..., period: number}], entryConditions: { buyConditions: [{indicator1: {type, period}, relationship: 'Crosses above'\|'Above'\|..., indicator2: {type, period}}], sellConditions: [...] }, risk: {stopLossPercentage, takeProfitPercentage, riskPercentage, maxDrawdown} }. At least one of buyConditions or sellConditions must be non-empty. movingAverages is accepted as an alias for indicators. Example indicator sets (do not default to one): RSI period 14; SMA 50+200; EMA 12+26; MACD; Bollinger length 20. Never invent EMA 9/21 when unspecified.
`algo_description`	No	Optional description of the algorithm
`broker_account_id`	Yes	Integer `id` from list_brokers for the account the user picked. Not the broker's external account number.
`capital_allocation`	Yes	USD capital from broker buying power. Ask the user — never invent.
`confirm_allocation`	No	true only after the user accepts capital vs live equity and the risk settings.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`message`	No
`success`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedSep 13, 2026
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / buyConditions / description
```
Added value: +"Optional list of conditions that must be satisfied to open or buy."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / buyConditions / items / properties / indicator1 / description
```
Added value: +"First indicator in the comparison."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / buyConditions / items / properties / indicator1 / properties / period / description
```
Added value: +"Indicator period length."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / buyConditions / items / properties / indicator1 / properties / type / description
```
Added value: +"Indicator type, such as RSI, SMA, EMA, or MACD."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / buyConditions / items / properties / indicator2 / description
```
Added value: +"Second indicator or comparison value."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / buyConditions / items / properties / indicator2 / properties / period / description
```
Added value: +"Indicator period length."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / buyConditions / items / properties / indicator2 / properties / type / description
```
Added value: +"Indicator type, such as RSI, SMA, EMA, or MACD."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / sellConditions / description
```
Added value: +"Optional list of conditions that must be satisfied to close or sell."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / sellConditions / items / properties / indicator1 / description
```
Added value: +"First indicator in the comparison."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / sellConditions / items / properties / indicator1 / properties / period / description
```
Added value: +"Indicator period length."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / sellConditions / items / properties / indicator1 / properties / type / description
```
Added value: +"Indicator type, such as RSI, SMA, EMA, or MACD."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / sellConditions / items / properties / indicator2 / description
```
Added value: +"Second indicator or comparison value."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / sellConditions / items / properties / indicator2 / properties / period / description
```
Added value: +"Indicator period length."
```
- addedInput schema / properties / strategy_params / properties / entryConditions / properties / sellConditions / items / properties / indicator2 / properties / type / description
```
Added value: +"Indicator type, such as RSI, SMA, EMA, or MACD."
```
- changedOutput schema / description
```
Previous value: -"Structured Gogi result. Error responses include error and message fields."New value: +"Structured result. Error responses include error and message."
```
- addedOutput schema / properties
```
Added value: +{
+  "error": {
+    "type": "string"
+  },
+  "message": {
+    "type": "string"
+  },
+  "success": {
+    "type": "boolean"
+  }
+}
```

Changed1 schema field changedSep 13, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured Gogi result. Error responses include error and message fields.",
+  "type": "object"
+}

First observedSep 13, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only flag destructiveHint/openWorldHint/non-idempotent; the description adds substantial behavior beyond that: a two-phase confirmation flow (first confirm_allocation=false, then retry with true after explicit OK), the allocation_requires_confirm response fields to surface, the policy max_total_capital ceiling on cumulative live allocation, and the risk-override semantics. This is exactly the context the annotations cannot convey for a live-money mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical constraint is front-loaded in sentence one, but the body is a dense wall of text that repeats the 'do not invent EMA 9/21' instruction already present in the schema, and stacks many workflow rules without visual grouping. Content mostly earns its place, yet the piece would be more usable if structured into labeled steps.

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 high-complexity, 12-parameter mutation with nested objects, an output schema already covers return values, and the description fills the remaining gaps: preconditions, confirmation choreography, policy limits, and risk precedence. Nothing an agent needs to invoke this correctly appears missing.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning: confirm_allocation is tied to the two-step confirmation flow, broker_account_id must be the integer id from list_brokers (not the external account number), and capital_allocation must come from broker buying power. The risk-vs-risk_preset override relationship is explained, though a few optional params (instance_name, risk_advanced specifics) are left to the schema.

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 opening sentence 'Create algo + instance + start trading' states a specific composite action across three resources, which cleanly distinguishes it from the single-purpose siblings create_algo, create_instance, and start_instance. An agent can tell what this tool produces without opening the 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?

The description gives explicit when/when-not rules: call list_brokers first and get an explicit choice before passing broker_account_id, prefer paper/demo unless the user confirms live, ask rather than invent indicators, only pick a template when the user explicitly invites it, and prefer custom risk numbers over presets. It also names the alternative path (risk_preset) and the condition that selects it.

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

All Gogi 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?