Skip to main content
Glama

Agent Rynku - Warsaw Stock Exchange (GPW) data for your agent

by pl.agentrynku
OverviewDiscussionsAdmin

Server Details

Public GPW daily prices, financials, ratios, company search, earnings calendar and WZA dividends.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 37 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
krystiangw/agentrynku-mcp
GitHub Stars
0
Server Listing
Agent Rynku MCP

TDQS

A4/5.0

Scored across 6 tools

Disambiguation4/5

Most tools have clearly distinct purposes: company search, price history, dividends, earnings calendar, ratios, and quarterly KPIs. The main potential ambiguity is between get_financial_ratios and get_quarterly_kpis, since both expose quarterly financial data, though their descriptions clarify that one provides computed margins/balance ratios and the other raw reported KPIs.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern: get_* or search_* followed by a clear resource name. There are no mixed conventions or vague names.

Tool Count5/5

Six tools is well-scoped for a focused GPW data server. Each tool covers a distinct data need, and there is no excessive surface area or obviously redundant tool.

Completeness4/5

The set covers core equity-research workflows: company lookup, price history, quarterly KPIs, financial ratios, dividends, and earnings calendar. Some gaps remain, such as broader company profile metadata, market/index data, or live quotes, but these are either explicitly out of scope or workable via existing tools.

Available Tools

6 tools
get_financial_ratiosFinancial ratios of a GPW companyB
Read-onlyIdempotent
Inspect

GPW quarterly financial ratios from published, quality-gated reports: EBITDA, operating, net profit margins, plus equity/assets. Each percentage includes its formula and report basis. Null means missing, withheld or nonpositive denominator. No price-based valuation multiples or TTM estimates.

NameRequiredDescriptionDefault
symbolYes
quartersBackNo

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare the tool as read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context beyond annotations: reports are quality-gated, each percentage includes its formula and report basis, and null values have a specific meaning. It does not discuss rate limits or data freshness, but the added transparency is substantial.

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 three tight sentences, front-loads the core resource and ratio families, then adds important null semantics and exclusions. Every sentence contributes useful information without repetition.

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?

The description covers what the tool returns and how nulls should be interpreted, and annotations cover the safety profile. However, with no output schema and 0% schema description coverage, the missing parameter explanations leave the agent without enough information to confidently supply symbol and quartersBack.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain either parameter. It does not state that symbol is required or whether it is a ticker/identifier, and it does not describe quartersBack, its default of 8, or its allowed range of 1–20.

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 names a specific resource and scope: quarterly financial ratios for a GPW company, including margins and equity/assets. It lists the exact ratio families covered and explicitly excludes price-based multiples and TTM estimates, though it does not directly differentiate itself from the sibling get_quarterly_kpis.

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 gives an implied usage boundary by excluding price-based valuation multiples and TTM estimates, which helps an agent know this is not a valuation-multiple tool. However, it does not explicitly say when to use this tool versus get_quarterly_kpis, get_public_price_history, or other siblings.

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

get_public_dividendsGPW dividend resolutionsA
Read-onlyIdempotent
Inspect

Known GPW dividend resolutions from issuer WZA announcements only, with amount per share, currency, status, dates and source URLs. Limited coverage: excludes market data vendor history and predictions. An empty result does not mean the company pays no dividend. Latest resolution generation is retained, including cancellations.

NameRequiredDescriptionDefault
limitNo
symbolYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered; the description adds real value beyond that by disclosing source restriction (issuer announcements only) and result semantics (empty ≠ no dividend, latest generation retained including cancellations). It says nothing about ordering, pagination or what a truncated result looks like despite a limit param.

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?

Four short sentences, front-loaded with the resource and its provenance before the caveats; every sentence carries information. The weak point is a lack of structural separation between "what you get back" and "how to interpret it", which makes it read as one dense run-on.

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?

With no output schema, the description usefully enumerates the returned fields (amount per share, currency, status, dates, source URLs) and sets expectations about coverage gaps. The missing piece is input guidance: an agent still cannot tell what to put in `symbol`, which is the one required parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description never mentions either parameter: nothing on what `symbol` accepts (GPW ticker? ISIN? case sensitivity? the maxLength 80 is unexplained) and nothing on `limit` beyond the schema defaults. The per-share/currency/date detail describes the response, not the inputs, so the two undocumented parameters are left to guesswork.

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

Purpose5/5

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

