How do I use @chartobserver/mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@chartobserver/mcp-server show me my portfolio summary" 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.

@chartobserver/mcp-server

by bbusche

Overview Schema Related Servers Score Discussions

TypeScript

Remote

`@chartobserver/mcp-server`

An MCP (Model Context Protocol) server that lets an AI agent — Claude Desktop, etc. — read your portfolio, place paper trades, and check the leaderboard on your ChartObserver account.

ChartObserver is paper trading. This server cannot move real money. It can affect your public leaderboard standing and your visible portfolio.

Source code: https://github.com/bbusche/chartobserver-mcp — see SECURITY.md for the full egress/data-flow disclosure.

What this server sends and where

Outbound HTTPS to exactly one host: the configured CHARTOBSERVER_API_BASE (default: the ChartObserver production API on AWS API Gateway, https://g2uyqqluc4.execute-api.us-east-2.amazonaws.com/dev).
It transmits your UID, username, your webhook credential (sent as an X-Webhook-Id identity header on every request for usage metering, and as auth on trade execution), and the trade parameters the agent supplies. Nothing else.
It reads no files, contacts no other host, collects no telemetry, runs no code fetched at runtime, and has no install scripts.

Related MCP server: bybit-ws

Install

You don't install this package directly. You add it to your MCP client's configuration and it runs on demand via npx. Pick the section for your client below.

Always pin to @latest. The package spec @chartobserver/mcp-server@latest tells npx to use the newest published version on each launch, so you automatically get fixes and new features. Plain @chartobserver/mcp-server (no tag) can keep running a stale cached copy.

Claude Desktop

Open your Claude Desktop config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Add a chartobserver entry under mcpServers, then restart Claude Desktop:

{
  "mcpServers": {
    "chartobserver": {
      "command": "npx",
      "args": ["-y", "@chartobserver/mcp-server@latest"],
      "env": {
        "CHARTOBSERVER_WEBHOOK_ID": "your-webhook-id-here",
        "CHARTOBSERVER_UID": "your-uid-here",
        "CHARTOBSERVER_USERNAME": "your-username-here"
      }
    }
  }
}

Claude Code

claude mcp add chartobserver \
  --env CHARTOBSERVER_WEBHOOK_ID=your-webhook-id-here \
  --env CHARTOBSERVER_UID=your-uid-here \
  --env CHARTOBSERVER_USERNAME=your-username-here \
  --transport stdio \
  -- npx -y @chartobserver/mcp-server@latest

Add --scope user to make it available across all your projects (the default is the current project only). Verify with claude mcp list; remove with claude mcp remove chartobserver.

Other MCP clients (Cursor, Cline, Windsurf, etc.)

Any client that supports stdio MCP servers uses the same shape — a server entry with a command, args, and env. Add this to that client's MCP/server configuration (consult its docs for the file location), then restart it:

{
  "mcpServers": {
    "chartobserver": {
      "command": "npx",
      "args": ["-y", "@chartobserver/mcp-server@latest"],
      "env": {
        "CHARTOBSERVER_WEBHOOK_ID": "your-webhook-id-here",
        "CHARTOBSERVER_UID": "your-uid-here",
        "CHARTOBSERVER_USERNAME": "your-username-here"
      }
    }
  }
}

All three paths run the identical server; the only difference is where each client keeps its configuration. The three environment variables are required in every case (see below).

Where to find your credentials

Sign in at https://chart.observer and open Integrations → AI Agent (MCP) — or go directly to https://chart.observer/integrations/mcp. The page shows your webhook ID, UID, and username with copy buttons and a pre-filled config snippet you can paste straight into your MCP client.

Environment variables

Variable	Required	Default	Description
`CHARTOBSERVER_WEBHOOK_ID`	yes	—	Your per-user webhook secret. Same value TradingView uses to fire trades into your account. Treat like a password.
`CHARTOBSERVER_UID`	yes	—	Your numeric user ID.
`CHARTOBSERVER_USERNAME`	yes	—	Your public username.
`CHARTOBSERVER_API_BASE`	no	`https://g2uyqqluc4.execute-api.us-east-2.amazonaws.com/dev`	API Gateway base URL. Override to point at staging during testing. Must be `https:`.
`CHARTOBSERVER_TIMEOUT_MS`	no	`15000`	Per-request timeout in milliseconds (max 120000).

Available tools

Account

Tool	What it does
`get_profile`	Read your public profile and current USD balance.
`get_subscription`	Your subscription tier (Basic / Swing Trader / Day Trader / Influencer), monthly usage vs. limits (trades, API calls, AI-assistant messages), renewal date, and recent payments.

Trading

Tool	What it does
`place_trade`	Place a buy or sell. Defaults to `dry_run: true` — returns the projected impact without executing. Set `dry_run: false` only after confirming with the user. `token` accepts a symbol (`SOL`), pair (`SOLUSD`), or name (`Solana`).
`get_balance`	Current USD balance (`0` for a funded-but-empty account).
`get_open_positions`	Open positions, grouped by token pair with average cost basis.
`get_closed_trades`	Recent closed trades (completed buy→sell roundtrips).
`get_recent_transactions`	Recent raw transactions (open + closed).

Market

Tool	What it does
`get_leaderboard`	7-day rolling leaderboard: top traders by average % profit.
`get_my_ranking`	Your position on the leaderboard (or `null` if not ranked).
`get_price`	Current price for a token. Accepts a symbol (`SOL`), pair (`SOLUSD` / `SOL-USD`), or name (`Solana`); quote defaults to USD.
`list_supported_tokens`	Every supported token-pair, so you can use a valid identifier before pricing or trading.

Portfolio

Tool	What it does
`get_portfolio_summary`	One-shot snapshot: balance + open positions + recent closed trades + your leaderboard rank. Designed for periodic polling — compare snapshots to detect changes.

Documentation

Tool	What it does
`search_docs`	Search the ChartObserver documentation and return the most relevant passages, each with its source URL. Use for "how does X work" / setup / integrations / subscriptions / troubleshooting questions; cite the URLs. Not for live account data.

Safety model

Paper trading only. Trades affect your simulated portfolio and your leaderboard standing. They do not move real money.
place_trade defaults to dry-run. The AI agent must explicitly pass dry_run: false to execute. You should be asked for confirmation before that happens.
Live trades are validated. Execution runs the same checks as the dry run (sufficient funds, position size, well-formed quantities) and refuses trades that would fail, without calling the API.
Secret redaction. Error text returned to the agent is sanitized; the webhook credential is redacted as defense-in-depth so it cannot leak into transcripts.
Bearer-secret auth. The webhook ID acts as a bearer token. If it leaks, anyone can act on your account. Don't paste it into screenshots, logs, or chat messages. If you suspect compromise, regenerate it from https://chart.observer/integrations/mcp.
No account creation. Sign up at https://chart.observer in a browser. Web signup requires a CAPTCHA, which a headless MCP server can't solve.
Prices are delayed up to 15 minutes. This is a paper-trading platform; quotes must not be used for real-money trading decisions.

What's not in v1

Real-time push notifications (poll get_portfolio_summary instead).
Per-token rotation, multiple tokens, scoped tokens, expiry — these will come in a later revision that hardens the webhook-ID lifecycle.
Equities/options/forex — the platform is crypto-only paper trading today.

Development

npm install
npm run typecheck
npm test
npm run build

To test locally against staging, build then point Claude Desktop at the local file:

{
  "mcpServers": {
    "chartobserver-local": {
      "command": "node",
      "args": ["/absolute/path/to/chartobserver/mcp-server/dist/index.js"],
      "env": {
        "CHARTOBSERVER_API_BASE": "https://g2uyqqluc4.execute-api.us-east-2.amazonaws.com/staging",
        "CHARTOBSERVER_WEBHOOK_ID": "...",
        "CHARTOBSERVER_UID": "...",
        "CHARTOBSERVER_USERNAME": "..."
      }
    }
  }
}

Repo layout

src/
  index.ts          # MCP server entry, registers tools
  config.ts         # Loads + validates env vars
  api-client.ts     # HTTP client for ChartObserver API
  marshal.ts        # Unmarshals raw DynamoDB JSON from the read endpoints
  pairs.ts          # Token-pair resolution + bundled name→symbol map
  instructions.ts   # Agent-facing server instructions
  redact.ts         # Secret-redaction backstop for all outbound error text
  tools/
    account.ts
    trading.ts
    market.ts
    portfolio.ts
    util.ts
  __tests__/
    api-client.test.ts
    config.test.ts
    trading.test.ts
    redact.test.ts

Available Tools

13 tools

get_balanceGet USD balanceA

Read-only

Fetch the configured user's current USD paper-trading balance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds the context of 'paper-trading' and 'configured user', which are not in annotations. It does not contradict annotations and provides useful behavioral context beyond the structured fields.

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?

The description is a single sentence of 10 words, perfectly concise with no filler. It front-loads the key information.

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?

Given the tool has no parameters and no output schema, the description is adequate. It clearly states what the tool does. A minor gap is that it does not mention the return format (e.g., numeric value), but for a simple balance fetch, it is sufficiently complete.

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?

The tool has 0 parameters and 100% schema coverage. With no parameters, the description does not need to add parameter semantics. Baseline score of 4 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 tool name 'get_balance' and description 'Fetch the configured user's current USD paper-trading balance' clearly specify the verb, resource, and scope. It distinguishes itself from sibling tools like 'get_portfolio_summary' and 'get_open_positions' by focusing on the USD balance.

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

Usage Guidelines3/5

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

The description implies usage for retrieving balance, but lacks explicit guidance on when to use this tool versus alternatives, such as when to use 'get_portfolio_summary' for a broader view. No when-not or alternative conditions are provided.

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

get_closed_tradesGet closed tradesA

Read-only

List closed paper trades (completed buy→sell roundtrips) for the configured user, most recent first.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of closed trades to return (server may cap).

TDQS

A4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint and openWorldHint. The description adds valuable context: it notes that trades are 'paper trades' (not real), defines roundtrips, and specifies the scope 'for the configured user'. This goes beyond annotations without contradicting them.

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?

The description is a single sentence that effectively conveys the core purpose, scope, and ordering. Every phrase adds value without redundancy.

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 list tool with one parameter and no output schema, the description is fairly complete. It covers what is listed, ordering, and user scope. It could mention that results are limited by the parameter, but that is implied.

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 coverage is 100% and the schema already documents the 'limit' parameter with defaults, maximum, and description. The tool description does not add any additional meaning or usage guidance for the parameter.

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 explicitly states the verb 'list', resource 'closed paper trades', and defines them as 'completed buy→sell roundtrips'. It also specifies the ordering 'most recent first', clearly distinguishing from siblings like 'get_open_positions'.

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

Usage Guidelines3/5

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

The description implies usage for retrieving completed trades, but does not explicitly state when to use this tool versus alternatives like 'get_open_positions' or 'get_recent_transactions'. No exclusions or conditions are mentioned.

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

get_leaderboardGet leaderboardA

Read-only

Fetch the 7-day rolling ChartObserver leaderboard: top traders by average % profit per closed trade, plus the top individual closed trades. Public data.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of top-traders rows to return.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's mention of 'Public data' reinforces safety. It also clarifies the rolling 7-day window. No contradictions; adds useful context beyond annotations.

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?

Two sentences, no fluff. Key information front-loaded: data source, period, criteria. Every word adds value.

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?

No output schema exists; description hints at result structure (top traders + top individual closed trades) but doesn't clarify format (e.g., fields returned, pagination). Adequate for a simple public data endpoint but could be more complete.

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 coverage is 100% with limit parameter fully described (default, max, exclusive min). Description does not add additional semantic meaning beyond the schema, so baseline of 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?

Description clearly states it fetches the 7-day rolling leaderboard, specifically top traders by average % profit per closed trade plus top individual closed trades. This distinguishes well from siblings like get_my_ranking (personal ranking) and others.

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?

Description implies the tool is for viewing public leaderboard data, noting it's public. It doesn't explicitly guide when to use vs alternatives, but the context with sibling tool names makes it clear. Could benefit from explicit when-not conditions.

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

get_my_rankingGet my leaderboard rankA

Read-only

Find the configured user's position on the 7-day leaderboard, if they appear. Returns null rank if not on the board.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate read-only and open-world; description adds behavior about returning null if not on board. No contradictions.

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?

Extremely concise: one sentence plus a brief clarification on null return. Every word adds value.

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 parameterless tool with no output schema, the description adequately explains purpose and expected result. Slight gap in explicit output format but sufficient.

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?

No parameters, so baseline is 4. Description adds meaning by specifying 'configured user' and '7-day leaderboard', beyond the empty 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 description clearly states the tool retrieves the configured user's position on the 7-day leaderboard, distinguishing it from sibling tool 'get_leaderboard' which returns the full board.

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?

Usage context is clear: for the configured user's rank. However, no explicit guidance on when not to use it or comparison with alternatives like 'get_leaderboard'.

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

get_open_positionsGet open positionsA

Read-only

List all currently open paper-trading positions (buy transactions that have not yet been closed by a sell).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already indicate read-only and open-world. Description adds that it lists paper-trading positions and defines open, providing context beyond annotations.

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?

One sentence, perfectly front-loaded with purpose, no wasted words.

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?

No output schema, but description only says 'list' and defines open positions. Doesn't specify fields or structure of each position, which would be helpful.

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?

No parameters exist; schema coverage is 100%. Description adds no param info, but there is nothing to add. It does explain the meaning of the result.

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 specific verb 'List' and resource 'open paper-trading positions', and defines what open positions are. It distinguishes from siblings like get_closed_trades.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs alternatives. The description implies use for open positions but doesn't mention siblings or exclusions.

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

get_portfolio_summaryGet portfolio summaryA

Read-only

One-call snapshot of the configured user's portfolio: USD balance, open positions grouped by token (with average cost basis), the 5 most recent closed trades, and the user's current leaderboard rank if any. Designed for periodic polling — agents can compare consecutive snapshots to detect changes.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations declare readOnlyHint and openWorldHint, and the description adds context by detailing the returned fields (balance, positions, trades, rank). It also specifies it is for the 'configured user,' which is a behavioral constraint beyond the annotations.

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?

Two focused sentences, front-loaded with purpose, and no redundant information. Every word contributes value.

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?

Given the tool's complexity (multiple data points) and no output schema, the description adequately summarizes what the agent can expect. It could be more precise about the structure of the returned data, but it suffices for understanding the tool's role.

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?

There are no parameters, so the description carries full burden. It describes the output contents clearly, compensating for the lack of an output schema.

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 clearly states the tool provides a one-call snapshot of the portfolio with specific items (USD balance, open positions, closed trades, leaderboard rank). It distinguishes itself from sibling tools that return individual data, though it could explicitly name alternatives.

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

Usage Guidelines3/5

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

The description mentions it is designed for periodic polling and comparing snapshots, implying a use case. However, it does not explicitly state when to use this tool versus the sibling tools that provide more granular data.

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

get_priceGet current priceA

Read-only

Fetch the latest price for a supported crypto token. Accepts a bare symbol (SOL), a full pair (SOLUSD, SOL-USD, SOL/USD), or a name (Solana); the quote currency defaults to USD. Prices are delayed up to 15 minutes and are for paper trading only — never for real-money decisions. Use list_supported_tokens to see valid identifiers.

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes	Token to price: symbol (SOL), pair (SOLUSD / SOL-USD), or name (Solana). Quote defaults to USD.

TDQS

A4.4/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint, openWorldHint), the description reveals critical behaviors: prices are delayed up to 15 minutes and are for paper trading only, preventing real-money misuse. No contradiction with annotations.

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?

