The Rozkoduj MCP server provides AI-powered access to market analysis, trading strategies, financial data, and Rozkoduj's knowledge base.
Technical Analysis
analyze — Technical analysis (composite rating + indicators) for any symbol across multiple intervals
score — Holistic 0–100 score combining technical rating, momentum, volume quality, and trend strength
multitf — Multi-timeframe alignment scoring across up to 10 timeframes
compare — Compare technical analysis across up to 10 symbols simultaneously
decode — Full 3-dimensional analysis: technical scores, fundamental valuation, analyst data, and news sentiment (each scored 0–100)
fundamentals — P/E, P/B, Piotroski score, analyst consensus, price targets, earnings, and dividends
Market Screening & Discovery
scan — Screen global markets by any indicator, fundamental, or metric with custom filters
smart_screen — Pre-built intelligent screens: unusual volume, oversold bounce, breakout, momentum, dividend, value, or growth
digest — Scan for anomalies: volume spikes, RSI extremes, big moves, 52-week highs/lows
movers — Top gainers/losers for any supported market
Market Sentiment & Events
market_pulse — Current market regime (RISK-ON, RISK-OFF, NEUTRAL) combining Fear & Greed, crypto sentiment, and VIX
buzz — Attention signal for any ticker or topic globally using headline counts and Wikipedia pageview data
calendar — Upcoming economic calendar events filtered by days, countries, and importance
Trading Strategies
list_strategies — Browse Rozkoduj's catalog of published, backtested strategies; sort by Rozkoduj Score, APY, or recency
strategy_details — Full details on a strategy: APY, max drawdown, win rate, risk mode, and more
Knowledge Base
search_articles — Keyword + semantic search across the Rozkoduj blog
search_knowledge — Hybrid search across Rozkoduj's extended knowledge base (requires sign-in)
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., "@Rozkoduj MCP Should I buy AAPL?"
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.
Market intelligence for your AI assistant - algo-trading strategies, analytics and specialized research knowledge.
Just ask
"What strategy works best on AAPL?"
"Show me the top strategy's backtest - return, max drawdown, win rate."
"How risky is BTC?"
"How do I avoid overfitting a backtest?"
The hosted server works immediately - no API key, no sign-up. Signing in on a paid tier adds the deeper knowledge base to research results.
Standard config works in most MCP clients:
{
"mcpServers": {
"rozkoduj": {
"url": "https://mcp.rozkoduj.com/mcp"
}
}
}Click the Add to Cursor button above, or add to ~/.cursor/mcp.json:
{
"mcpServers": {
"rozkoduj": {
"url": "https://mcp.rozkoduj.com/mcp"
}
}
}Click the Install in VS Code button above, use the CLI:
code --add-mcp '{"name":"rozkoduj","type":"http","url":"https://mcp.rozkoduj.com/mcp"}'or add to .vscode/mcp.json:
{
"servers": {
"rozkoduj": {
"type": "http",
"url": "https://mcp.rozkoduj.com/mcp"
}
}
}claude mcp add --transport http rozkoduj https://mcp.rozkoduj.com/mcpAdd --scope user to enable it in every project.
Settings → Connectors → Add custom connector, then enter:
https://mcp.rozkoduj.com/mcpConnectors are account-level, so the server is available in both the desktop app and claude.ai. Sign in with Rozkoduj when prompted, or skip it to use the anonymous tier.
Custom MCP connectors need Developer mode (Plus/Pro/Team/Enterprise/Edu):
Settings → Connectors → Advanced - enable Developer mode.
Settings → Connectors → Create - name it Rozkoduj, set the MCP
server URL to https://mcp.rozkoduj.com/mcp, pick OAuth (or
No authentication for the anonymous tier), and create.
In a chat, open + → Developer mode and toggle Rozkoduj on.
uvx rozkoduj-mcp # run straight from PyPI
pip install rozkoduj-mcp # or install
docker run -p 8080:8080 $(docker build -q .) # or containerizedDefaults to stdio transport; set MCP_TRANSPORT=streamable-http to serve
HTTP. See Self-host with your own key to run
as your subscription tier.
Related MCP server: TickerAPI
You ask in plain language. The AI picks the right tool. You get an answer with evidence - strategy metrics you can rank, or research passages you can cite - not a data dump.
You ask | You get |
"What strategy works best on AAPL?" | Strategies backtested on AAPL, ranked by their score on it |
"How risky is BTC?" | The instrument dossier - volatility, drawdowns, character fingerprint |
"What does the research say about position sizing?" | Ranked passages with |
One tool per pillar. All four are read-only.
leaderboard - the strategy leaderboard: published, backtested
strategies, ranked. Sort by score or APY - apy_desc ranks by cagr_usd
(annualised return in USD, the cross-market canon; local cagr is the
fallback); filter by family or by instrument symbol ("what works best on
AAPL?").
strategy - one strategy's full dossier: metrics, risk mode, parameters, and the backtest summary.
instrument - the catalog of covered markets, or one instrument's dossier: buy-and-hold facts and the six-axis character fingerprint.
research - one search across the research: articles plus, on paid tiers, the deeper knowledge base. Returns cited passages.
Explore the leaderboard
What strategy works best on AAPL?
Show me the highest-APY strategy and its max drawdown.
Which strategy family performs best?Dig into a strategy
Give me the full details on the MA Crossover strategy.
What's the win rate and risk mode of your top strategy?Explore the markets
Which markets do you cover?
How risky is BTC - volatility, drawdowns, character?Search the research
How do I avoid overfitting a backtest?
Find articles about position sizing and drawdown control.The hosted server at https://mcp.rozkoduj.com/mcp authenticates to the data
API automatically. When you self-host the package, supply your own Rozkoduj API
key so calls run as your subscription tier instead of the anonymous tier:
Ask for a key at hello@rozkoduj.com (format rzk_ + 40 hex). It maps to
your account's tier.
Provide it via the ROZKODUJ_API_KEY environment variable - never inline in
committed config. In an MCP client, reference it as ${env:ROZKODUJ_API_KEY}.
A malformed value is ignored (requests fall back to anonymous); the active posture is logged at startup, prefix only - the key is never logged.
Precedence: ROZKODUJ_API_KEY (self-host) > anonymous. The hosted server
authenticates automatically.
MIT - rozkoduj.com
The instrument catalog, or one instrument's dossier.
Without symbol: the catalog of covered markets - name, venue, asset
class, status - filterable by asset_class (equity, crypto,
index, commodity) or status. Use for "which markets do you
cover?", "list your crypto instruments".
With symbol: the dossier - identity (name, venue, currency, sector)
plus stats, the analytics summary: buy-and-hold facts (cagr,
volatility_pct, max_drawdown, time_underwater_pct) and the six-axis character
fingerprint (fingerprint_axes, with verdict). stats is null for freshly added
instruments. Case-insensitive: aapl finds aapl-us; the full slug
(ry-ca) pins one listing when a ticker trades in several markets. Use
for "what do you know about AAPL?", "how volatile is BTC?".
For strategies backtested on the instrument, use leaderboard with the
same symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| status | No | ||
| symbol | No | ||
| asset_class | No |
| Name | Required | Description |
|---|---|---|
| items | No | |
| limit | No | |
| stats | No | |
| total | No | |
| offset | No | |
| sector | No | |
| status | No | |
| ticker | No | |
| currency | No | |
| last_close | No | |
| prev_close | No | |
| asset_class | No | |
| display_name | No | |
| listing_slug | No | |
| exchange_label | No | |
| last_close_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavior beyond that: the catalog/dossier mode switch, case-insensitive symbol matching, full-slug disambiguation, and `stats` being null for newly added instruments. No contradiction exists between the description and annotations.
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 front-loaded with the core distinction—catalog vs. dossier—then organized by mode, with fields, examples, and edge cases in a logical order. Every section earns its place, and the closing `leaderboard` routing is useful without bloating the text.
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 read-only catalog/dossier tool with an output schema present, the description covers both operation modes, filter dimensions, symbol resolution edge cases, null stats behavior, and sibling routing. An agent has everything it needs to select and invoke the tool correctly.
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 carries the burden of explaining parameters. It thoroughly explains `symbol` (case-insensitive, slug pinning), `asset_class` (including enum values), and `status` as a filter. However, it does not explicitly describe `limit` or `offset`, though their names and schema defaults make them fairly obvious.
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 what the tool does: it returns either the instrument catalog (when `symbol` is absent) or one instrument's dossier (when `symbol` is provided). It distinguishes itself from siblings by naming the `leaderboard` alternative and describing the exact fields returned in each mode.
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 gives explicit 'Use for...' examples for both modes, such as 'list your crypto instruments' and 'what do you know about AAPL?'. It also explicitly routes strategy backtest queries to the `leaderboard` sibling with the same symbol, providing clear when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The strategy leaderboard - published, backtested strategies, ranked.
Use for "what are the best strategies?", "what works best on AAPL?".
symbol narrows to strategies backtested on one instrument and makes
best_run the best run on that instrument - case-insensitive, plain
tickers just work (aapl finds aapl-us, btc finds btc-usd; the
full slug like ry-ca pins one listing when a ticker trades in several
markets).
There is NO risk filter here: unit_risk_band is returned on best_run
but cannot be filtered or sorted on. Answer "best aggressive strategy?"
by fetching a page and reading unit_risk_band, never by inventing a
parameter.
Sorting: score_desc (default) ranks by the Rozkoduj Score - the
headline leaderboard axis; apy_desc ranks by annualised return in USD
(cagr_usd - the cross-market canon, immune to weak-currency inflation;
local cagr is the fallback); recent is newest first.
Each item carries algorithm_uid (ULID), slug, i18n
name/description, family/variant, and best_run with hot
metrics: listing_slug (the instrument the metrics were earned on),
cagr (APY in the instrument's local currency), cagr_usd (APY in USD -
use this whenever comparing across markets), max_drawdown,
win_rate_pct, num_trades, rozkoduj_score, rozkoduj_band, the risk
mode (unit_risk_band, unit_risk_score), and a sparkline.
For one strategy's full dossier use strategy.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | score_desc | |
| limit | No | ||
| family | No | ||
| offset | No | ||
| status | No | active | |
| symbol | No |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| limit | Yes | |
| total | Yes | |
| offset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say `readOnlyHint: true` and `openWorldHint: false`. The description adds meaningful behavioral context beyond that: no risk filtering is possible, `unit_risk_band` cannot be filtered or sorted, `symbol` matching is case-insensitive with ticker normalization, and sort options have specific well-defined meanings. No contradiction with annotations exists.
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 long but well structured and front-loaded with the core purpose and usage examples. Every paragraph earns its place: symbol behavior, risk-filter caveat, sorting semantics, and return fields. A few clauses are somewhat redundant with the schema, but overall it is efficiently organized.
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?
The description covers the key operational details an agent needs: when to use the tool, how sorting works, how `symbol` affects `best_run`, what fields are returned, and an important limitation (no risk filter). An output schema exists, so the description need not restate return structures. This is complete enough for reliable invocation.
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?
With 0% schema description coverage, the description must compensate and does for the two most nuanced parameters: `sort` is fully explained with its enum meanings, and `symbol` gets detailed normalization semantics. However, `family`, `status`, `limit`, and `offset` receive little or no explicit textual explanation, though their schema titles and enum values make them partially self-explanatory.
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 states a specific verb and resource: 'published, backtested strategies, ranked' on a leaderboard. It clearly differentiates from the sibling `strategy` tool by noting that a single strategy's full dossier belongs there, so an agent can distinguish the two without opening schemas.
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?
It explicitly gives example user intents ('what are the best strategies?', 'what works best on AAPL?') and explains when `symbol` is appropriate. It also states when not to use this tool for risk filtering and directs users to the `strategy` tool for a full strategy dossier, providing clear when/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the research - public articles plus, when signed in on a paid tier, the deeper knowledge base, in one query.
Use when the user asks about a topic the research likely covers (drawdown control, position sizing, backtesting pitfalls, ...).
Returns two ranked lists of passages:
articles (public): each hit carries slug + locale - cite by
linking https://www.rozkoduj.com/<locale>/research/<slug> - plus
title, chunk_text, and parent_text for wider context.
knowledge (deeper corpus): joins automatically for signed-in paid
tiers. When it was skipped, the response carries locked with an
unlock URL - mention it so the user knows a paid sign-in widens the
search.
Args: query: Question or topic (2-300 chars). locale: Optional article locale - "en" or "pl". limit: How many top passages per list (1-20, default 5).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| locale | No |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| locked | No | |
| articles | Yes | |
| knowledge | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses substantial behavior: it returns two ranked passage lists, explains the paid-tier knowledge corpus behavior, describes locked responses with an unlock URL, and tells the agent to mention the paid sign-in. This goes well beyond what annotations or the schema provide.
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 well-structured and front-loaded with purpose, usage, then return details and args. It is longer than minimal but every section earns its place; the only minor deduction is some redundancy between the opening summary and the detailed return-list explanation.
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 3-parameter read-only search tool with an output schema, the description is complete: it covers query intent, locale behavior, result shapes, citation URL construction, paid-tier locking behavior, and how to handle locked responses. No critical operational detail is missing.
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?
With schema description coverage at 0%, the description fully compensates by documenting each parameter: query semantics and length, locale allowed values, and limit meaning. This adds practical meaning beyond the raw schema constraints.
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 opens with a specific verb and resource ('Search the research'), clarifies the two-corpus behavior, and provides concrete example topics. This distinguishes it clearly from sibling tools like strategy or leaderboard, which are not knowledge-search tools.
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 when to use this tool ('Use when the user asks about a topic the research likely covers') and gives example topics. It does not explicitly state when not to use it or name alternatives, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One strategy's full dossier, including its backtest summary.
identifier is either the URL slug (e.g. ma-crossover) or the
algorithm_uid (ULID, e.g. 01J7...). Returns i18n names/descriptions,
family/variant/version metadata and the best_run backtest summary:
rozkoduj_score/rozkoduj_band (ranking axis), cagr (APY in the
instrument's local currency), cagr_usd (APY in USD - the cross-market
canon), max_drawdown, win_rate_pct, num_trades, the risk mode
(unit_risk_band, unit_risk_score), plus sparkline, params_public,
and data_start/data_end.
Use this after leaderboard once a candidate is chosen, or when the
user names a strategy directly. Raises a not-found error when no
strategy matches identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
| name | No | i18n: {en, pl} |
| slug | Yes | |
| family | No | |
| locked | No | |
| aliases | No | i18n alias maps |
| variant | No | |
| version | No | |
| best_run | No | |
| is_active | No | |
| created_at | Yes | |
| updated_at | Yes | |
| visibility | No | |
| description | No | i18n |
| algorithm_uid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds useful input-resolution details (URL slug vs `algorithm_uid`) plus precise return semantics such as `cagr` in local currency and `cagr_usd` as the canonical USD metric. However, it ends with an incomplete 'Raises a ...' and does not disclose error conditions, auth requirements, or rate limits, leaving a clear behavioral gap.
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 opening sentence is strong and the usage hint is useful, but the description repeats the entire identifier/returns/usage block verbatim, which is redundant and confusing. The incomplete 'Raises a ...' clause also breaks the structure, so the description is noticeably longer than it needs to be.
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 simple single-parameter, read-only tool with an output schema, the description covers identifier formats, exact returned fields, and the workflow trigger, which is nearly complete. The main missing piece is the truncated error clause, and the duplication adds noise, so it does not earn a 5.
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 carry all parameter meaning. It does this thoroughly: `identifier` is defined as either a URL slug (`ma-crossover`) or an `algorithm_uid` ULID (`01J7...`), with examples and format details. No parameter semantics are left to inference.
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 opens with a clear verb+resource: 'One strategy's full dossier, including its backtest summary.' It also specifies the retrieval key (`identifier`) and enumerates the returned metadata, making it easy to tell this detail lookup apart from the `leaderboard` listing. It does not explicitly differentiate from every sibling (`research`, `instrument`), but the title and single-parameter contract make 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit workflow guidance: 'Use this after `leaderboard` once a candidate is chosen, or when the user names a strategy directly.' That clearly situates the tool in a sequence and distinguishes it from a browsing/listing action. It stops short of a full 5 because it never states when not to use it or mentions other sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool addresses a distinct concern: research searches articles and knowledge, leaderboard ranks strategies, strategy returns one full dossier, and instrument handles the market catalog or dossier. The descriptions explicitly cross-reference when to use leaderboard versus strategy, so an agent should not confuse them.
All four tool names are single lowercase nouns representing the returned resource: research, strategy, instrument, and leaderboard. This is a clear and predictable convention with no mixed styles, verbs, or separators.
Four tools is well-scoped for a read-only research/analytics server: one for content search, one for rankings, one for strategy details, and one for instrument data. Each tool earns its place and the count is comfortably within the ideal 3-15 range.
The server covers the obvious read-only workflows: discover strategies via leaderboard, inspect a strategy's backtest via strategy, look up instruments via instrument, and search research via research. Cross-links prevent dead ends, such as using the same symbol in leaderboard to find strategies backtested on an instrument.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Crypto market signals, technical indicators, and sentiment analysis for AI agents.
Real-time market data, screeners, technical analysis & backtesting for stocks, crypto and forex.
Build, backtest, and deploy quantitative trading strategies from your AI agent.
Portfolio analytics + US-equity market research for AI clients. ChatGPT deep-research compat.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rozkoduj/rozkoduj-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
