Percentile fingerprints, curated peers, theme clusters & market-stress context for US stocks.
The 16 percentile scores + P3 + 1Y price change for 2-5 tickers as one compact matrix (rows = metrics, columns = tickers). Use when weighing names against each other; percentiles make the comparison fair across sectors and sizes.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | 2-5 US tickers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by specifying the exact metric composition (16 percentile scores + P3 + 1Y price change) and the matrix layout (rows = metrics, columns = tickers), which an agent could not infer from annotations or the minimal schema.
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?
Two dense sentences carry the full purpose, output shape, and usage context with no filler. The core output definition is front-loaded, and every clause earns its place.
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 single-parameter read-only comparison tool, the description is largely complete: it defines the input range, the exact metrics, the matrix orientation, and the intended use case. The only minor gap is that 'P3' is not expanded, which could confuse an agent unfamiliar with the domain, but this does not prevent correct tool selection or 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?
The schema already documents the only parameter, tickers, as '2-5 US tickers' with minItems and maxItems constraints, so schema coverage is 100%. The description reinforces the 2-5 range but does not add meaningful semantic detail beyond what the schema provides, matching the baseline of 3.
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 names a specific operation and resource: comparing fingerprints side by side, with a precise output definition (16 percentile scores + P3 + 1Y price change for 2-5 tickers as a matrix). This clearly distinguishes it from siblings like fingerprint or peers, which would not produce a multi-ticker comparison matrix.
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 it: 'when weighing names against each other' and explains why percentiles are appropriate for fair comparison. It does not name alternatives or give exclusion conditions, but the context is clear enough for an agent to select this tool over the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The character of one stock in ~550 tokens: 16 percentile scores (vs the S&P 500 cohort) across four panels — Market Beat, Trend Persistence, Business Growth, Pressure (money flow) — plus the composite P3 score (the validated 3-factor form), curated competitive peers (not GICS), a one-line character read, and the price line. Use for 'is this number good?' and quick company character.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | RESERVED (phase 2): YYYY-MM-DD point-in-time snapshot; currently only the live snapshot is served | |
| ticker | Yes | US ticker, e.g. NVDA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the token budget, the percentile-based framing, the four panel names, the composite P3 score, and the inclusion of curated peers. This goes well beyond what the annotations alone convey, with no contradiction.
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 dense but efficient, front-loading the core outcome ('The character of one stock in ~550 tokens') before listing components and ending with use cases. Every clause contributes useful information, and nothing is redundant with the schema.
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?
With no output schema, the description carries the burden of explaining return values, and it does so well by enumerating the major output sections. It could be slightly more explicit about interpretation or edge cases, but for a read-only, single-parameter tool with 100% schema coverage, it is adequately complete.
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 100%, so the schema fully documents the parameters. The description adds minimal parameter-specific meaning beyond implying a single stock context; it does not describe as_of or ticker semantics in further detail. Baseline 3 is appropriate.
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 defines what the tool produces: a ~550-token 'character' of one stock composed of 16 percentile scores, four panels, a composite P3 score, curated peers, a character read, and a price line. It also distinguishes itself from siblings by emphasizing 'one stock' and 'vs the S&P 500 cohort' and explicitly noting 'not GICS.' This is a specific, informative statement of purpose.
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 cases: 'Use for "is this number good?" and quick company character.' This tells an agent when to invoke it, though it does not explicitly name sibling alternatives or state when not to use it. The context is clear enough for a single-stock read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where market stress sits right now: the dashboard's 8-indicator stance, each indicator's traffic-light band, the VIX 5-year percentile (the ONE input validated as predicting forward risk — blended composites tested worse), and the S2 stress-confirmation badge (SPY below its 40-week average AND VIX above its 80th percentile of the trailing year). Descriptive context, not a market call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and the description explicitly states 'Descriptive context, not a market call,' preventing the agent from over-interpreting the output. It also discloses the input-validation design (VIX percentile vs blended composites) and the S2 badge conditions. Moderate value over annotations, but not richly detailed.
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?
A dense, single-sentence description that front-loads the most important fact (current market stress), then enumerates the concrete outputs. Every clause adds information; no filler.
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 zero-parameter, read-only context tool with no output schema, the description covers what the tool is, what it contains, and importantly how to interpret it (not a market call). Nothing needed for correct invocation 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?
No parameters exist, so the description's job of defining parameters is vacuous. It adds context about what inputs were tested (VIX percentile) even though the tool itself takes none. Baseline 4 for zero params is appropriate here.
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?
States a specific verb-resource pair (market stress context) and defines exact indicators (8-indicator stance, traffic-light bands, VIX 5-year percentile, S2 badge). Distinguishes from sibling tools by naming market stress context, which no other sibling covers.
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?
Describes what the tool tells an agent (descriptive context, not a market call) and implicitly when it is relevant: whenever the agent needs current stress/regime context. It does not cite sibling alternatives or exclusions, but the scope is sufficiently clear for a zero-parameter, non-destructive context tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The stock's TRUE competitive cluster — LLM-curated from segment overlap (who it actually competes with for revenue), not GICS classification. Costco's peers are WMT/TGT/KR, not 'Discount Stores'. Each peer carries its P3 score. Honest empty list for monopolies/private-rival cases.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds meaningful behavior beyond that: results are LLM-curated from segment overlap, each peer carries a P3 score, and monopolies/private-rival cases yield an honest empty list. These are non-obvious edge-case and methodology disclosures.
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?
Three sentences carry dense, relevant information: methodology, a concrete example, output score details, and empty-list behavior. There is no filler; every sentence earns its place.
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 single-parameter read-only list tool with no output schema, the description covers the core output (peers with P3 scores) and the empty case. It does not specify the exact response envelope or peer object shape, but the expected usage is clear enough for an agent to act on.
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 coverage is 0% and the only parameter, ticker, has no schema description. The description implies the input is a stock ticker via 'The stock's' and the Costco example, but it never explicitly explains the expected format, ticker universe, or invalid-input behavior.
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 identifies the tool's output as the stock's competitive cluster ('TRUE competitive cluster') and distinguishes it from GICS classification with the Costco example. It lacks an explicit verb like 'returns' or 'lists', but the resource and method are 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?
The description gives clear context for when to use the tool: when you need the actual revenue-competitor set, not the GICS sector. It also discloses the empty-list behavior for monopolies and private-rival cases. It does not explicitly name sibling alternatives or exclusions, so it stops short of the highest score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen the S&P 500 + NDX universe on ANY of the 16 percentile scores, with minimum AND maximum bounds, optionally within one GICS sector, sorted by the validated P3 composite or by any single metric. Metric keys: marketBeat1Y/1M/1W/1D (price vs SPY), rankPersistence52W/26W/13W + trendPersistence (rank stability), businessBeat + revGrowthYoy + marginGrowthYoy + fcfGrowthYoy (business growth), accumDistFlow/30/5/2 (money flow 60/30/5/2-day). Examples: momentum — {sort_by:'marketBeat1M', filters:[{metric:'businessBeat', min:70}]}; fallen leaders — {filters:[{metric:'rankPersistence52W', min:80},{metric:'marketBeat1Y', max:40}]}. Legacy min_perform/min_persist/min_profit/min_pressure still work (the four headline scores).
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | max results (default 12) | |
| sector | No | GICS sector filter, e.g. 'Energy' | |
| filters | No | bounds on any metrics; entries AND together | |
| sort_by | No | 'p3' (default) or any metric key; descending | |
| min_profit | No | ||
| min_perform | No | ||
| min_persist | No | ||
| min_pressure | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral nuance: filters AND together, sorting can be by P3 or a single metric, and legacy parameters still work. This goes beyond the structured annotations without contradicting them.
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 dense but every section earns its place: core behavior, metric-key vocabulary, and two illustrative examples. It is front-loaded with the main purpose and avoids filler.
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 input semantics, metric vocabulary, legacy compatibility, and example payloads well enough for correct invocation. With no output schema, it could optionally describe the response shape, but that omission is minor for a screening tool whose parameters and selection logic are thoroughly specified.
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 only 50%, but the description compensates by enumerating all 16 metric keys, explaining sort behavior, giving full filter examples, and naming the four legacy parameters. This adds meaningful semantics beyond the bare schema, though n and sector remain primarily documented by the schema.
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 ('Screen'), a precise universe ('S&P 500 + NDX'), and a clear object ('ANY of the 16 percentile scores' with min/max bounds and sorting). The metric-key enumeration and examples make the tool's function unambiguous and distinguishable from sibling tools like compare or peers.
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 clearly states what universe and filtering dimensions the tool operates on, and gives two concrete usage examples. It does not explicitly name sibling tools or state when not to use them, but the context is strong enough that an agent can infer screening use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The statistical theme a stock actually trades with: clusters built from years of price co-movement (market-removed residuals → random-matrix cleaning → Ward linkage), not sector labels. Returns the cluster's name, description, cohesion, sector mix and up to 20 member tickers. Different question from peers (business competition) — this is who it MOVES with.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive. The description goes beyond annotations by explaining the statistical methodology (market-removed residuals, random-matrix cleaning, Ward linkage) and the output limits (up to 20 member tickers). No contradiction with annotations; it adds substantive behavioral context.
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 brief and front-loaded with the core definition. Three sentences each add value: the concept, the return contents, and the differentiation from peers. No filler or redundant information.
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?
Despite lacking an output schema, the description enumerates what the tool returns: cluster name, description, cohesion, sector mix, and up to 20 member tickers. For a read-only single-parameter tool, this is complete enough for an agent to understand what the call will produce and how to use it.
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?
The schema has one parameter, `ticker`, with zero description coverage. The description compensates by indicating the input is a stock identifier ('a stock actually trades with') and that the output corresponds to that ticker. Though it doesn't specify format or casing, the single self-explanatory parameter name plus the context is sufficient for correct invocation.
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: returns the statistical theme a stock trades with, based on price co-movement clusters. It specifies the output contents (name, description, cohesion, sector mix, member tickers) and explicitly contrasts with sector labels and the `peers` tool, making its 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?
The description gives an explicit alternative (`peers`), explains the difference (business competition vs. co-movement), and provides a when-not context ('not sector labels'). This is exactly the explicit routing guidance that helps an agent choose this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Analytical engine for US-listed equities: screens, rankings, and event studies in plain English.
Portfolio analytics + US-equity market research for AI clients. ChatGPT deep-research compat.
Signals, technicals, regime and news for 1,000+ US/TR symbols. Data only, not investment advice.
AI stock intelligence: prices, fundamentals, technicals, news, macro regime, and sector signals.
Add one secure layer between your agents and this server.
Each tool owns a distinct analytical niche: single-stock character, multi-ticker comparison, market regime, business peers, co-movement cluster, and universe screening. The only near-overlap (fingerprint's peer list vs peers) is explicitly resolved by describing peers as the deeper standalone lookup.
All names are lowercase and stylistically consistent, but there is no verb_noun pattern: compare and screen are verbs while market_regime, peers, and theme_cluster are noun phrases. The mixed grammar is readable but not a strongly predictable naming convention.
Six tools is tightly scoped for a stock-character research server; each tool covers a distinct user workflow and none feels redundant. The count is well within the ideal range and does not burden an agent with overlapping endpoints.
The set covers the full intended workflow: assess market context, inspect a single stock, compare tickers, identify true peers and co-movement groups, and screen the universe on every available metric. There are no obvious dead ends or missing operations for a read-only analytics domain.
