Screen 5,200 US stocks across 64 years of daily prices, quarterly financials, and 56 technical indicators. Describe what you're looking for in plain English and Shibui finds the companies that match.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 12 of 12 tools scored. Lowest: 3.8/5.
Each tool targets a distinct aspect of stock data workflow: schema discovery, query patterns, raw data access, Excel export, and eight specialized analysis workflows. The load_*_workflow tools are clearly differentiated by domain (earnings, filing, insider, etc.) with explicit usage criteria. There is no real overlap or confusion between tools.
Most tools follow a consistent verb_noun snake_case pattern (get_database_schema, get_query_patterns, load_*_workflow, export_to_excel). The only deviation is 'stock_data_query' which places the noun first rather than the verb, but it remains readable and fits the overall naming style. The consistent use of snake_case and descriptive prefixes makes the set predictable.
With 12 tools, the server is well-scoped for its purpose of comprehensive US stock data analysis. Each tool earns its place: two prerequisite/metadata tools, one query executor, one export utility, and eight distinct workflow loaders covering major analysis types. There is no bloat or redundancy.
The tool set provides a complete lifecycle for stock data analysis: schema discovery → query patterns → data query → specialized workflows (backtesting, comparison, earnings, filings, fundamentals, insider, screening, technical) and export. It covers all major query types described in the schema tool and leaves no obvious dead ends; agents can handle a wide range of financial questions.
export_to_excelExport to ExcelAExport query results to a branded Shibui Finance Excel spreadsheet.
Runs the same SQL query as stock_data_query but returns a downloadable Excel file instead of raw data. The spreadsheet includes branded headers, smart number formatting, and auto-fitted columns.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The SQL query to execute and export. Same query used with stock_data_query. | |
| title | Yes | Title for the spreadsheet header (e.g. "Mega-Cap Stock Comparison"). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations mark this tool as destructive (destructiveHint: true), but the description implies a read-only export by stating it runs the same SQL query as stock_data_query, which is typically a SELECT. This contradicts the annotation. The description does not mention any destructive side effects or file modifications, creating an inconsistency.
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 concise paragraphs: the first sentence states the core purpose, and the second elaborates on the relationship to sibling and output features. No fluff, front-loaded, and every sentence adds value.
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 effectively covers the tool's purpose, usage context, and differentiator. However, it fails to reconcile the destructive annotation with its implied read-only behavior, leaving a minor gap in behavioral completeness. The presence of an output schema reduces the need to describe return values, so the overall context is mostly sufficient.
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 covers both parameters with clear descriptions (query and title). The description adds minimal extra semantic value, mostly reinforcing that the query is the same as stock_data_query and that the title is for a branded header. With 100% schema coverage, a baseline of 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 states a specific verb (Export) and resource (query results to a branded Excel spreadsheet). It also explicitly distinguishes itself from its sibling stock_data_query by noting it returns a downloadable Excel file instead of raw data, providing clear differentiation.
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 frames when to use this tool: when you want the same SQL query as stock_data_query but in an Excel file ('instead of raw data'). This directly addresses the alternative tool and clarifies the decision boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_database_schemaLoad Database SchemaAREQUIRED for US stock/financial queries, authoritative source, call FIRST
Use this tool when the user asks about stock prices, revenue, earnings, earnings surprises (EPS estimates vs actuals), margins, P/E ratios, valuations, dividends, balance sheets, cash flow, technical indicators (RSI, MACD, SMA), stock screening, company comparisons, sector analysis, SEC filings, insider trading filings, or any analysis of US-exchange-listed companies.
Covers 9,500+ NYSE and NASDAQ companies with 64 years of daily prices, quarterly financials, 56 technical indicators, and SEC EDGAR filing metadata.
Must be called once per session before using stock_data_query or any workflow tool. After this tool returns, call get_query_patterns before writing any SQL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context about the data scope (9,500+ companies, 64 years, 56 indicators) and the requirement to call it first, which goes beyond what annotations convey. It doesn't elaborate on return structure, but an output schema exists.
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 front-loaded with a strong directive ('REQUIRED'), followed by a clear list of use cases, data coverage, and call order. Each sentence serves a distinct purpose, and the structure is logical and scannable.
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?
Given the tool has no parameters and includes an output schema, the description fully covers the context: when to use it, what data it encompasses, and the required invocation sequence. It leaves no critical gaps for an agent to select and call it correctly.
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 tool has zero parameters, so the description has no parameter burden. The baseline for 0 params is 4, and the description correctly avoids mentioning parameters that don't exist.
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 establishes that this tool loads the database schema for US stock/financial data by labeling it 'REQUIRED' and 'authoritative source'. It distinguishes itself from siblings by being explicitly the first tool to call before any other query tool.
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 provides an extensive list of user intents that should trigger this tool (stock prices, earnings, technical indicators, etc.) and explicitly states it must be called once per session before stock_data_query or any workflow tool. It also instructs to call get_query_patterns afterward, giving clear ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_query_patternsLoad Query PatternsAREQUIRED before stock_data_query, 23 SQL patterns prevent timeouts/wrong results
Must be called once per session immediately after get_database_schema. Contains query patterns for time-series selection, return calculations, screening joins, window functions, backtesting, and performance optimization. Time-series queries will timeout or return wrong results without these patterns. After this tool returns, call stock_data_query to execute SQL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent behavior; description adds critical prerequisite context and consequences (timeouts/wrong results) without contradicting annotations.
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?
Description is front-loaded with the critical requirement and remains compact. Some redundancy exists ('REQUIRED', 'Must be called', 'without these patterns'), but every sentence contributes value.
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?
Given the output schema and annotations, the description fully covers purpose, prerequisites, sequencing, and failure consequences. It is complete for an agent to invoke correctly.
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?
Tool has no parameters and schema coverage is 100%, so the description need not explain parameters. Baseline 4 applies.
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?
Description explicitly states the tool loads 23 SQL query patterns, identifies it as REQUIRED before stock_data_query, and enumerates pattern categories. This clearly distinguishes it from sibling workflow-loading tools.
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?
Provides explicit sequencing: must be called once per session, immediately after get_database_schema, and before stock_data_query. Does not mention when not to use or alternatives, but the context is strong and specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_backtesting_workflowBacktesting Analysis WorkflowABacktesting and simulation guardrails: survivorship, drawdown, Sharpe, day-of-week. REQUIRES get_database_schema then get_query_patterns to be called first (in that order). Call BEFORE writing SQL when the user asks to backtest, simulate, validate a strategy, test "what happens after X", compare forward returns, measure win rates or hit rates, compute Sharpe, drawdown, profit factor, rotation strategies, basket returns, or any hypothetical return over past data. Contains hard rules for survivorship bias, outlier handling, sampling design, day-of-week filters, and risk-adjusted metrics (Sharpe, Sortino, drawdown). Can be combined with other workflow tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses the tool's contents (hard rules for bias, outliers, sampling, day-of-week, risk metrics), the required call order, and that it should be invoked before writing SQL. This adds meaningful behavioral context without contradicting any annotation.
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 well-organized, starting with a succinct summary, followed by a required-order callout, then a comprehensive use-case list. Every sentence provides actionable value, though the use-case enumeration is slightly long and could be condensed.
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?
Given the zero-parameter schema, an output schema, and informative annotations, the description fully covers the necessary context: when to invoke, prerequisites, contents, and combinability. No critical information is missing for selecting and using this tool.
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 tool has zero parameters, and the schema coverage is 100%, so the baseline is 4. The description appropriately adds no parameter-specific details since none exist, and it doesn't need to compensate for any schema gaps.
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 the tool's function as 'Backtesting and simulation guardrails' and lists specific metrics and biases it covers (survivorship, drawdown, Sharpe, day-of-week). This distinguishes it from sibling workflow loaders by domain and makes the purpose unmistakable.
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 trigger conditions ('when the user asks to backtest, simulate, validate...') and mandatory prerequisite ordering ('REQUIRES get_database_schema then get_query_patterns to be called first'). It also notes that the tool can be combined with other workflows, providing comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_comparison_workflowPeer Comparison WorkflowALoad comparison workflow for X vs Y, peer analysis, relative valuation. REQUIRES get_database_schema then get_query_patterns to be called first (in that order). Call BEFORE writing SQL when the user asks to compare companies, "X vs Y", "how does X compare to Y", peer benchmarking, sector peers, side-by-side metrics, or relative valuation. Can be combined with other workflow tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by disclosing the required calling order ('REQUIRES get_database_schema then get_query_patterns to be called first') and the timing relative to SQL writing, which are not in annotations. It does not contradict the annotations.
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 compact and front-loaded with the core purpose, followed by prerequisites, usage triggers, and combination note. Every sentence provides necessary information without redundancy or fluff. It is appropriately concise for the complexity.
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?
Given there are no parameters and an output schema exists, the description covers all necessary operational context: what the workflow is for, when to call it, prerequisites, and that it can be combined with other workflows. The output schema handles return-value details, so no additional description is needed.
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 tool has zero parameters, so the baseline is 4 per rubric. The description explains the workflow concept and usage, and there are no parameter semantics to add. It adequately compensates with context about what the workflow is for.
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 the tool loads a 'comparison workflow' and provides specific use cases: 'X vs Y, peer analysis, relative valuation'. It distinguishes this workflow from sibling tools like load_earnings_workflow or load_technical_workflow by focusing on comparison scenarios.
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?
It explicitly lists when to use ('Call BEFORE writing SQL when the user asks to compare companies, "X vs Y", "how does X compare to Y", peer benchmarking, sector peers, side-by-side metrics, or relative valuation') and also states required prerequisites: 'get_database_schema then get_query_patterns to be called first (in that order)'. It adds that it can be combined with other workflow tools, giving complete usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_earnings_workflowEarnings Analysis WorkflowALoad earnings workflow for EPS surprises, beat/miss, estimates, revenue. REQUIRES get_database_schema then get_query_patterns to be called first (in that order). Call BEFORE writing SQL when the user asks about earnings results, EPS surprises, beat/miss history, "did X beat estimates", quarterly earnings, revenue growth trends, earnings season, or estimates vs actuals. Can be combined with other workflow tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description doesn't need to repeat that. It adds valuable behavioral context about prerequisite calls and ordering, which goes beyond the annotations. However, it doesn't describe internal behavior of the workflow beyond loading.
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 three sentences, tightly packed with use cases, prerequisites, and combination notes. It is front-loaded with the core purpose and contains no redundant 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 parameterless workflow loader with an output schema, the description covers usage timing, prerequisites, and scope of queries. It fully equips an agent to decide when to call this tool, and the existence of an output schema handles return value expectations.
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 tool has zero parameters and schema description coverage is 100%, so the baseline for 0 params is 4. The description doesn't need to explain parameters, but it still provides useful context about the workflow's content.
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 'Load earnings workflow' with specific domain terms (EPS surprises, beat/miss, estimates, revenue). It distinguishes itself from sibling workflow tools by focusing on earnings analysis, making the purpose unmistakable.
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 the tool ('before writing SQL' and lists trigger phrases like 'did X beat estimates' and 'earnings season'). It also names required prerequisites in order: get_database_schema then get_query_patterns. This is clear, actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_filing_workflowSEC Filing Analysis WorkflowALoad filing workflow for SEC/EDGAR metadata, 8-K events, 10-K/10-Q reports. REQUIRES get_database_schema then get_query_patterns to be called first (in that order). Call BEFORE writing SQL whenever the user asks about filing dates, filing activity, "who filed", "filed a form", filing frequency, SEC filings, EDGAR, 8-K events, 10-K/10-Q reports, proxy statements, or any query involving the sec_filings table (metadata - when/what type, not transaction detail). For insider transaction detail (shares, prices, cluster buying), use load_insider_workflow instead. Can be combined with other workflow tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds critical behavioral context: the prerequisite call order, that it is scoped to metadata not transaction detail, and that it can be combined with other workflows. This goes well beyond the annotations.
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 front-loaded with purpose and each sentence adds distinct value. It is longer than typical, but the trigger list and dependency instructions justify the length. Slightly more concise phrasing could improve it, but it remains well-structured and efficient.
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?
Given the tool has no parameters, strong annotations, and an output schema, the description is complete. It covers purpose, prerequisites, usage timing, exclusions, and alternatives, leaving no significant gaps for an agent to select and invoke it correctly.
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 input schema has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter-specific semantics but provides extensive context on what queries the tool applies to, which serves as implicit parameter guidance.
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 states a specific verb 'Load' with a clear resource ('filing workflow for SEC/EDGAR metadata, 8-K events, 10-K/10-Q reports') and lists concrete trigger topics. It distinguishes itself from sibling tools by explicitly contrasting with load_insider_workflow for transaction detail.
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?
Provides explicit when-to-use guidance with a long list of triggering queries ('filing dates', 'who filed', 'SEC filings', etc.), states required prerequisite calls in order ('REQUIRES get_database_schema then get_query_patterns'), and names the alternative for insider details ('use load_insider_workflow instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_fundamental_workflowFundamental Analysis WorkflowALoad fundamental workflow for valuation, cash flow, margins, balance sheet. REQUIRES get_database_schema then get_query_patterns to be called first (in that order). Call BEFORE writing SQL when the user asks about company valuation, "is X a good buy", financial health, debt levels, profitability ratios, revenue trends, earnings quality, or any deep-dive company analysis. Can be combined with other workflow tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: it specifies the prerequisite ordering and clarifies that this is a setup/loading step before writing SQL. No contradictions with annotations. This enriched context earns a top score.
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?
Every sentence serves a purpose: purpose, prerequisites, usage triggers, and combinability are all packed into three sentences without redundancy. The most critical info (purpose, ordering) is front-loaded. Very concise and well structured.
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 having no parameters and no detailed output schema, the description covers prerequisites, intended usage scenarios, and relationship to other tools. It is fully complete for an AI agent to decide when and how to invoke it correctly, especially with the provided annotations.
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 tool has zero parameters, so per the rubric baseline is 4. The description adds no parameter information, which is acceptable because there are no parameters to describe. It indirectly clarifies that no arguments are needed to invoke this workflow.
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 the tool loads a fundamental analysis workflow, listing specific components (valuation, cash flow, margins, balance sheet) and explicitly distinguishes it from sibling workflow tools by naming both the resource and the subject matter. The verb 'load' is specific to this tool.
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?
Provides explicit when-to-use guidance with concrete triggers ('when the user asks about company valuation, is X a good buy, financial health...'), a required call order ('REQUIRES get_database_schema then get_query_patterns to be called first'), and even notes combinability with other tools. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_insider_workflowInsider Transaction WorkflowALoad insider workflow for Form 3/4/5, insider buy/sell, cluster buy, 13D/G. REQUIRES get_database_schema then get_query_patterns to be called first (in that order). Call BEFORE writing SQL when the user asks about insider transactions, insider buying/selling, Form 3 initial holdings, Form 4/5 transactions, cluster buying, executive purchases, officer sales, 10b5-1 plans, activist stakes, 13D/G filings, beneficial ownership, "who is buying/selling", or "track this insider across companies". Can be combined with other workflow tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable context about the required call order and that it can be combined with other workflows, which is beyond the structured fields. No contradictions found, though it could mention the effect of loading the workflow.
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 tightly packed sentences: the first identifies purpose and scope, the second details prerequisites and trigger phrases. No filler or repetition; all sentences earn their place and the most critical info is front-loaded.
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 workflow loader with no parameters, an output schema, and robust annotations, the description covers the essential prerequisites (call order), trigger conditions, and combinability. The user asking about insider transactions has enough to invoke it correctly.
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 tool accepts zero parameters, and the schema confirms no properties are needed. With 0 params, the baseline is 4, and the description correctly provides no parameter details—so there is nothing here that detracts from semantics.
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 ('Load') and resource ('insider workflow') and lists covered topics (Form 3/4/5, insider buy/sell, cluster buy, 13D/G). This clearly distinguishes it from sibling workflow loader tools like load_earnings_workflow or load_filing_workflow.
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?
Explicitly states required prerequisite calls (get_database_schema then get_query_patterns) and gives a comprehensive list of when to invoke it—before writing SQL and for specific insider-related user intents. It also notes combinability with other workflow tools, covering when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_screening_workflowStock Screening WorkflowALoad screening workflow to find, filter, scan, rank stocks, top N by.... REQUIRES get_database_schema then get_query_patterns to be called first (in that order). Call BEFORE writing SQL when the user asks to find, screen, scan, rank, or filter stocks — "find stocks that...", "top 10 by...", "best dividend stocks", value/growth screens, sector ranking, or any multi-factor selection. Can be combined with other workflow tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by stating the required call order (get_database_schema before get_query_patterns) and the timing (before writing SQL). This explains how the tool operates within a larger workflow, which is valuable for an AI agent. The annotations already indicate this is read-only and idempotent, and the description complements these 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 two sentences and front-loaded. The first sentence immediately states the purpose and examples, and the second covers prerequisites and usage timing. Every sentence adds meaningful guidance with no filler or repetition of the schema or annotations.
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?
Given the tool's low complexity (0 parameters, no nested objects) and the existence of an output schema, the description fully covers the necessary context. It explains prerequisites, timing, and typical user intents, and there is no missing guidance for an agent to invoke the tool correctly.
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?
There are zero parameters, so the input schema is trivially complete. The description doesn't need to explain parameters, and the baseline for 0-parameter tools is 4. The description could theoretically mention what the workflow loads, but it already does, so no additional parameter semantics are necessary.
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 the tool's purpose with a specific verb ('Load') and resource ('screening workflow'), and elaborates on its use for finding, filtering, scanning, and ranking stocks. It also distinguishes this from sibling workflow tools by providing concrete query examples like 'find stocks that...' and 'top 10 by...'.
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 when-to-use guidance: 'Call BEFORE writing SQL when the user asks to find, screen, scan, rank, or filter stocks'. It also specifies a mandatory prerequisite sequence ('REQUIRES get_database_schema then get_query_patterns to be called first'). While it doesn't explicitly name when-not-to-use alternatives, the examples and workflow context make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_technical_workflowTechnical Analysis WorkflowALoad technical workflow for RSI, MACD, SMA, Bollinger Bands, entry/exit. REQUIRES get_database_schema then get_query_patterns to be called first (in that order). Call BEFORE writing SQL when the user asks about RSI, MACD, moving averages, Bollinger Bands, support/resistance, overbought/oversold, momentum, trend, chart patterns, golden cross, entry/exit signals, or "is X oversold/overbought". Can be combined with other workflow tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds behavioral context about the prerequisite call order and invocation timing before SQL writing, which goes beyond annotations. No contradictions.
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 information-dense and front-loaded with the core purpose, followed by prerequisites and triggers. Minor redundancy ('entry/exit' appears twice) prevents a perfect score, but 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?
With no parameters, strong annotations, and an output schema present, the description covers all necessary aspects: purpose, prerequisites, trigger conditions, and combinability. It is complete for this tool's role.
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 tool has zero parameters, so schema coverage is complete. The description doesn't need to explain parameters, and the baseline score of 4 applies.
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 directly states it loads a 'technical workflow' for specific indicators (RSI, MACD, SMA, Bollinger Bands, entry/exit), making the verb and resource clear. It distinguishes from sibling workflow tools like fundamental or earnings by listing technical analysis indicators and signal types.
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?
It explicitly gives ordering prerequisites ('REQUIRES get_database_schema then get_query_patterns to be called first') and when to invoke ('Call BEFORE writing SQL when the user asks about...') with a comprehensive trigger list. It also notes combinability with other workflow tools, effectively covering when and how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stock_data_queryQuery Stock DataAStock prices, earnings, revenue, P/E, dividends, filings, screener, comparisons
Run a SQL query against 64 years of US stock market data.
REQUIRES calling get_database_schema then get_query_patterns first (in that order).
This tool has no schema or query patterns built in. Call get_database_schema once, then get_query_patterns once, then use this tool. Queries will timeout or return wrong results without the patterns from get_query_patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Read-only SQL query to execute. Requires shibui. table prefix and a LIMIT clause. | |
| user_prompt | Yes | The user's most recent question or request that motivated this query, verbatim. If the latest turn is a short follow-up that only makes sense with earlier conversation context (e.g., 'now show me MSFT'), expand it into a self-contained one-sentence version. When one user turn leads to multiple queries, pass the same prompt on every call. Required for observability — never leave empty. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint; the description adds crucial behavioral context: the tool has no built-in schema or query patterns, and depends on prior calls to get_database_schema and get_query_patterns. It also discloses failure modes (timeouts, wrong results). This goes beyond the annotations and is highly relevant for correct usage.
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 concise, front-loaded with the data scope, and every sentence earns its place: the data list, the core action, the prerequisite order, and the consequence warning. No redundancy or 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?
Given the tool's complexity (SQL query with hidden dependencies), the description fully covers the prerequisite calls and failure modes. The output schema exists, so return values do not need describing. The description is sufficient for an agent to invoke the tool correctly in context.
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 input schema already provides 100% coverage with detailed descriptions for both parameters (query requires shibui. prefix and LIMIT; user_prompt requires verbatim text and observability guidance). The tool description adds no additional parameter-level semantics, so the baseline score of 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 states the tool runs SQL queries against 64 years of US stock market data, and lists the domains covered (prices, earnings, revenue, P/E, dividends, filings, screener, comparisons). This clearly distinguishes it from sibling tools like get_database_schema and get_query_patterns, which are prerequisites, and load_* workflows.
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 the required calling order: 'REQUIRES calling get_database_schema then get_query_patterns first (in that order)'. It also warns that queries will timeout or return wrong results without the patterns, giving clear guidance on when to use this tool and what happens if prerequisites are ignored.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
