Skip to main content
Glama
quality-screener

Quality Screener MCP Server

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PORTNoBind port for HTTP transports (Railway sets this automatically)
QSCREENER_TOKENNoBearer-token override for stdio mode (single user)
QSCREENER_API_URLNoBase URL of the Quality Screener backend API the tools callhttp://localhost:8001
QSCREENER_MCP_HOSTNoBind host for HTTP transports0.0.0.0
QSCREENER_MCP_PORTNoBind port fallback when PORT is unset8080
QSCREENER_CONFIG_DIRNoDirectory holding credentials.json for stdio mode~/.config/qscreener
QSCREENER_WEBSITE_URLNoWeb-app base URL used to build the OAuth browser-login link and shareable screen URLshttp://localhost:3001
QSCREENER_MCP_TRANSPORTNoTransport mode: stdio, streamable-http, or ssestdio
QSCREENER_MCP_PUBLIC_URLNoPublicly reachable base URL of this server; used to build the OAuth callback URLhttp://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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 (duplicates as ticker strings, description truncated); pass full_rows=True for the raw backend payload.

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 scoring_system_id is given (which requires being signed in and owning that system). Tickers with no score are omitted from the response. Results are sorted by quality score descending.

Rows are slimmed for MCP by default (duplicates as ticker strings, description truncated); pass full_rows=True for the raw backend payload.

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 data (one row per found ticker), pagination (total_count = number found), and aggregates.

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 config is a CustomScoreConfig: weighted metric groups (each with weighted metrics) plus scoring parameters winsorizePercentile (1-10), missingDataPercentile (0.1-0.5), normalizeGroupZScores and includeDuplicatesInScoring (booleans). Loose inputs (snake_case keys, legacy winsorize/zScore flags) are normalized automatically.

Scoring happens in two stages, and they answer different questions.

Stage 1 — scoring_universe: who is in the peer group. Quality scores are relative: each company is winsorized and z-scored against a population. Narrowing this changes every score and can reorder the list. Accepts sectors, industries, regions, countries, currencies, exchanges, min_market_cap_usd and max_market_cap_usd. Omit it to score against the whole universe.

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 scoring_universe={"sectors": ["Technology"], "regions": ["Europe"]}, while "best European tech judged against the world" is sectors=["Technology"], regions=[...] as stage-2 arguments. The response's scoring_universe field reports the peer group and its size — scores computed against different peer groups are not comparable, so do not mix them in one table.

Two things do not fit the split cleanly, and both are deliberate:

  • min_market_cap_usd as a stage-2 argument also floors the scoring population (a long-standing backend behaviour). Set min_market_cap_usd inside scoring_universe to control the peer group explicitly; it overrides the stage-2 floor. max_market_cap_usd filters rows only unless set in scoring_universe.

  • min_score/max_score/ticker/tickers cannot appear in scoring_universe: the first two filter on the scores being computed, the rest select rows. Passing them there returns an error rather than being ignored.

A nested config['filters'] block is saved-screen state, persisted by screen_share/systems_create/systems_update so a screen restores its view. Passing a saved config here applies that block as stage-2 filters (an explicit argument below wins), matching what the web app does — it never defines the peer group.

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 groups, scoring parameters (winsorizePercentile, missingDataPercentile, normalizeGroupZScores, includeDuplicatesInScoring), and an optional nested filters block. Loose inputs (snake_case keys, legacy winsorize/zScore flags, or top-level filter keys) are normalized to this shape so the shared link always renders.

Returns: dict with url (the shareable link to copy-paste), slug (the short identifier), created (True if newly created, False if an identical screen already existed), and view_count.

filters_listA

Return available filter values (sectors, industries, countries, currencies, exchanges).

tickers_listA

Return available tickers, optionally truncated to limit.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 23 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Maintenance

ActivityActive
ResponsivenessUnresponsive