Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sigmavue-mcp show my current portfolio"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Control your SigmaVue trading account from the terminal —
and from any MCP-speaking assistant. sigmavue is a thin, read-mostly client
over the public SigmaVue API: check status, journal, and portfolio; manage broker
accounts and copy-trading groups; and place kill-switch-gated simulated trades —
without clicking through the app.
It adds no backend logic and bundles no trading strategies. Every command maps to an API endpoint that already ships. Trade execution is fail-closed and SIM-only.
Run it without installing (requires uv):
uvx --from git+https://github.com/Sigma-Algo/sigmavue-cli sigmavue --helpInstall from source:
git clone https://github.com/Sigma-Algo/sigmavue-cli
cd sigmavue-cli
uv sync # or: pip install -e .
uv run sigmavue --help
pip install sigmavue— coming soon (PyPI publish pending).
Related MCP server: IBKR MCP Server
# Point at the API (optional). Defaults to the public SigmaVue API.
export SIGMAVUE_API_URL=https://sigmavue-api-green.onrender.com
# or http://localhost:8000 for a local backend.
sigmavue login --email you@example.com # password read at a secure prompt
sigmavue status # health + account summary
sigmavue accounts list # broker accounts your token owns
sigmavue journal list --symbol NQ # trade journal
sigmavue portfolio # open positions + rollup
sigmavue trade execute --symbol NQ --qty 1 --side buy --sim # SIM-only
sigmavue copy groups list # copy-trading groupsThe bearer token is stored at ~/.sigmavue/auth.json (file mode 0600).
Passwords are only ever read from a prompt, never accepted as an argument.
Command | What it does |
| Authenticate; store or clear the local token |
| Backend health + current user + account summary |
| List broker accounts your token is scoped to ( |
| Start a broker OAuth connect (returns an |
| Remove a broker account by id |
| List managed trading profiles (enterprise) |
| List trade-journal entries ( |
| Current positions + summary ( |
| Place an order — kill-switch gated, |
| List copy-trading groups |
| Create a copy-trading group |
| Coming soon — use the app for now (see below) |
Exit codes: 0 success · 1 validation / API / trade-refused · 2 not logged in.
Trade execution is fail-closed and re-checked on every call, before any order request leaves your machine:
CLI live-execution is disabled — --sim is required; SIM routes to your
active demo broker account.
Local kill-switch — the CLI refuses to place an order whenever trading is turned off, via any of:
env TRADING_ENABLED set to 0/false/no/off
~/.sigmavue/killswitch.json with {"paused": true} (a missing or corrupt
file also blocks — fail-closed)
~/.sigmavue/TRADING_ENABLED file containing 0
Paths are overridable via SIGMAVUE_KILLSWITCH_PATH and
SIGMAVUE_TRADING_ENABLED_PATH.
Backend circuit breaker — the order is refused unless the server-side
per-user circuit breaker is CLOSED.
Rate limits are respected: a stable User-Agent/X-SigmaVue-Client is sent, and
429 responses trigger bounded Retry-After backoff (--verbose surfaces the
rate-limit headers).
The same capability layer is exposed as an MCP
server, so phone / agent coding assistants get identical reach over one API. It
speaks stdio and reads the SAME token sigmavue login stores — there is no
credential collection in the MCP surface.
uv sync --extra mcp # or: pip install "sigmavue[mcp]"
sigmavue login # once, in a terminal
uv run sigmavue-mcp # serves over stdioAdd it to an MCP client (use an absolute path so it can start from anywhere):
{
"mcpServers": {
"sigmavue": {
"command": "uv",
"args": [
"--directory", "/ABSOLUTE/PATH/TO/sigmavue-cli",
"run", "sigmavue-mcp"
]
}
}
}Claude Code:
claude mcp add sigmavue -- \
uv --directory /ABSOLUTE/PATH/TO/sigmavue-cli run sigmavue-mcpIt exposes eight tools: sigmavue_status, sigmavue_accounts_list,
sigmavue_clients_list, sigmavue_journal_list, sigmavue_portfolio,
sigmavue_trade_execute, sigmavue_copy_groups_list, and
sigmavue_copy_groups_create. Interactive/destructive flows (login, broker
connect/remove) stay CLI-only.
Command breadth is decided server-side by your token: a member sees their own
accounts, a manager/enterprise token sees everything it owns — the same
accounts list command covers both. A dedicated multi-tenant clients endpoint is
on the roadmap; clients list maps to managed trading profiles today.
copy groups add-follower is intentionally not enabled from the CLI or MCP yet:
there is no atomic add-follower endpoint, and a client-side read-modify-write of
the follower list would be unsafe. A server-side
POST /api/v2/trading-groups/{id}/followers is planned; until then, add
followers in the SigmaVue app. copy groups list and create work fully.
uv sync
uv run pytest -q # tests use httpx.MockTransport — no live API callsList every broker account the caller's token is scoped to. Breadth is
decided server-side by the token (a member sees their own; a manager token
sees all it owns). Optional is_active filter and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| is_active | No | ||
| page_size | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description explains token-based scoping, optional filter, and pagination. However, it does not explicitly state read-only nature, nor describe pagination behavior (e.g., defaults, total count). Adequate but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler, front-loaded with action and scope. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality, scoping, one filter, and pagination. Output schema exists for return values. Minor omission: no mention of ordering or default pagination behavior. Very good for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It mentions 'is_active filter' and 'pagination' which adds meaning, but does not fully describe each parameter individually (e.g., page_size max). Acceptable but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'list' and resource 'every broker account' scoped to token. Clearly distinct from sibling tools which deal with clients, journals, portfolio, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. Implicit from resource name but no exclusions or when-not-to-use provided. Sibling tools are different, but description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List managed trading profiles (maps to /users/trading-profiles). A
dedicated enterprise "clients" endpoint is a documented backend gap; for full
breadth today use sigmavue_accounts_list.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description discloses the tool's mapping to /users/trading-profiles and a backend gap, but does not cover potential response format or auth needs, though minimal for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, then usage guidance. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with output schema, the description is complete: purpose, limitation, and alternative are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so description adds nothing beyond schema. Baseline score of 4 is appropriate as schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List managed trading profiles' with a specific API endpoint, distinguishing it from sibling tool 'sigmavue_accounts_list' by noting a backend gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use an alternative: 'for full breadth today use sigmavue_accounts_list', providing clear when-not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a copy-trading group with a leader account and optional followers. Adding followers to an EXISTING group is intentionally not exposed over MCP (honest-disabled in the capability layer — needs an atomic server endpoint).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| ticker | Yes | ||
| environment | No | demo | |
| leader_account_id | Yes | ||
| follower_account_ids | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the limitation about not exposing follower additions to existing groups. However, it omits details like whether the tool is idempotent, auth requirements, or if it returns the created group. Output schema exists but isn't leveraged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the core action, the second clarifies a behavioral limitation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and an output schema, the description covers the main action and a key limitation but lacks details on parameters like name and ticker. It's adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies leader_account_id and follower_account_ids by mentioning leader and optional followers, but does not explain name, ticker, or environment parameters, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a copy-trading group with a leader account and optional followers, distinguishing it from siblings by noting that adding followers to existing groups is not exposed via MCP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (create a group) and when not to use (add followers to existing groups), providing clear guidance and mentioning that a server endpoint is needed for the latter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List copy-trading groups. Optional active and environment filters.
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | ||
| environment | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states it lists groups with optional filters, but does not disclose behavioral traits like pagination, rate limits, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks necessary detail. It is not verbose, but the brevity sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown), return value explanation is not needed. However, the description is too minimal for a simple list tool with optional filters; it could mention that it returns an array of groups or provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions the parameter names 'active' and 'environment' but provides no additional meaning, such as possible values or semantics, beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'copy-trading groups'. It mentions optional filters, which adds clarity. However, it does not distinguish from sibling list tools like sigmavue_accounts_list or sigmavue_clients_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description implicitly suggests use for listing copy-trading groups, but no exclusions or context about sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List trade-journal entries, newest first. Optional symbol and
entry_type filters plus pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| symbol | No | ||
| page_size | No | ||
| entry_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions listing with filters and pagination but does not address side effects, authentication needs, rate limits, or data freshness. The safety profile is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and includes key details (filters, pagination, ordering). No redundant or missing words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers the tool's purpose, ordering, and optional filters/pagination. It lacks mention of response format or limits, but the schema fills that gap. Slight deduction for not explicitly stating it returns a paginated list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It identifies symbol and entry_type as filters and mentions pagination, adding basic semantic meaning. However, it does not describe parameter formats, allowed values, or constraints beyond the schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists trade-journal entries, specifies ordering (newest first), and mentions optional filters and pagination. It distinguishes itself from siblings like sigmavue_accounts_list by targeting journal entries specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools are listed but no comparisons or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current open positions plus a rollup summary. Optional account_id and
position status_filter selectors.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | ||
| status_filter | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It states the tool provides 'Current open positions plus a rollup summary', implying a read operation, but fails to disclose whether it is destructive, requires authentication, or has rate limits. The term 'rollup summary' is vague, and no details about data freshness, pagination, or response size are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that front-loads the primary function and mentions the optional parameters. No extra words; every part is necessary. It is exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two optional parameters and an output schema exists, the description captures the core purpose. However, it lacks explanation of the 'rollup summary' and whether the positions include historical data. While the output schema may fill gaps, the description could be more informative about what the return data represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two optional parameters with 0% description coverage. The description adds that they are 'selectors' and names them as 'account_id' and position 'status_filter', clarifying their purpose as filters. However, it does not specify allowed values, formats, or behavior when omitted. The addition of 'Optional' helps but is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool returns 'Current open positions plus a rollup summary'. It identifies the resource (positions/portfolio) and the action (retrieve/summarize). While no explicit verb is used, the noun phrase is unambiguous. Sibling tools like sigmavue_accounts_list or sigmavue_trade_execute show different domains, so this tool is sufficiently distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or when to avoid it. Users are left to infer that it's for viewing portfolio positions, but there is no explicit context or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Backend health plus, when a token is stored, the current user and account
summary. Safe to call unauthenticated — it reports authenticated: false
with a login hint rather than erroring.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that the tool does not error on unauthenticated requests but instead returns 'authenticated: false' with a login hint. This is a key behavioral trait beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with 'Backend health plus', immediately conveying the main purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description is complete enough. It covers the core function and the special unauthenticated behavior. Minor gap: could mention it's useful for connectivity checks, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a health check that also returns user/account info when authenticated. It uses specific verb 'reports' and resource 'backend health plus current user/account summary'. It distinguishes from sibling CRUD tools by its status-check nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is safe to call unauthenticated, providing clear context on when to use. It does not explicitly state when not to use or suggest alternatives, but the purpose implies it's the status tool, and the sibling tools have different functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place an order — fail-closed. Mirrors the CLI exactly: live execution is
disabled (pass sim=true to route to the active demo account), and the
operator kill-switch + backend circuit breaker are re-checked on every call
BEFORE any network write. When the kill-switch is engaged the tool refuses
with blocked: true and places nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| sim | No | ||
| side | Yes | ||
| symbol | Yes | ||
| quantity | Yes | ||
| order_type | No | market | |
| requested_price | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description fully details safety features: fail-closed, kill-switch check before network write, blocked:true response, and simulation mode. Exceeds expectation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each with a distinct purpose: action, simulation, safety, blocked state. Front-loaded, zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, safety, simulation mode. Output schema exists for return values, so omission of return details is acceptable. Missing parameter format constraints, but overall adequate for execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description explains the sim parameter fully but leaves symbol, side, quantity, order_type, and requested_price to inference. Adds some value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Place an order — fail-closed', with specific verb and resource. It distinguishes from siblings that list accounts, clients, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on using sim=true for demo and fail-closed behavior. Does not explicitly list alternatives or when not to use, but siblings are clearly different operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0sigmavue_accounts_listsigmavue_clients_listsigmavue_copy_groups_createsigmavue_copy_groups_listsigmavue_journal_listsigmavue_portfoliosigmavue_statussigmavue_trade_executeMost tools have distinct purposes, but 'sigmavue_accounts_list' and 'sigmavue_clients_list' overlap significantly; the description of clients_list explicitly directs users to accounts_list for full breadth, causing potential confusion for an agent.
Tools consistently use the 'sigmavue_' prefix and generally follow a verb_noun pattern (e.g., 'accounts_list', 'trade_execute'), but 'portfolio' and 'status' are nouns only, and 'trade_execute' inverts the typical verb_noun order, creating minor inconsistency.
With 8 tools covering accounts, clients, copy groups, journal, portfolio, status, and trade execution, the count is well-scoped for a trading platform MCP server—neither too few nor excessive.
The tool surface covers essential listing and execution operations, but notable gaps exist: no way to update or delete copy groups, no close-position tool, and no order-specific detail retrieval beyond journal entries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
Connect any MCP client to MetaTrader 4/5 to read prices, manage positions, and place trades.
Hosted MCP for stocks, options, Greeks, brokers, order previews, alerts, and workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sigma-Algo/sigmavue-cli'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