Three concise sentences: purpose first, then input format, then important caveats. No filler; every sentence adds value.

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 one-parameter tool without output schema, the description adequately covers purpose, input, and caveats. Lacks explicit mention of return format, but the output is often inferred. A small gap prevents a 5.

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 coverage is 100%, and the description largely repeats the schema's parameter description. It adds no new semantics beyond what the schema already provides, so 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?

Description clearly states the tool fetches the latest price for a crypto token, with specific verb 'Fetch' and resource 'price'. It also explains accepted input formats, making the purpose unambiguous and distinct from sibling tools like get_balance.

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?

The description advises using list_supported_tokens for valid identifiers and notes that prices are for paper trading only. While it doesn't explicitly contrast with alternatives, the context is clear and helpful for proper usage.

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

get_profileGet profileA

Read-only

Fetch the currently configured user's public profile (description, social links, follower counts) along with their USD paper-trading balance. Read-only. Requires an existing chart.observer account — if credentials are missing or rejected, direct the user to sign up in a browser at https://chart.observer (accounts cannot be created via this server).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds behavioral context: the tool requires validated credentials and fails with a clear guidance action. No contradictions with annotations.

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?

The description is two sentences: the first defines the core function, the second adds prerequisite and error handling. It is front-loaded, concise, and contains no unnecessary words.

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 tool with no parameters and no output schema, the description covers purpose, return data, prerequisite, and error resolution. It provides sufficient information for an agent to decide when and how to call it.

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?