States a specific resource (GPW dividend resolutions), its data origin (issuer WZA announcements only) and its payload (amount per share, currency, status, dates, source URLs). The scope language plainly separates it from get_public_price_history and get_public_earnings_calendar without those siblings being named.

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?

"Limited coverage: excludes market data vendor history and predictions" plus "An empty result does not mean the company pays no dividend" gives explicit when-not-to-trust guidance, which is unusually good. It stops short of naming a sibling alternative for the excluded data, so it is not a full when/when-not/alternatives statement.

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

get_public_earnings_calendarGPW earnings calendarA
Read-onlyIdempotent
Inspect

Get known scheduled GPW reports over the next 1 to 90 days, including today in Warsaw. Covers the public market calendar, without a personal watchlist. Includes source and fetch date, removes dates superseded by published results, and declares truncation. An empty result is not proof that no companies will report.

NameRequiredDescriptionDefault
limitNo
daysAheadNo

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantive behavior beyond that: it includes source and fetch date, removes dates superseded by published results, and declares truncation. The empty-result caveat is a genuinely useful semantic warning an agent could not infer from 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?

Short and front-loaded: the core action and time window come first, with behavioral caveats appended in compact clauses. No sentence is filler.

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?

There is no output schema, and the description compensates by explaining what the response contains (source, fetch date, truncation flag, superseded-date removal). Only the limit parameter's meaning is left implicit, a minor gap for a two-param read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the param burden. It explains the meaning and range of daysAhead ('next 1 to 90 days, including today in Warsaw'), which matches the schema bounds, but the limit parameter goes unmentioned and no guidance is given on default sizing or truncation interaction.

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

Purpose5/5

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

States a specific verb and resource ('Get known scheduled GPW reports') plus the exact scope ('next 1 to 90 days, including today in Warsaw'). It also distinguishes itself from a personal watchlist, so an agent can separate it from the sibling tools that cover dividends, ratios, prices, and company search.

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 'public market calendar, without a personal watchlist' clause gives a clear condition for when this tool applies. It doesn't explicitly name an alternative when a personal view is needed, so it stops short of the explicit when/when-not/alternatives tier.

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

get_public_price_historyGPW daily price historyA
Read-onlyIdempotent
Inspect

Stored GPW daily OHLCV price history without an account. Returns the latest up to 500 candles within 1-3650 calendar days, in chronological order, with truncation, source, stored-series update timestamp and actual candle dates. Coverage may be shorter than requested. Per-candle priceScale and adjustment metadata are preserved; unknown means unrecorded, currency null means not recorded. Adjusted history can change after splits or dividends. No intraday, live quote or supplier fetch on demand. GPW equities only, excluding indices, ETFs and bonds; use ticker or ISIN.

NameRequiredDescriptionDefault
daysNo
limitNo
symbolYes

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, yet the description adds substantial context: results are chronological and truncated, coverage may be shorter than requested, adjusted history can change after splits or dividends, and 'unknown'/'null' field semantics are explained. This is exactly the extra context annotations cannot convey.

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

Conciseness4/5

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

Front-loaded with purpose and budget-aware; nearly every clause carries new information. The telegraphic, semicolon-heavy style makes it slightly harder to scan than it needs to be, but there is no filler.

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?

There is no output schema, so the description must describe returns — and it does, covering truncation, source, stored-series update timestamp, actual candle dates, per-candle priceScale and adjustment metadata. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry all parameter meaning — and it does: 'up to 500 candles' (limit), '1-3650 calendar days' (days), and 'use ticker or ISIN' (symbol). It does not explain the interaction between days and limit when both constrain the result, leaving one real ambiguity.

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

Purpose5/5

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

States a specific verb and resource (returns stored GPW daily OHLCV price history) with explicit scope boundaries: equities only, excluding indices, ETFs and bonds, no intraday/live/supplier fetch. An agent can tell immediately this is the historical daily bar tool and not one of the unrelated siblings.

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?

Gives clear when-not conditions (no intraday, no live quote, no on-demand supplier fetch) and prescribes the identifier forms (ticker or ISIN). It does not name a specific alternative tool to use for intraday or live data, so the routing is broad rather than explicit.

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

get_quarterly_kpisQuarterly results of a GPW companyA
Read-onlyIdempotent
Inspect

