Quality Screener MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Bind port for HTTP transports (Railway sets this automatically) | |
| QSCREENER_TOKEN | No | Bearer-token override for stdio mode (single user) | |
| QSCREENER_API_URL | No | Base URL of the Quality Screener backend API the tools call | http://localhost:8001 |
| QSCREENER_MCP_HOST | No | Bind host for HTTP transports | 0.0.0.0 |
| QSCREENER_MCP_PORT | No | Bind port fallback when PORT is unset | 8080 |
| QSCREENER_CONFIG_DIR | No | Directory holding credentials.json for stdio mode | ~/.config/qscreener |
| QSCREENER_WEBSITE_URL | No | Web-app base URL used to build the OAuth browser-login link and shareable screen URLs | http://localhost:3001 |
| QSCREENER_MCP_TRANSPORT | No | Transport mode: stdio, streamable-http, or sse | stdio |
| QSCREENER_MCP_PUBLIC_URL | No | Publicly reachable base URL of this server; used to build the OAuth callback URL | http://localhost:{PORT|8080} |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| auth_statusA | Report whether a CLI token is present and which user it authenticates as. |
| healthA | Check API and database health. |
| account_profileA | Return the signed-in user's profile (email, username, organization). |
| scores_listB | List scored tickers with optional filters. Market caps are in USD. Rows are slimmed for MCP by default ( |
| scores_topB | Return the top tickers by quality score as a {ticker: score} map. |
| scores_showB | Return the score row(s) for a single ticker. |
| scores_for_tickersA | Return current scores for a specific list of tickers. Looks up the latest score for each requested ticker under the default quality
score, or under a saved scoring system when Rows are slimmed for MCP by default ( Args: tickers: Exact ticker symbols to score (e.g. ["AAPL", "MSFT", "ASML.AS"]). scoring_system_id: Optional saved scoring-system id; omit for default scoring. full_rows: Return unmodified rows (embedded duplicate rows, full descriptions). Returns:
dict: A ScoreListResponse with |
| scores_statisticsB | Return min/max/average score statistics for a filtered universe. |
| scores_market_capB | Return aggregated total market cap (USD) for a filtered universe. |
| score_computeA | Compute custom scores from a CustomScoreConfig, scored against a chosen peer group. The Scoring happens in two stages, and they answer different questions. Stage 1 — Stage 2 — the filter arguments below: which rows come back. Applied after scoring, so they never change a score. They accept the same keys as stage 1, so any filter can be asked either way. OR logic within a filter, AND across filters. So "best European tech judged against European tech" is
Two things do not fit the split cleanly, and both are deliberate:
A nested |
| screen_shareA | Create a shareable link for a screen (CustomScoreConfig) and return its URL. Persists the screen configuration and returns a short, public link that can be copy-pasted to anyone — recipients open it to view and load the exact screen. The link is content-addressed: sharing an identical config returns the same URL instead of creating a duplicate. Args:
config: The complete CustomScoreConfig to share — weighted metric Returns:
dict with |
| filters_listA | Return available filter values (sectors, industries, countries, currencies, exchanges). |
| tickers_listA | Return available tickers, optionally truncated to |
| tickers_searchA | Search available tickers by case-insensitive substring. |
| history_tickerA | Return score history for a single ticker (dates: YYYY-MM-DD). |
| history_batchA | Return score history for several tickers at once. |
| history_topB | Fetch the top-N tickers and return their score history. |
| systems_listA | List the user's saved scoring systems. |
| systems_showA | Show a saved scoring system by ID. |
| systems_createB | Create a saved scoring system from a config object. |
| systems_updateC | Update a saved scoring system. |
| systems_deleteB | Delete a saved scoring system. |
| systems_applyA | Apply a saved scoring system (increments its usage count). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Most tools map to a distinct resource/action (scores queries, history, systems CRUD, tickers/filters), and the descriptions clearly separate custom score computation from canned score lookups. A few pairs overlap conceptually, such as scores_list vs scores_top or auth_status vs account_profile, but their output shapes and inputs make them distinguishable.
Tool names are predominantly snake_case and follow a resource-prefix pattern like scores_*, systems_*, history_*, and tickers_*. Minor deviations such as score_compute (singular vs the plural scores_* family), screen_share (noun_verb rather than resource_verb), and the non-action names auth_status/health keep it from being fully consistent.
At 23 tools the surface is heavy and falls in the borderline 16-25 range; some tools like scores_top, scores_for_tickers, and history_top overlap with list/batch operations and could be consolidated. The broad scope (auth, scores, screens, systems, history) justifies most of the count, but it is not tight.
Core workflows are well covered: score retrieval, custom score computation, saved-system CRUD, screen sharing, filters, tickers, history, and health/auth. Minor gaps exist, such as no way to fetch a shared screen by slug and no direct score-comparison tool, but agents can work around these without dead ends.