With zero parameters, the schema provides no information. The description adds value by listing the return fields (profile details, balance), but this is not parameter semantics per se. Baseline 4 is appropriate for zero-parameter tools.

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 clearly states the tool fetches the user's public profile (description, social links, follower counts) and their USD paper-trading balance. It distinguishes from sibling tools like get_balance by combining these elements, and explicitly labels it as read-only.

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?

The description specifies a prerequisite (existing chart.observer account) and error handling (direct user to sign up via browser). While it doesn't explicitly compare to siblings, the combination of profile and balance provides context for when to use this tool over others.

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

get_recent_transactionsGet recent transactionsA

Read-only

List the configured user's recent transactions (open + closed, all types). Most recent first.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of transactions to return.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so the description's behavioral disclosure is minimal. It adds sorting order but does not mention caching, pending transactions, or other quirks beyond annotations.

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?

Single sentence of 15 words, front-loaded with the key action and scope. No redundant information.

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 tool with one parameter and no output schema, the description covers the return type and ordering. Minor omission of default limit, though schema already specifies it.

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 coverage is 100%, and the description does not add meaning beyond the schema. 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?

Clearly states verb (list), resource (transactions), and scope (configured user, recent, open+closed, all types, sorted most recent first). Distinguishes from siblings like get_open_positions and get_closed_trades.

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

