Quality Screener MCP Server

score_compute

Read-only

Compute custom quality scores against a selected peer group using weighted metrics, winsorization, and z-scoring; filter results by sector, region, or market cap.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Default
`limit`	No
`config`	Yes
`offset`	No
`regions`	No
`sectors`	No
`sort_by`	No	quality_score
`countries`	No
`exchanges`	No
`currencies`	No
`industries`	No
`sort_order`	No	desc
`scoring_universe`	No
`include_duplicates`	No
`max_market_cap_usd`	No
`min_market_cap_usd`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Sep 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only supply readOnlyHint and openWorldHint; the description adds substantial behavioral disclosure: two-stage scoring, filters applied after scoring, OR/AND logic, the min_market_cap_usd backend floor quirk, error behavior for invalid scoring_universe keys, and saved-screen config handling. 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?

Long but tightly structured: a one-line summary, bolded stage headers, concrete examples, and a dedicated paragraph for edge cases. Each section adds a distinct rule, and the length is warranted by 15 parameters and zero schema coverage.

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?

Covers invocation semantics, filter logic, config details, edge cases, and the saved-state path from screen_share/systems tools. The main gap is return/pagination details: limit, offset, sort_by, sort_order, and the general response shape are not described, and there is no output schema to fill that gap.

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 description coverage is 0%, and the description compensates for most non-obvious parameters: config structure, scoring_universe keys, filter keys, min/max market cap asymmetry, and loose-input normalization. It omits limit/offset/sort_by/sort_order and the top-level include_duplicates parameter, but those are simpler and more inferable.

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: 'Compute custom scores from a CustomScoreConfig, scored against a chosen peer group.' The detailed two-stage explanation and concrete examples make the tool's purpose clear and distinguish it from standard score-listing siblings like scores_top and scores_list, even though no sibling is 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?

Clearly explains when to put criteria in scoring_universe vs stage-2 filters, with explicit examples and exclusions: min_score/max_score/ticker/tickers cannot go in scoring_universe, and min_market_cap_usd has special peer-group behavior. It does not explicitly name alternative sibling tools, but the usage boundaries are unambiguous.

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

score_compute

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools