fintools-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.1
Disambiguation5/5
Each tool has a distinct purpose: quotes, technical analysis, options, position sizing, screening, meta functions. No two tools appear to do the same thing, and descriptions clearly differentiate them.
Naming Consistency4/5
Most tools follow a verb_noun pattern with snake_case (e.g., get_stock_quote, calculate_position_size). Minor inconsistency: 'about_fintools' and 'winner_similarity_scan' break the pattern slightly, but overall the naming is predictable and clear.
Tool Count5/5
With 17 tools, the server covers a broad financial toolkit without being overwhelming. Each tool appears necessary for the domain of financial analysis and trading, and the count feels well-scoped.
Completeness4/5
The tool set covers core financial workflows: quotes, technical indicators, options, trades, scanning, and position sizing. Minor gaps exist (e.g., no historical price data, no news), but the provided tools form a coherent and functional surface for the stated purpose.
Average 2.7/5 across 17 of 17 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on July 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, has rate limits, or requires special permissions. The mention of 'Paid Fintools MCP required' indicates a prerequisite but not behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but uses jargon ('day-context gates, flags') without explanation, making it cryptic rather than concise. It does not efficiently convey essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no schema descriptions, the description is grossly incomplete. It does not explain the output, return format, or how the parameters affect the snapshot. An output schema exists but is not described.
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 add any meaning to parameters 'ticker' or 'period'. It fails to clarify their purpose or acceptable values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'day-context gates, flags, and fresh_add_status' which hint at filtering but do not clearly state the tool's purpose. The name suggests a market snapshot, but the description is vague and fails to articulate the specific function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling tools like get_stock_quote or compare_tickers. The description does not differentiate the tool's use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the paid requirement, which is good, but fails to disclose whether the tool is read-only, destructive, or what happens during execution. With no annotations, the burden is on the description, and it falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is too terse to convey necessary information. It sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and schema coverage is 0%, the description is woefully incomplete. It does not explain input semantics, output, or usage context.
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?
The description adds no meaning to any of the 5 parameters, and schema coverage is 0%. Parameters like ticker, expiration, and liquidity filters are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'options-chain context and liquidity filters' is almost a tautology with the tool name 'analyze_options_chain', lacking a clear verb or specific action. It does not distinguish from siblings like get_option_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_option_quote or analyze_trades. The description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a sparse description, behavioral traits are almost entirely undisclosed. The description does not indicate whether the tool is read-only, destructive, or has other constraints, leaving the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks necessary detail. It is too brief to be useful, sacrificing completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and an output schema, the description is severely incomplete. It does not explain how parameters affect results, what the output contains, or the kind of breakout detection algorithm used.
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?
The input schema has 0% description coverage, and the tool's description adds no explanation for any of the 5 parameters. Parameter meanings like max_rsi, min_rsi, max_results, exclude_symbols, and min_trend_score remain unclear from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'breakout discovery and candidate surfacing' which gives a general sense of purpose, but it lacks specificity about what kind of breakouts and does not distinguish the tool from similar siblings like get_trend_score or screen_stocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description only states that a paid Fintools MCP is required, but does not indicate when to use this tool versus alternatives or any prerequisites beyond payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Paid Fintools MCP required', which is a behavioral prerequisite, but does not disclose whether the tool is read-only, has side effects, requires authentication beyond the paid plan, or has rate limits. For a calculation tool, a readOnly hint would be valuable but is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, it sacrifices completeness and clarity. It is not front-loaded with the most critical information; instead, it leads with the paid requirement, which may not be the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters (one required), a known output schema (though not detailed here), and no annotations, the description is severely incomplete. It fails to explain the tool's purpose adequately, parameter meanings, return values, or how it fits with sibling tools. The agent lacks sufficient information to use it correctly.
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%, meaning the input schema provides no descriptions for the two parameters. The description does not mention any parameters, leaving the agent without any explanation of 'pnls' (array of numbers) or 'starting_equity' (number with default). The agent cannot infer their meaning or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'trade-stat calculations and review context', which gives a general sense of the tool's function but lacks specificity. The verb 'analyze' is implied from the name, but the description does not explicitly define the verb or resource, making it somewhat vague. It fails to differentiate from siblings like 'analyze_options_chain' or 'get_market_snapshot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. The description does not mention contexts, prerequisites beyond the paid requirement, or exclusions. The agent is left to guess the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions 'Paid Fintools MCP required', hinting at a subscription requirement, but does not disclose other behavioral aspects such as required permissions, side effects, or what happens with invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but fails to convey essential information. For a tool with 6 parameters and no schema descriptions, the description is under-specified, lacking necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, 4 required, no schema descriptions) and the presence of an output schema (not detailed), the description is incomplete. It does not explain what the output represents or how to interpret results.
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 tool description does not elaborate on any parameter (e.g., what 'risk_pct' represents, defaults for optional parameters). The description adds no semantic value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'risk-based position sizing', which indicates the tool calculates position size based on risk parameters. However, it lacks specificity on what exactly is computed (e.g., number of shares, dollar amount) and does not differentiate from the sibling tool 'calculate_atr_position' that likely calculates position size using ATR.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'calculate_atr_position'. No prerequisites or context for appropriate usage are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention authentication, rate limits, data freshness, or what 'levels and structure' entail in terms of output format. For a paid tool, the lack of transparency about data source or updates is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it mixes a prerequisite ('Paid Fintools MCP required') with the functional purpose, which reduces clarity. The sentence structure is adequate but not optimally front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain what the output contains (e.g., levels, zones, strengths). Given three parameters and an output schema, the description should provide context on how to interpret results or set parameters. It falls short of being complete.
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%, meaning none of the three parameters (ticker, lookback, max_levels) are explained in the schema. The description does not compensate; it fails to describe any parameter, such as what lookback controls or how max_levels affects results. This makes it impossible for an agent to understand parameter usage without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'support/resistance levels and structure,' which indicates the tool returns support and resistance levels. However, it is somewhat vague and does not specify what 'structure' refers to. It is clear enough but lacks precision compared to a more explicit statement like 'Calculate and return support and resistance price levels and market structure zones for a given ticker.' The mention of 'Paid Fintools MCP required' is a prerequisite, not part of the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only a condition ('Paid Fintools MCP required') but gives no guidance on when to use this tool versus sibling tools like get_technical_indicators or screen_stocks. It does not specify scenarios where support/resistance analysis is appropriate or mention any prerequisites beyond payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It only states 'ATR-based position sizing' and payment requirement, but does not disclose behavioral traits such as whether it is a read-only calculation, required permissions, or what happens with the result. Output schema exists but isn't referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short (8 words), which is concise but at the cost of missing crucial information. It earns a middle score because brevity is valued but not at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no schema descriptions, and no annotations, the description is grossly inadequate. It does not explain the purpose of parameters, when to adjust them, or how the output is structured (though output schema exists, the description doesn't guide interpretation).
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%, with 7 parameters including 'stop_atr_mult' and 'target_atr_mult' that are not self-explanatory. The description adds no parameter explanations, leaving the agent to guess their meaning.
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?
Clearly states 'ATR-based position sizing', identifying the verb (calculate) and resource (position size based on ATR). However, it does not distinguish from sibling 'calculate_position_size', which may be a simpler version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only mentions 'Paid Fintools MCP required', which is a prerequisite but not guidance on when to use versus alternatives. No explicit context for when to choose this tool over others like 'calculate_position_size'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only says 'side-by-side technical comparison' and mentions paid requirement, but fails to disclose behavioral traits such as data source, API calls, whether it modifies state, or output format. With 0% schema coverage, the description is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (8 words), which is concise, but it sacrifices substance. Important information is missing. The sentence is front-loaded with 'Paid Fintools MCP required' which is a prerequisite, not the core purpose. Better structure would place the action first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and simple parameters, the description is incomplete for a tool with 17 siblings. It lacks context on when to choose this over similar tools, what technical indicators are compared, and how results are presented. The paid requirement adds context but leaves many gaps.
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%, leaving parameters unexplained. The description does not clarify 'period' (allowed values, format) or 'tickers' (number limits, format). The default '3mo' is in schema but its meaning is not elaborated. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'side-by-side technical comparison', which implies comparing multiple tickers technically. However, it lacks a specific verb and does not elaborate on the type of technical analysis (e.g., indicators, charts). It distinguishes from single-ticker tools like get_technical_indicators but is vague compared to potential multi-ticker alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like get_technical_indicators or screen_stocks. The description only mentions a paid requirement, which is a prerequisite but not usage context. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description adds only the 'Paid Fintools MCP required' note. No disclosure of side effects, authorization needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, but awkwardly structured with a colon. Could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values need not be explained, but parameter semantics are insufficient. The description lacks completeness for an AI agent to use it correctly.
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%, but the description fails to explain entry_price or option_symbol beyond what the field names imply. entry_price is ambiguous.
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 mentions 'option quote, spread, IV, and entry P&L context', making it clear this tool retrieves option-related data. It distinguishes from siblings like get_stock_quote and analyze_options_chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like analyze_options_chain. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses the paid requirement and lists the indicators returned, which adds transparency. However, no information about rate limits, authentication, or side effects is provided.
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?
The description is a single sentence with no unnecessary words. It front-loads the important paid requirement and lists the indicators efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits explanation of parameters and usage context. With three parameters and no descriptions, the agent lacks guidance on how to use the tool effectively.
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%, meaning no parameter descriptions in the schema. The description does not explain the three parameters (ticker, period, interval) at all, failing to add any meaning beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists the specific technical indicators (RSI, MACD, ATR, EMAs, Fibonacci) that the tool provides, which clarifies its purpose beyond the tool name. However, it lacks a clear verb-resource structure like 'Get technical indicators for a ticker'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Paid Fintools MCP required', which is a usage constraint but offers no guidance on when to use this tool versus sibling tools like get_trend_score or get_support_resistance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only mentions the paid requirement. It does not disclose behavioral traits such as rate limits, data sources, or what happens if the required MCP is not present.
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?
The description is a single sentence, which is concise. However, it uses jargon ('winner-similarity') and front-loads the paid requirement, which could be misleading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0% schema coverage and an output schema present, the description is too brief. It does not explain the input format for 'tickers', the meaning of 'triage', or how results are ordered.
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 provides no explanation of the two parameters ('tickers', 'max_results'). Only the schema field names and types are available, which is insufficient.
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?
Description states the tool performs winner-similarity candidate ranking and triage. 'Winner-similarity' is a specific concept, but it's not fully clear how it differentiates from siblings like 'compare_tickers' or 'get_trend_score'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The only usage note is 'Paid Fintools MCP required', which is a prerequisite, not a usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only mentions the screening criteria, not whether the tool is read-only, requires authentication, or has rate limits. This is insufficient for an agent to understand operational implications.
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?
The description is a single sentence with no superfluous text. However, the requirement note is embedded in the same sentence, which could be separated for clarity. Overall, it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no schema descriptions, the description is too brief to be considered complete. It does not explain the output (though an output schema exists) or how the screening logic works. Missing context for a tool of this complexity.
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%, so the description must clarify parameter meanings. It mentions trend, RSI, EMAs, and volume, which map to some parameters (rsi_min/max, trend_min/max, above_50/200ema, min_relative_volume), but ignores tickers, universe, and max_results. Many parameters remain unexplained.
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 states it screens stocks by trend, RSI, EMAs, and volume, clearly indicating the action and resource. It distinguishes from siblings like get_stock_quote or get_technical_indicators, though it does not explicitly contrast with find_breakouts or other screening tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The only added information is a note about requiring a paid Fintools MCP, but no context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only adds the paid requirement. It does not disclose whether the tool is read-only, modifies any state, or other behavioral aspects. The lack of detail about side effects or data volatility is a significant gap.
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?
The description is very concise (two short sentences) with no fluff. Every part serves a purpose: stating the requirement (paid) and the core output (graduated trend score with breakdowns). It could benefit from slight expansion but remains efficient.
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?
Given that the tool has an output schema (though not shown), the description adequately covers the basic purpose and output type. However, it misses behavioral guidance and usage context, making it barely sufficient for a simple single-parameter tool.
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% for the single parameter 'ticker', and the description does not elaborate on its meaning or expected format. While it is somewhat implied that ticker is a stock symbol, the description should explicitly clarify param semantics since the schema offers no description.
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 explicitly states 'graduated trend score with component breakdowns', clearly indicating the tool returns a trend score with details. The verb 'get' in the name combined with the description makes the purpose clear. It is distinct from sibling tools that focus on options, trades, or screening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions a prerequisite ('Paid Fintools MCP required') but provides no guidance on when to use this tool versus alternatives or when not to use it. There is no context for selecting this tool over siblings like 'get_technical_indicators' or 'get_market_snapshot'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as data freshness, authentication requirements, or any side effects. The term 'basic' is vague and does not convey limitations or caveats.
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 extremely concise, using two short sentences to convey purpose and parameter usage. No wasted words, and the key information is front-loaded.
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 tool has a simple one-parameter interface and an output schema, so the description covers the basics. However, it fails to distinguish from sibling tools or specify whether the quote is real-time or delayed, leaving some gaps for an AI agent.
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?
Despite 0% schema description coverage, the description provides example tickers (AAPL, SPY, TSLA) and clarifies 'stock symbol', adding meaning beyond the schema's bare type definition.
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 clearly states 'Get a basic stock quote', which is a specific verb and resource. However, it does not distinguish from sibling tools like get_option_quote or get_market_snapshot, leaving ambiguity about what 'basic' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It only mentions the connector scope but lacks context on prerequisites, data source, or comparison with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It implies a read-only operation (Show), which is correct. However, it does not disclose potential behavioral traits like auth requirements or rate limits, but given the tool's simplicity (no parameters, read-only), a moderate score is appropriate.
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 a single, concise sentence that immediately conveys the purpose. It is front-loaded and contains no extraneous information.
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?
Given the tool has zero parameters and an output schema exists, the description sufficiently explains what it does. No additional information is necessary for an agent to understand its role.
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?
There are no parameters, so the description does not need to add parameter semantics. The schema coverage is 100% (empty schema), so baseline 4 applies.
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?
The description uses a specific verb 'Show' and clearly identifies the resource as 'public connector cache status and provider request counters.' It distinguishes itself from siblings like get_market_snapshot or get_stock_quote, which cover different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context or exclusion criteria, leaving the agent to infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it confirms connection and response, but does not elaborate on return format or failure behavior. Adequate for a simple tool.
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?
Single, clear sentence with no extraneous information. Efficiently conveys purpose.
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?
For a simple connectivity check with zero parameters and an output schema, the description is sufficiently complete. No additional context needed.
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?
No parameters; schema coverage is 100%. Baseline 4 per rubric for zero parameters.
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?
Clearly states the verb 'confirm' and specific resource 'public Fintools connector connected and responding'. Distinguishes from sibling tools which focus on data analysis and trading functions.
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?
Implied usage as a health check, but no explicit when-to-use or alternative tools recommended. Siblings provide no direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It clearly states it 'explains' but does not detail internal behavior (e.g., network calls). However, for a simple informational tool this is sufficient.
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 sentences, front-loaded with purpose, then usage scenarios. No wasted words.
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?
Tool is simple with no parameters and an output schema (not shown). The description fully covers what it does and when to use, leaving no gaps given the context.
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?
No parameters. Baseline 4 as per rules since 0 parameters. No additional param info needed.
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?
The description clearly states it explains the public connector and paid Fintools MCP package, with a specific verb 'Explain' and resource. This distinguishes it from sibling analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use: when a user asks about capabilities, package status, upgrade, or unavailability of a workflow. No alternatives needed as it's unique.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fintools-mcp MCP server](https://glama.ai/mcp/servers/slimbiggins007/fintools-mcp/badges/card.svg)](https://glama.ai/mcp/servers/slimbiggins007/fintools-mcp)

Score Badge

Copy to your README.md:

[![fintools-mcp MCP server](https://glama.ai/mcp/servers/slimbiggins007/fintools-mcp/badges/score.svg)](https://glama.ai/mcp/servers/slimbiggins007/fintools-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/slimbiggins007/fintools-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server