Usage Guidelines3/5

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

Describes what the tool does but does not explicitly state when to use it versus alternatives like get_open_positions or get_closed_trades. Sibling names provide implicit context, but no explicit guidance on when-not-to-use.

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

get_subscriptionGet subscription & usageA

Read-only

Fetch the currently configured user's subscription tier (Basic, Swing Trader, Day Trader, or Influencer), their monthly usage vs. limits (trades, API calls, AI-assistant messages), the plan renewal date and whether it is set to cancel, and recent payments. Use this for ANY question about the user's own plan, tier, remaining quota, billing, or renewal — do NOT use search_docs for those (search_docs explains how tiers work in general; this returns the user's actual, resolved values). Read-only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'Read-only.' which is consistent but not additional beyond annotations for behavioral traits.

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?

Two sentences, no fluff. Front-loaded with key output details. Every sentence adds value.

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?

Given 0 parameters, annotations present, and no output schema, the description comprehensively lists return fields and use case, making the tool's function fully clear.

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?

No parameters in input schema; schema coverage 100%. Baseline for 0 params is 4, and description doesn't need to add parameter details.

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 clearly states the tool fetches the user's subscription tier, monthly usage vs limits, renewal date, cancel status, and recent payments. It uses specific verbs and resources, and distinguishes from sibling search_docs.

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?

Explicitly tells when to use ('for ANY question about the user's own plan...') and when not to use (do NOT use search_docs). Provides clear context and alternatives.

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

list_supported_tokensList supported tokensA

Read-only

List every crypto token-pair ChartObserver supports, so you (or the user) can use a valid identifier before requesting a price or placing a trade. Returns slash pairs like BTC/USD with their exchange. Most tokens trade against USD; a few against USDT.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint. Description adds that it returns slash pairs with exchange and mentions typical trading pairs (USD/USDT), providing extra behavioral context beyond annotations.

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?

Two concise sentences, front-loaded with main action and purpose, no wasted words.

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?

Given no parameters and no output schema, description is complete: covers purpose, usage context, output format, and typical pairs.

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?

No parameters exist, so baseline of 4 applies. Description does not need to explain parameters.

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?

Description clearly states verb 'List' with specific resource 'every crypto token-pair', explains purpose to get valid identifiers for subsequent actions, and distinguishes from siblings like get_price and place_trade.

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?

Provides clear context: 'so you can use a valid identifier before requesting a price or placing a trade'. Does not explicitly exclude alternatives or state when not to use, but sufficient for a read-only list tool.

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

place_tradePlace a paper tradeA

Destructive

Place a paper-trading buy or sell on the ChartObserver platform for the configured user.

IMPORTANT SAFETY NOTES:

Defaults to dry_run=true. With dry_run=true, NO trade is executed; the tool returns the would-be impact (cost, resulting balance, resulting position). Always start with dry_run=true and present the result to the user for confirmation before calling again with dry_run=false.
This is paper trading (simulated). It does NOT move real funds. It DOES affect the user's leaderboard standing and visible portfolio.
Crypto only. token accepts a bare symbol (SOL), a pair (SOLUSD / SOL-USD), or a name (Solana); quote defaults to USD. Use list_supported_tokens for valid identifiers.
Sell count may be a percentage string like '50%' or '100%'. Buy count must be a numeric quantity.
Buys require sufficient USD balance. Sells cannot exceed currently held tokens.
Live execution runs the same validation as the dry run and refuses trades that would fail.
Prices are delayed up to 15 minutes (paper trading only) — never present them as real-time or use them for real-money decisions.
Requires an existing chart.observer account. If credentials are rejected, direct the user to https://chart.observer to sign up in a browser (accounts cannot be created via this server).

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Quantity of base token to trade. For sells, may be a percentage string ('50%', '100%') of currently held tokens. For buys, must be a positive number.
`token`	Yes	Token to trade: symbol (SOL), pair (SOLUSD / SOL-USD), or name (Solana). Quote defaults to USD.
`action`	Yes	Trade direction.
`dry_run`	No	When true (default), returns the projected impact without executing. Set to false ONLY after confirming with the user.

TDQS

A4.8/5.0

Behavior5/5

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

While annotations already indicate destructiveHint=true and readOnlyHint=false, the description adds critical behavioral context: dry_run defaults to true (no real execution), paper trading affects leaderboard but not real funds, prices are delayed 15 minutes, and trade validation occurs on live runs. No contradictions exist.

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?

The description is structured with a clear opening sentence and a bulleted 'IMPORTANT SAFETY NOTES' section for emphasis. While lengthy, it avoids redundancy and each point provides distinct value for a complex tool. Minor trimming could improve conciseness, but it remains well-organized and front-loaded.

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?

Given the tool's complexity (trading, multi-type parameters, safety risks), the description covers all necessary aspects: dry_run flow, token formats, count constraints, balance requirements, price delay, account prerequisites, and what dry_run returns. It references sibling tools appropriately and leaves no major gaps despite lacking an output schema.

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?

Input schema covers all 4 parameters with descriptions (100% coverage). The description enriches understanding: sell count can be a percentage string, buy count must be numeric, token accepts symbols/pairs/names, and dry_run defaults to true. This adds practical nuance beyond schema alone.

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 starts with 'Place a paper-trading buy or sell on the ChartObserver platform for the configured user,' clearly stating the verb (place) and resource (paper trade). It distinguishes from sibling tools (e.g., get_balance, get_leaderboard) by focusing on trade execution, and the title 'Place a paper trade' aligns perfectly.

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 provides explicit instructions: always start with dry_run=true, present results for confirmation before setting dry_run=false. It also specifies when not to use (e.g., for non-crypto assets), alternative references (list_supported_tokens for valid identifiers), and operational constraints (price delays, account requirements).

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

search_docsSearch ChartObserver documentationA

Read-only

Search the ChartObserver documentation and return the most relevant passages, each with its source URL. Use this for questions about how the platform works — features, setup, integrations (TradingView, webhooks, the MCP server itself), subscriptions/limits/pricing, supported tokens, or troubleshooting. Answer from the returned excerpts and cite the url(s). Do NOT use it for the user's own live account data (balance, positions, prices, leaderboard) — those have dedicated tools.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The question or key terms to look up in the documentation.
`top_k`	No	How many excerpts to retrieve.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral context: returns excerpts with URLs, and instructs to answer from excerpts and cite sources. No contradictions.

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?

Two sentences, front-loaded with purpose and domain, followed by usage constraints. Every sentence adds value; no wasted words.

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?

Given full schema coverage and annotations, the description is complete. It explains what the tool returns, when to use it, and how to handle results. No gaps for an agent to misunderstand.

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 coverage is 100%, so baseline is 3. The description does not add significant parameter-level detail beyond what the schema provides, but the schema descriptions are clear.

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 clearly states it searches ChartObserver documentation and returns relevant passages with source URLs. It distinguishes from sibling tools that handle live account data, making the purpose unambiguous.

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?

Explicitly specifies when to use (questions about platform features, setup, integrations, subscriptions, etc.) and when not to use (live account data, which have dedicated tools). This provides clear decision guidance for the agent.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

13 tool updatesv0.6.0Jul 12, 2026
- First observedget_balance
- First observedget_closed_trades
- First observedget_leaderboard
- First observedget_my_ranking
- First observedget_open_positions
- First observedget_portfolio_summary
- First observedget_price
- First observedget_profile
- First observedget_recent_transactions
- First observedget_subscription
- First observedlist_supported_tokens
- First observedplace_trade
- First observedsearch_docs

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, though get_profile and get_balance share some balance info, and several tools deal with trades/positions. However, descriptions provide enough differentiation to guide an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., get_balance, place_trade, list_supported_tokens), making it easy to infer functionality.

Tool Count5/5

13 tools is well-scoped for a paper trading platform, covering user data, trading, portfolio, community features, and documentation search without unnecessary overlap.

Completeness4/5

The tool set covers essential CRUD and lifecycle operations for paper trading. Minor gaps exist (e.g., no tool for individual trade details), but core workflows are fully supported.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Danushkumar-V-mcp-discordOAuth
ai.smithery
An MCP server that integrates with Discord to provide AI-powered features.
Communication Social Media App Automation
2
agentwork-mcp A
io.github.ferm-ai
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Agent Orchestration Autonomous Agents App Automation
2
Helvetic Research AOAuth
io.github.KushPatil22
Research-only MCP server: turn your AI into a quant research desk — backtests, no trades.
Finance Research & Data
1
openmm-mcp A
io.github.QBT-Labs
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Finance
1513

Related MCP Servers

crypto-sentiment-mcp
Cryptocurrency Social Media Research & Data
kukapay
A
license
A
quality
F
maintenance
An MCP server that delivers cryptocurrency sentiment analysis to AI agents.
Updated a year ago (2025-03-27 22:59 UTC)
5
48
MIT
bybit-ws
Cryptocurrency Finance Autonomous Agents
poliakarmai
A
license
Not graded
quality
A
maintenance
An MCP server that enables AI agents to scan the market, manage positions, and retrieve trading metrics for Bybit through natural language commands.
Updated 10 days ago (2026-08-27 18:48 UTC)
1
AGPL 3.0
ibkr-mcp
Finance Research & Data
jeffbai996
F
license
Not graded
quality
B
maintenance
An MCP server that turns Interactive Brokers into a question-answering portfolio analyst.
Updated 2 days ago (2026-09-05 05:02 UTC)
4
-
Scorched
Finance AI & Machine Learning Autonomous Agents
willcassell
A
license
Not graded
quality
B
maintenance
An MCP server that lets you talk to your AI trading assistant in plain English to research stocks, generate trade recommendations, manage a portfolio, and execute trades through natural language.
Updated 7 days ago (2026-08-31 12:22 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bbusche/chartobserver-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server