Quarterly financial KPIs of a GPW company: revenue, EBITDA, EBIT, net income, EPS, balance sheet and cash flow, reported and adjusted. Instruments resolve by ticker, alias or ISIN. Coverage varies by company and quarter, and missing data is not zero. Monetary ...PLN fields are in millions of the issuer's reporting currency, given in the row's currency field, which can be EUR or USD; EPS fields are per share. values.<field> carries value, currency, unit, report date and source URL, and a field without complete provenance is absent. dataQuality.blocksComputation: true marks a row our checks do not trust. withheld lists fields returned as null by a data-quality rule, with the rule and reason; a null can also mean the field was excluded as not issuer-sourced. reportScope tells standalone from consolidated figures, and is null when unknown.

NameRequiredDescriptionDefault
symbolYesRequired. XTB-style 'KGH.PL' canonicalized.
quartersBackNoHow many recent quarters to return. Default 8, max 20.

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond readOnly/idempotent annotations: warns that coverage varies, that missing data is not zero, that monetary fields are in millions of the issuer's reporting currency (EUR or USD, not necessarily PLN despite the field suffix), and that fields lacking complete provenance are absent. The dataQuality.blocksComputation and withheld semantics explain why a null appears — exactly the non-obvious behavior an agent would otherwise misread.

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

Conciseness4/5

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

Front-loads purpose in the first clause, then moves to resolution rules and then to return-value caveats in a logical order; every sentence carries information. It is dense and backtick-heavy, sitting near the upper limit of comfortable length, but nothing is redundant.

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?

With no output schema, the description must explain the response shape and it does: values.<field> internals, currency/unit/report date/source URL provenance, reportScope standalone vs consolidated, and the null-vs-withheld distinction. An agent can interpret the payload correctly without guessing.

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 both parameters are already documented, giving a baseline of 3. The description adds only that instruments resolve by ticker, alias or ISIN, which extends the schema's narrow 'KGH.PL canonicalized' note but does not clarify quartersBack behavior.

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?

States a specific verb+resource and enumerates the KPI families (revenue, EBITDA, EBIT, net income, EPS, balance sheet, cash flow) plus reported vs adjusted. It is distinguishable in substance from get_financial_ratios and get_public_price_history, but it never names those siblings, so route selection rests on the agent's own inference.

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?

Usage is only implied: the quarterly-KPI framing suggests annual/ratio/dividend queries belong elsewhere, but no explicit when-to-use or when-not statement and no named alternative appear. The agent must infer the boundary from the sibling names alone.

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

search_gpw_companiesSearch GPW companiesA
Read-onlyIdempotent
Inspect

Find active GPW companies by name, ticker, alias or ISIN before requesting financial data. Returns canonical symbols, ISIN and public company URLs; does not search other markets. Results are bounded and truncated is explicit.

NameRequiredDescriptionDefault
limitNo
queryYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and closed-world. The description adds genuinely new context: what is returned (canonical symbols, ISIN, public URLs) and that results are bounded with truncation made explicit. Minor gap: doesn't say how truncation is signalled.

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 tight sentences, front-loaded with purpose, then scope and return-value/truncation notes. No filler.

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?

With no output schema, the description appropriately names the returned fields and the truncation behavior, and annotations already cover the safety profile. It could be slightly more explicit about limit semantics, but an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the load. It explains the query parameter's accepted forms well (name, ticker, alias, ISIN) and hints at result bounding, but never clarifies the limit parameter's default, range, or that it controls result count.

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

Purpose5/5

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

States a specific verb and resource ('Find active GPW companies') plus the searchable fields (name, ticker, alias, ISIN). Explicitly scopes to a single market, so an agent can distinguish it from the sibling financial-data tools without inspecting the schema.

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

Usage Guidelines4/5

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

