Gogi

Create and Start Algorithm

create_and_start_algo

Destructive

Create algo + instance + start live trading on broker_account_id (integer id from list_brokers; prefer paper/demo). 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. Ask for capital_allocation; keep cumulative live capital ≤ policy max_total_capital. Prefer user risk numbers in strategy_params.risk; optional risk_preset otherwise. First call confirm_allocation=false; after user OK retry confirm_allocation=true. On success present Instance Setup Details.

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.6/5.0

Behavior4/5

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

Annotations already declare destructive=true, non-idempotent, open-world, so the safety profile is partly covered. The description adds real behavioral context beyond them: a two-step confirmation gate, the policy constraint that cumulative live capital must stay within max_total_capital, a preference for paper/demo, and the post-success presentation step. It stops short of describing failure modes or rollback.

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

Conciseness4/5

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

Front-loaded with the core action and the confirmation sequence, and no sentence is purely filler. However, the anti-EMA-9/21 warning and the indicator example list are restated across the description and two schema fields, adding redundancy to an already dense paragraph.

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 12-parameter destructive tool with nested objects and an output schema, the description supplies the missing operational context: prerequisites (id source), gating (confirmation flow), policy limits, and the terminal success step. Since an output schema exists, return-value explanation is correctly omitted.

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%, so baseline is 3. The description still adds meaning beyond the schema by clarifying broker_account_id is the internal id (not the external number), that risk numbers should be preferred over risk_preset, and that confirm_allocation must start false and only flip after user acceptance — a workflow detail the schema only hints at.

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?

States a specific compound action (create algo + instance + start live trading) and the resource (broker_account_id), which cleanly distinguishes it from the atomic siblings create_algo, create_instance, and start_instance. An agent can tell what this does 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?

Explicit when-to-use and when-not-to-act guidance: use the user's specified strategy, ASK if indicators were not specified, never invent EMA 9/21, only pick a template when explicitly invited, and ask for capital_allocation. It also names list_brokers as the source of the account id and prescribes the confirm_allocation=false → true sequencing.

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

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?