Gogi

Create Algorithm

create_algo

Create a trading algorithm strategy with technical parameters. 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.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	The name of the algorithm
`symbols`	Yes	List of tickers to trade (e.g. ['BTC-USD'])
`timeframe`	No	Strategy timeframe (e.g., '1m', '5m', '1h')
`description`	No	Detailed description of the strategy
`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.

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

A3.5/5.0

Behavior3/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds nothing about side effects, permissions, rate limits, or — crucially — whether the created algorithm is started or left inactive, which is exactly the ambiguity created by the presence of create_and_start_algo and activate_algo.

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 anti-invention rule is front-loaded and clear, but the same warning ('do NOT invent EMA 9/21' / 'never always the same MA pair' / schema's 'Never invent EMA 9/21') recurs across description and schema. The template-selection clause is useful but wordy, so structure is adequate rather than tight.

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

Completeness3/5

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

For a nested-schema mutation tool with an output schema, the essentials are covered (required params, indicator shape, the no-invention rule). What is missing is its position in the algorithm lifecycle relative to create_and_start_algo, activate_algo, and run_backtest, which is the main remaining ambiguity.

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% and the nested strategy_params shape is fully documented, so the baseline is 3. The description's instructions about indicator choice are behavioral guidance rather than additional parameter semantics, and it says nothing about name, symbols, or timeframe.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Create a trading algorithm strategy with technical parameters.' An agent can tell it apart from update_algo or delete_algo. However, it never distinguishes itself from the close sibling create_and_start_algo, leaving the create-vs-create-and-start distinction to inference.

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?

Strong when/when-not guidance: 'Use the strategy the user (or this conversation) specified' and 'If indicators/entry conditions were not specified, ASK — do NOT invent.' It also scopes the one exception where the agent may pick freely. It does not, though, address when to use this tool rather than create_and_start_algo or activate_algo.

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?