The phrase 'before requesting financial data' positions it as the lookup step preceding the sibling tools, and 'does not search other markets' is a clear exclusion. It stops short of naming a sibling tool or stating failure/empty-result handling, so not a full 5.

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.

  1. 1 tool update
    • Addedget_public_price_history
  2. 98 tool updates
    • Removedanalyze_thesis_exposure
    • Removedanalyze_trade_outcome
    • Removedcalculate_early_redemption
    • Removedcancel_priced_event
    • Removedclaim_feature_request
    • Removedcompare_portfolio_risk_reward
    • Removedcompare_symbols
    • Removedcreate_decision_rule
    • Removeddelete_decision_rule
    • Removedfind_dip_candidates
    • Removedfind_opportunities
    • Removedfind_overheat_candidates
    • Removedfind_tlh_opportunities
    • Removedget_activity_feed
    • Removedget_alert_delivery_stats
    • Removedget_alerts
    • Removedget_asset_signals
    • Removedget_bond_orderbook
    • Removedget_bond_series
    • Removedget_codex_pipeline_stats
    • Removedget_company_analysis
    • Removedget_company_dossier
    • Removedget_concentration_risk
    • Removedget_conference_reminders
    • Removedget_conference_summary
    • Removedget_cross_market_peers
    • Removedget_daily_brief
    • Removedget_dividends
    • Removedget_drivers
    • Removedget_earnings_calendar
    • Removedget_earnings_deepdive
    • Removedget_evaluation_outcomes
    • Removedget_event_risks
    • Removedget_factor_context
    • Addedget_financial_ratios
    • Removedget_forecast
    • Removedget_forecast_accuracy
    • Removedget_intraday_candles
    • Removedget_intraday_quote
    • Removedget_market_anomalies
    • Removedget_my_alert_performance
    • Removedget_news_history
    • Removedget_outcome_settlement_health
    • Removedget_pipeline_health
    • Removedget_portfolio_analytics
    • Removedget_portfolio_context
    • Removedget_portfolio_stats
    • Removedget_portfolio_value_history
    • Removedget_price_series
    • Removedget_priced_events
    • Addedget_public_dividends
    • Addedget_public_earnings_calendar
    • Changedget_quarterly_kpis4 fields changed
      • addedInput schema / properties / quartersBack / default
        Added value: +8
      • addedInput schema / properties / quartersBack / maximum
        Added value: +20
      • addedInput schema / properties / quartersBack / minimum
        Added value: +1
      • changedInput schema / properties / quartersBack / type
        Previous value: -"number"New value: +"integer"
    • Removedget_ranking_performance
    • Removedget_realized_pnl
    • Removedget_report_event
    • Removedget_risk_dashboard
    • Removedget_risk_regime
    • Removedget_risk_themes
    • Removedget_signal_prediction_performance
    • Removedget_spot_price
    • Removedget_stock_rankings
    • Removedget_sygnal_score
    • Removedget_top_opportunities
    • Removedget_total_portfolio_view
    • Removedget_transaction_history
    • Removedget_wza_summary
    • Removedhistorical_event_hit_rate
    • Removedlist_decision_rule_proposals
    • Removedlist_decision_rules
    • Removedlist_feature_requests
    • Removedlist_webhook_events
    • Removedmacro_attribution
    • Removedmodify_chat_settings
    • Removedmodify_holdings
    • Removedmodify_profile
    • Removedmodify_watchlist
    • Removedquery_companion
    • Removedrank_revenue_growth
    • Removedrank_thematic
    • Removedrecommend_diversification
    • Removedrecommend_position_size
    • Removedresolve_priced_event_now
    • Removedrun_predictive_scan
    • Removedscreen_stocks
    • Addedsearch_gpw_companies
    • Removedsector_pulse_pl
    • Removedset_agent_prefs
    • Removedset_cash_balance
    • Removedsubmit_alert_feedback
    • Removedsubmit_broker_transactions
    • Removedsubmit_feature_request
    • Removedsubmit_portfolio_snapshot
    • Removedsuggest_order_size
    • Removedtrack_priced_event
    • Removedupdate_decision_rule
    • Removedupdate_priced_event
    • Removedwhats_moving_now
  3. 1 tool update
    • Changedget_stock_rankings1 field changed
      • changedInput schema / properties / minAdvPLN / description
        Previous value: -"Dodatkowy filtr ADV w PLN. Overall zawęża opublikowanych członków bez zmiany ich rang. Pozostałe kategorie: defensive 1000000, dividend 100000, growth 1000000."New value: +"Dodatkowy filtr ADV w PLN. Zawęża opublikowanych członków bez zmiany ich rang. Próg samego przebiegu to od 29.09.2026 50000 w overall, growth, dividend i defensive (plus obrót w 80% z 63 sesji)."
  4. 1 tool update
    • Addedscreen_stocks
  5. 1 tool update
    • Changedmodify_watchlist1 field changed
      • removedInput schema / properties / setAlertsActive
        Removed value: -{
-  "description": "Free plan: choose which watchlist symbols get news alerts (at most 5 active). Enabling a sixth is refused and comes back in `alertsRejectedByLimit`; disable another first. On PRO every symbol has alerts and this is a no-op (`alertsAlwaysOn`).",
-  "items": {
-    "properties": {
-      "active": {
-        "description": "true = send news alerts for this watchlist symbol, false = keep it on the list without alerts.",
-        "type": "boolean"
-      },
-      "symbol": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "symbol",
-      "active"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}
  6. 1 tool update
    • Changedmodify_watchlist1 field changed
      • addedInput schema / properties / setAlertsActive
        Added value: +{
+  "description": "Free plan: choose which watchlist symbols get news alerts (at most 5 active). Enabling a sixth is refused and comes back in `alertsRejectedByLimit`; disable another first. On PRO every symbol has alerts and this is a no-op (`alertsAlwaysOn`).",
+  "items": {
+    "properties": {
+      "active": {
+        "description": "true = send news alerts for this watchlist symbol, false = keep it on the list without alerts.",
+        "type": "boolean"
+      },
+      "symbol": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "symbol",
+      "active"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  7. 2 tool updates
    • Changedtrack_priced_event1 field changed
      • changedInput schema / properties / thesisRef / description
        Previous value: -"Optional ObjectId of a PositionThesis (FR A)."New value: +"Optional legacy user thesis id (old position_theses id, still recorded on the ledger claim)."
    • Changedupdate_priced_event1 field changed
      • changedInput schema / properties / thesisRef / description
        Previous value: -"Cross-link to a PositionThesis ObjectId (must belong to user). Empty string clears the link."New value: +"Cross-link to a legacy user thesis id (old position_theses id still recorded on the ledger claim, must belong to user). Empty string clears the link."
  8. 5 tool updates
    • Changedcompare_symbols1 field changed
      • changedInput schema / properties / metrics / description
        Previous value: -"Optional subset. Default: ['lastClose','changePct30d','realizedVolPctAnnualized','sentimentAvg30d','alertCount30d','impliedUpsidePct','sanityFiltered','impliedPriceUnavailableReason','sector','inPortfolio','inWatchlist']. Unknown metrics ignored."New value: +"Optional subset. Default includes lastClose, price change, volatility, sentiment, alerts, impliedUpsidePct, valuation availability, sector and membership. With FREE/PRO enabled, FREE gets null impliedUpsidePct even when requested. Unknown metrics ignored."
    • Changedfind_dip_candidates1 field changed
      • changedInput schema / properties / minScore / description
        Previous value: -"Default 55. Minimum overall Agent Rynku score, to avoid value traps."New value: +"PRO only. Default 55. Minimum overall Agent Rynku score, to avoid value traps. FREE uses the default."
    • Changedfind_opportunities1 field changed
      • changedInput schema / properties / minImpliedUpsidePct / description
        Previous value: -"Minimum forecast.impliedUpsidePct (vs spot) to include. Default 5 — typically a meaningful target threshold."New value: +"PRO only: minimum forecast.impliedUpsidePct (vs spot) to include. Default 5; ignored for FREE when FREE/PRO is enabled."
    • Changedfind_overheat_candidates1 field changed
      • changedInput schema / properties / maxScore / description
        Previous value: -"Default 50. ⚠️ This is NOT an exclusion filter, despite how the name reads: it only decides whether the Agent-Rynku-score CONFIRMATION counts, and one confirmation out of three is enough for `trim_candidate`. A symbol above the threshold still shows up when price >=125% SMA200 or vol is high — its `reason` then names the missing signal explicitly. Measured 2026-08-05 on 55 scanned symbols: 5 of 12 trim candidates had a score at or above the default 50 (PKNORLEN 52, ALLEGRO 54, ANET 53, ZABKA 61, AMZN 59), each held in by a stretched SMA200 or high vol. Lowering the value saturates for the same reason: 20 and 5 both return 9 trim candidates. To drop a symbol entirely you need the separate `trend_continuation` rule (score >=55 with vol not high), which this parameter does not move."New value: +"PRO only. Default 50. This controls one of three confirmations for `trim_candidate`, not whether a symbol is included. The separate `trend_continuation` rule uses score >=55 and is unaffected. FREE uses the default."
    • Changedrun_predictive_scan1 field changed
      • changedInput schema / properties / pricingInPenaltyWeight / description
        Previous value: -"Weight applied to the pricing-in penalty. Default 1.0; set 0 to disable."New value: +"PRO only. Weight applied to the pricing-in penalty. Default 1.0; set 0 to disable. FREE uses the default and receives ranking order without exact score."
  9. 1 tool update
    • Changedmodify_chat_settings1 field changed
      • changedInput schema / properties / mutedAlertClassifications / description
        Previous value: -"Mute-lista klasyfikacji alertów — te typy nie będą wysyłane realtime. Pusta = nic nie wyciszone."New value: +"Mute-lista klasyfikacji alertów — te typy nie będą wysyłane jako alerty o nowych zdarzeniach. Pusta = nic nie wyciszone."
  10. 93 tool updates
    • First observedanalyze_thesis_exposure
    • First observedanalyze_trade_outcome
    • First observedcalculate_early_redemption
    • First observedcancel_priced_event
    • First observedclaim_feature_request
    • First observedcompare_portfolio_risk_reward
    • First observedcompare_symbols
    • First observedcreate_decision_rule
    • First observeddelete_decision_rule
    • First observedfind_dip_candidates
    • First observedfind_opportunities
    • First observedfind_overheat_candidates
    • First observedfind_tlh_opportunities
    • First observedget_activity_feed
    • First observedget_alert_delivery_stats
    • First observedget_alerts
    • First observedget_asset_signals
    • First observedget_bond_orderbook
    • First observedget_bond_series
    • First observedget_codex_pipeline_stats
    • First observedget_company_analysis
    • First observedget_company_dossier
    • First observedget_concentration_risk
    • First observedget_conference_reminders
    • First observedget_conference_summary
    • First observedget_cross_market_peers
    • First observedget_daily_brief
    • First observedget_dividends
    • First observedget_drivers
    • First observedget_earnings_calendar
    • First observedget_earnings_deepdive
    • First observedget_evaluation_outcomes
    • First observedget_event_risks
    • First observedget_factor_context
    • First observedget_forecast
    • First observedget_forecast_accuracy
    • First observedget_intraday_candles
    • First observedget_intraday_quote
    • First observedget_market_anomalies
    • First observedget_my_alert_performance
    • First observedget_news_history
    • First observedget_outcome_settlement_health
    • First observedget_pipeline_health
    • First observedget_portfolio_analytics
    • First observedget_portfolio_context
    • First observedget_portfolio_stats
    • First observedget_portfolio_value_history
    • First observedget_price_series
    • First observedget_priced_events
    • First observedget_quarterly_kpis
    • First observedget_ranking_performance
    • First observedget_realized_pnl
    • First observedget_report_event
    • First observedget_risk_dashboard
    • First observedget_risk_regime
    • First observedget_risk_themes
    • First observedget_signal_prediction_performance
    • First observedget_spot_price
    • First observedget_stock_rankings
    • First observedget_sygnal_score
    • First observedget_top_opportunities
    • First observedget_total_portfolio_view
    • First observedget_transaction_history
    • First observedget_wza_summary
    • First observedhistorical_event_hit_rate
    • First observedlist_decision_rule_proposals
    • First observedlist_decision_rules
    • First observedlist_feature_requests
    • First observedlist_webhook_events
    • First observedmacro_attribution
    • First observedmodify_chat_settings
    • First observedmodify_holdings
    • First observedmodify_profile
    • First observedmodify_watchlist
    • First observedquery_companion
    • First observedrank_revenue_growth
    • First observedrank_thematic
    • First observedrecommend_diversification
    • First observedrecommend_position_size
    • First observedresolve_priced_event_now
    • First observedrun_predictive_scan
    • First observedsector_pulse_pl
    • First observedset_agent_prefs
    • First observedset_cash_balance
    • First observedsubmit_alert_feedback
    • First observedsubmit_broker_transactions
    • First observedsubmit_feature_request
    • First observedsubmit_portfolio_snapshot
    • First observedsuggest_order_size
    • First observedtrack_priced_event
    • First observedupdate_decision_rule
    • First observedupdate_priced_event
    • First observedwhats_moving_now

Related MCP Connectors

Related MCP Servers

  • Screener MCP Server

    sahiljani
    F
    license
    A
    quality
    D
    maintenance
    MCP server for Indian stock market data — search companies, analyze fundamentals, compare stocks, browse sectors and screens.
    11
    -

  • stockscreen-mcp

    xang1234
    A
    license
    A
    quality
    A
    maintenance
    Daily stock screens, RS ratings, market breadth and group rankings for 12 markets. No API keys.
    20
    6
    404
    Apache 2.0
  • akyla-mcp by AkilaAnalytics

    akyla-mcpofficial

    AkilaAnalytics
    A
    license
    A
    quality
    D
    maintenance
    Provides as-reported US equity fundamentals, live quotes, financial statements, valuation comps, and a screener from SEC filings, with per-cell filing provenance for citations.
    7
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources