stoquant-mcp

Server Quality Checklist

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

Latest release: v0.5.3
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., quote vs. extended quote vs. sparklines), but the social suite is crowded: stoquant_get_social_trend, stoquant_get_social_sentiment, stoquant_get_trending_social, and stoquant_get_social_momentum overlap in domain and could be confused without careful reading of descriptions. Similarly, stoquant_get_catalysts and stoquant_get_catalyst_watch are different (per-ticker vs. market-wide) but the names are close.
Naming Consistency4/5
The naming convention is overwhelmingly consistent: a fixed 'stoquant_' prefix followed by a verb (get, run, list, explain) and a noun or noun phrase with underscores (e.g., stoquant_get_quote, stoquant_run_screener, stoquant_list_prebuilt_screens). Minor deviations include version suffixes (stoquant_get_signals_v2) and the use of 'explain' instead of 'get', but these are semantically appropriate and do not break the overall pattern.
Tool Count2/5
With 49 tools, the server is heavily overloaded. While the breadth of stock research, macro data, social sentiment, and alternative data can justify many endpoints, 49 exceeds the threshold where an agent can easily navigate or remember the full surface. The count feels like the server tries to expose every feature as a separate tool rather than consolidating related functionality (e.g., multiple social tools could be merged).
Completeness5/5
The tool set is remarkably comprehensive for a stock analysis/quant research domain. It covers quotes, technicals, fundamentals, ML predictions, analyst estimates/ratings, insider trading, institutional holders, SEC filings, social sentiment, macro indicators, catalysts, alternative data, and screening. There are no obvious dead ends—each workflow has supporting tools, and the availability of both breadth (dashboard, news_events) and depth (explain_ml_prediction, evidence) makes the surface feel complete.
Average 4.3/5 across 49 of 49 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds the return structure (data + summary) and mentions a bullish signal for cluster buying. It doesn't address pagination, exact field names, or time ranges, but the annotations lower the burden.
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 two sentences, front-loaded with the main function and output summary, followed by a useful interpretation note. Every sentence adds value with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, output structure, and a usage signal, which is adequate for a simple read-only tool. However, it doesn't mention what 'recent' means (time range) or distinguish from overlapping insider tools, leaving a small but notable gap.
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?
With 0% schema description coverage, the description should compensate by explaining the 'ticker' parameter. It merely says 'for a ticker' and doesn't add details about format, examples, or possible values. The parameter name is self-explanatory, but the description contributes little beyond the schema.
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 the tool returns recent Form 4 transactions and a summary with net buy/sell counts and dollar value, which is a specific verb+resource. It doesn't explicitly differentiate from sibling tools like stoquant_get_insider_cluster or stoquant_get_big_insider_buys, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage directive: 'Use to check whether insiders are accumulating or distributing.' This gives contextual guidance without explicit exclusions or references to alternatives, but the context is clear enough for an agent to decide when to invoke this tool.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds valuable context: the output is nested under 'data', and inactive sources are null rather than zero. This goes beyond the annotations by explaining the data shape and null-handling behavior, though it doesn't mention rate limits or error conditions.
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 long but well-structured: it front-loads the core value proposition, then uses a semicolon-separated list to enumerate all 15 sources efficiently. Every sentence adds information, and the closing sentence reinforces its strategic value, though it borders on promotional tone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 aggregated sources) and the absence of an output schema, the description does a solid job of explaining what to expect: the data location, source categories, and null behavior. It could be improved by mentioning the response format or potential error cases, but it is largely complete for an average agent.
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?
With only one parameter 'ticker' and 0% schema description coverage, the description must compensate by adding meaning. It mentions 'for a ticker' but offers no examples, format constraints, or clarification of what constitutes a valid ticker (e.g., symbol vs. company name). The description essentially restates the parameter name without enriching it.
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 it provides 'the full alternative-data dossier for a ticker' and enumerates 15 specific data sources, making the tool's purpose concrete. It distinguishes itself from a generic alt-data feed by emphasizing comprehensiveness, but it does not explicitly differentiate itself from the sibling tool 'stoquant_get_alt_data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using it 'to surface catalysts and red flags an ordinary data feed misses,' giving a clear use case. It also explains that sources with no recent activity are null, which helps set expectations. However, it does not mention when to prefer this over the simpler 'stoquant_get_alt_data' or other focused alternatives.
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?
Annotations already declare readOnlyHint and openWorldHint, so the description does not need to repeat those. It adds a useful structural detail about the 'data' field containing news, filings, and earnings, which gives a hint about the response layout. No contradictory behavior is disclosed, but other behaviors like rate limits or error handling are not mentioned.
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 two sentences, starts with the core action ('Combined event view'), and every phrase adds meaning. It avoids redundant wording and is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's purpose and what it returns (news, filings, earnings) without an output schema. It lacks details like time ranges or pagination, but for a read-only aggregate with a single parameter, it is sufficiently complete for an agent deciding when to use it.
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?
The input schema has only one parameter (ticker) and no description in the schema. The description mentions 'for a ticker' but does not provide any additional context about the format, examples, or constraints. With 0% schema coverage, the description should compensate more, but it barely does.
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 is a combined event view for a ticker containing news, filings, and earnings. It explicitly differentiates from sibling tools like stoquant_get_news and stoquant_get_sec_filings by emphasizing the combined nature and positioning itself as 'the single best call' for a holistic view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context—'what is happening with this stock'—and implies this is the go-to tool for a combined snapshot. However, it does not explicitly name alternatives or state when to avoid using this tool, only implicitly distinguishing from single-data-type 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the data is daily and spans ~30 days, giving temporal context. It does not describe return format or processing details, but with annotations present, a 3 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 two sentences long, with the first sentence front-loading the core definition and time window. The second sentence adds a practical use case. No unnecessary words, and the structure is scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description provides enough context to select it correctly. It covers purpose, time window, and use case. The lack of an output schema or parameter details is mitigated by the tool's simplicity and the clear differentiation from related tools.
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 coverage is 0% and the description does not mention the 'ticker' parameter at all. While 'ticker' is self-explanatory in a financial context, the description fails to compensate for the missing schema documentation, leaving the agent to infer its meaning from common knowledge.
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 gives a specific verb+resource: 'Daily social mention-volume and sentiment trend for a ticker over the last ~30 days.' It clearly distinguishes from snapshot tools by saying 'not just the current snapshot,' which differentiates it from siblings like get_social_sentiment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use it: 'Use to see whether attention and bullishness are building or fading, not just the current snapshot.' This provides clear context and implies a comparison to snapshot tools, though it does not explicitly name alternatives or list 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?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful context about the 90-day window and the breakdown of action types, but does not mention return format, pagination, or data boundaries. This is acceptable but not rich behavior disclosure.
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, both informative: the first states what the tool returns, the second adds the nuance of use. Nothing extraneous, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and read-only annotation, the description covers the essential time window, action types, and usage context. With no output schema, it doesn't detail return formatting, but the description is enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'ticker' parameter, and the description only mentions 'for a ticker.' It implicitly conveys that ticker is the stock symbol, but provides no format examples or validation hints. The parameter is simple and obvious, but the description adds minimal semantic value beyond the schema's property name.
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 returns 'recent analyst rating changes' including 'upgrades, downgrades, reiterations, and initiations,' with a '90-day action breakdown.' It distinguishes itself from siblings like analyst estimates and price targets by emphasizing momentum in sentiment vs. static consensus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to see the direction of sell-side revisions (momentum in sentiment), not just the static consensus,' providing a clear when-to-use context. It doesn't name specific sibling alternatives but the contrast with static consensus implies a differentiation from consensus-type 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?
Annotations include readOnlyHint=true, which already indicates a safe read operation, lowering the bar for the description. The description adds the specific output fields and intent, but does not disclose any behavioral limitations such as the number of holders returned, ordering, or data freshness. It provides some value but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and output fields, with no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the key return fields (organization name, shares held, percent ownership) and the purpose, which is sufficient for a simple one-parameter read-only tool. It could be more complete by specifying the list size or sorting order, but the provided information covers the main use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (ticker) with 0% description coverage. The description references 'for a ticker', which aligns the parameter with the tool's purpose, but it does not add format, examples, or constraints beyond the parameter name itself. For a simple self-explanatory parameter, this meets the baseline but doesn't exceed it.
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 the tool returns 'Top institutional holders for a ticker' with specific fields (organization name, shares held, percent ownership), using a specific verb and resource that distinguishes it from sibling tools like get_institutional_ratings or get_insider_trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case ('Use to gauge institutional concentration and who the big holders are.'), giving clear context for when to use it. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.
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?
The annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context beyond that by noting that some future periods may have null estimates until coverage fills in, and by clarifying the response structure under `data` and `count`.
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 two sentences, front-loaded with the core purpose, followed by usage guidance and a caveat. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return structure (data with per-fiscal-period fields and count) and notes null estimates. It could mention units or format details, but for a simple single-parameter tool, this is reasonably complete.
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?
The schema has only one parameter, ticker, with no description (0% coverage). The description merely repeats 'for a ticker' without adding format, examples, or further meaning, so it does not compensate for the missing schema description.
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 provides sell-side analyst forward estimates for a ticker, and specifies the exact data fields (EPS and revenue averages/high/low, analyst count) per fiscal period. This is specific and distinguishes the tool from siblings like analyst_price_targets and analyst_changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for consensus expectations and dispersion,' providing a clear use case. It does not mention when not to use or alternative tools, but the positive guidance is enough to count as clear context without exclusions.
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?
Annotations already indicate a safe read operation, and the description adds behavioral detail by specifying the consensus block fields (avgTarget, highTarget, lowTarget, numAnalysts) and the existence of underlying data. This goes beyond the annotations' safety hint.
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 two sentences with a clear front-loaded statement and then the usage context. Every word earns its place, and it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with readOnlyHint and no output schema, the description provides adequate context about the return structure (consensus block and data) and purpose. However, it doesn't explain the contents of the data array or possible edge cases, so it's not fully complete.
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?
The schema has one required string parameter, ticker, with no description (0% coverage). The description only rephrases 'ticker' without adding format details, examples, or additional semantics, so it fails to compensate for the missing schema information.
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 the tool provides analyst price targets for a ticker, including a consensus block with specific fields. It also includes the purpose of gauging upside/downside and target dispersion, which differentiates it from sibling tools like analyst estimates or changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'Use to gauge implied upside/downside vs the current price and the dispersion of targets.' However, it does not explicitly mention when not to use or name alternative tools, so it lacks exclusions.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds valuable behavioral context: the output is under 'data' with specific fields, and filtering by a ticker may return an empty list if no catalysts exist. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the output structure, then explains usage and an edge case. Every sentence earns its place, with no redundancy or fluff.
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's simplicity (one optional parameter, no output schema), the description covers the return format, the two invocation modes, a potential empty result, and the intended use case. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single optional 'ticker' parameter (coverage 100%), and the description essentially restates that. It adds the edge case that the result may be empty for a ticker without catalysts, but this is more about behavior than parameter semantics. Baseline 3 is appropriate.
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 identifies the tool as returning upcoming and recent catalysts with a list of fields, and states the intent 'Use to find date-driven, event-based opportunities.' This is specific and resource-focused, but it does not explicitly distinguish this from the sibling tool 'stoquant_get_catalyst_watch', so it does not fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context ('Use to find date-driven, event-based opportunities') and explains the market-wide vs. ticker-filtered modes. However, it does not mention when not to use it or reference alternative tools, so it lacks explicit exclusions or alternatives that would merit a 5.
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?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds valuable behavioral context by indicating metrics appear under a `data` key and by explaining the clusterScore interpretation. No contradictions with annotations observed.
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 just two sentences, front-loads the output fields, includes an interpretive note, and names the companion tool. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool without an output schema, the description lists all return fields, explains their meaning, and relates the tool to insider trades. This is sufficient for the agent to understand what it will receive and why it matters.
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?
The sole parameter 'ticker' has zero schema description coverage, and the description only says 'for a ticker,' providing no format, examples, or constraints. Since schema coverage is 0%, the description should compensate but does not, leaving the agent to infer everything from the parameter name.
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 the tool returns insider-buying cluster metrics for a ticker and lists the exact fields provided. It also distinguishes itself from stoquant_get_insider_trades by noting it pairs with that tool for raw transactions, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use cases: evaluating cluster buying as a bullish signal and complementing raw insider transaction data. It names the sibling tool for raw transactions, providing context for when to use this tool vs. the alternative, though it stops short of explicit when-not-to-use guidance.
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?
The readOnlyHint annotation already declares this as a safe read operation. The description adds valuable behavioral context by explaining the union of filing types, the output fields (items, count/total, accession, formType, filedDate, category, label), and the 'recent' scope. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, starting with the core purpose, then listing filing types, describing output fields, and ending with a use case. Every sentence contributes useful information, though the enumeration of filing types makes it slightly longer than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by specifying the item structure and field names. It covers the main scenarios and the union scope thoroughly. Minor details like pagination or ordering are not mentioned, but for a list-fetching tool with a limit parameter, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents two of three parameters (days, limit) with default/max values, and ticker is self-evident. The description adds little parameter-specific detail beyond saying 'recent' which is already implied by the days parameter. With schema coverage at 67%, the description provides marginal added value.
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 the tool gets recent SEC filings for a ticker, enumerates the specific filing types covered (8-K, NT-10K/Q, 13D/13G, etc.), and describes the output structure. This specific verb+resource+scope distinguishes it from all sibling tools, which cover other data domains like social trends, quotes, and analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'Use to read the actual regulatory record behind a thesis.' It provides clear context for when to use the tool, but does not explicitly name alternatives or exclusions. Since no other sibling tool covers SEC filings, the unique niche is implied, making the guidance effective.
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?
Annotations already declare readOnlyHint=true, and the description adds the expected return fields (id, name, description) and the full inventory of screens. It does not contradict the annotations, though it omits how the optional universe parameter might affect results, which is more of a parameter-semantics gap.
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 efficiently structured, leading with the core purpose, then listing each screen with a useful parenthetical, and ending with actionable usage advice. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description provides the return structure and the complete set of screen names. The only notable gap is the unexplained universe parameter, but overall the description is sufficiently complete for the tool's low complexity.
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 never mentions the 'universe' parameter. The agent is left without any guidance on what this parameter does or whether it filters the list, so the description completely fails to compensate.
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 'List the curated prebuilt screens with their id, name, and description,' which is a specific verb+resource construction. It enumerates each available screen, making it easy to distinguish from sibling tools like stoquant_run_prebuilt_screen.
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 says 'Call this first, then run one with stoquant_run_prebuilt_screen' and contrasts with 'hand-built filters,' giving clear when-to-use and alternative guidance.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds valuable context: data is cached, keyed by source, and includes fetchedAt timestamps. The structure under `data` is also disclosed, going beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences pack a lot: the tool's purpose, the list of sources, the response structure, and the relationship to a sibling tool. No fluff, front-loaded with the key noun phrase 'Generic cached alternative-data'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter cached-data tool without an output schema, the description provides enough context about what is returned (sources, structure, timestamps) and how it fits with alternatives. It could be slightly more explicit about the response shape but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'ticker' with no description (0% coverage), so the description carries the burden. It says 'for a ticker' which implies the purpose but does not specify format (e.g., uppercase, exchange suffix) or other constraints. Minimalistic but functional.
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 the tool retrieves cached alternative data for a ticker, listing specific sources (google_trends, wikipedia_pageviews, options_iv, openinsider, edgar_8k). It differentiates from the sibling tool stoquant_get_alt_signals by noting it 'complements' it with raw data, which is a specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions complementing stoquant_get_alt_signals, which gives clear context on when to use this tool for raw alternative data vs derived signals. It lacks explicit exclusions (e.g., when not to use), but the relationship to alternatives is clearly stated.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is known. The description adds useful behavioral context: results appear under `items`, each with buy detail, a current quote, and Q-Score, plus the default threshold. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no redundant wording. Every phrase contributes meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with three optional parameters and no output schema, the description adequately covers purpose, output structure, default threshold, and use case. It lacks details on sorting/pagination, but these are not critical for an agent deciding to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented with defaults. The description mentions the default >=$1M threshold but does not add new semantics beyond the schema. Baseline of 3 is appropriate.
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 ('list') and resource ('tickers with large recent insider purchases'), clearly scoped to 'market-wide'. It distinguishes itself from sibling tools by focusing on market-wide discovery rather than ticker-specific insider data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case ('where are insiders putting real money right now') and explicitly states the market-wide context. However, it does not explicitly mention when not to use or name alternative tools for specific-ticker insider queries.
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?
Annotations already declare readOnlyHint, so no additional safety context needed. The description adds value by disclosing the return shape (`{gems:[...], totalCount, lastScanAt}`) and explaining the freshness filter's semantics, which enriches the agent's understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence defines the tool's purpose with concrete criteria; the second covers return format and usage. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with two optional parameters and no output schema, the description covers the essential context: purpose, screen definition, freshness meaning, and return structure. It could add more about the shape of each gem, but the total context is sufficient for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description rephrases the freshness parameter ("filters by how recently a gem's signals fired") but adds no new technical detail beyond what the schema provides, yielding a baseline score.
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 the tool returns undervalued small-caps with confirming signals, specifying the 'hidden gem' screen criteria. This distinguishes it from sibling tools like momentum-focused screens, fulfilling a specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context by recommending it for value-oriented idea generation and explicitly contrasting it with momentum. It does not name alternative tools or provide explicit when-not-to-use, but the context is strong enough.
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?
Annotations already declare readOnlyHint=true, and the description adds context about the aggregated nature and signal direction. It doesn't contradict annotations and provides behavioral context beyond the safety profile, though it could mention limitations or data source specifics.
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 two sentences: the first states the core purpose, the second gives usage guidance. Every word contributes value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides enough information about the response content (holder additions, reductions, signal). It could elaborate on the signal's interpretation, but it is sufficient for a straightforward sentiment tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, ticker, with no description (0% coverage). The description mentions 'for a ticker', which confirms the parameter's purpose but doesn't add details like format or requirements. It partially compensates for the schema gap, but the parameter is self-explanatory.
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 the tool provides aggregated institutional sentiment with specifics on holder additions/reductions and a net signal direction. It distinguishes itself from analyst ratings, differentiating it from sibling tools like stoquant_get_analyst_estimates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as a 'smart money' flow read and contrasts it with analyst ratings, giving a clear use case. It doesn't list explicit alternatives, but the context is sufficient to guide when to use this tool over others.
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?
The annotations already declare readOnlyHint=true and openWorldHint=true, which covers safety and dynamic behavior. The description adds useful behavioral details like 'by recent return' and the requirement for a full GICS name, but it does not disclose return structure, pagination, or potential error conditions. With annotations present, this is adequate but not exceptional.
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 three sentences, each earning its place. The first sentence front-loads the core purpose, the second gives clear usage, and the third conveys the critical constraint with examples and a reference. There is no redundancy or fluff, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema) and the description covers its purpose, usage, and a key constraint. It relies on the schema for parameter details and annotations for safety. However, it does not describe the return format or the exact meaning of 'recent return', which would be useful for agent invocation, but given the tool's low complexity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema by explicitly stating that sector 'must be a full GICS name' and referencing another tool for valid names, which clarifies the expected format more precisely than the schema alone. The limit parameter is already well-described in the schema, so no additional explanation is 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 the tool's function: 'Top and bottom performing stocks within a GICS sector, by recent return.' It uses a specific verb ('Get') and resource ('sector performers'), and distinguishes itself from sibling tools by focusing on sector-level leaders and laggards. The title 'Get sector leaders/laggards' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use to find what is leading or lagging inside a sector.' It also gives a prerequisite for the sector parameter (must be a full GICS name) and points to a sibling tool for valid names, which is helpful. However, it does not state when not to use this tool or list alternative tools for similar tasks, so it falls short of a full 5.
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?
Beyond the readOnlyHint annotation, the description discloses the response structure (append-only snapshots, summary fields like latestFloat and latestRatio) and the interpretive context of short squeezes. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver purpose, structure, interpretation, and usage guidance without fluff. It is front-loaded with the core function, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with no output schema, the description covers the key aspects: what it returns, the summary fields, and a usage context. It lacks exact snapshot formatting or time range details, but is adequate for AI decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single ticker parameter with no description coverage. The description merely restates 'for a ticker' and does not add format/constraints. Since the schema is self-explanatory, a baseline 3 is appropriate.
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 provides 'short-interest history for a ticker' with a specific output structure (snapshots + summary). This distinguishes it from all sibling tools, none of which cover short interest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit use case: 'Use for crowded-short reads,' plus interpretive guidance about rising/falling short interest signaling squeezes or covering. However, it does not mention alternatives or when not to use it.
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?
Annotations already provide readOnlyHint and openWorldHint. The description adds valuable context: the `{data:null}` response for unsupported tickers should be treated as 'no data' not an error, and clarifies the output is qualitative. This goes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and output content, followed by a concise caveat. No wordy or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool, the description covers the output contents and the key edge case (null data for certain tickers). It stops short of describing the exact return structure, but given the low complexity, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a required string 'ticker' with 0% description coverage. The description says the tool is 'for a ticker' and implies the ticker should be a mid/small-cap, but it does not define the ticker format or any constraints beyond that, only partially compensating for the missing schema description.
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 identifies the tool's purpose: 'Qualitative competitive intelligence for a ticker' and specifies the exact content areas (economic moats, structural weaknesses, upcoming catalysts, peer comparison). This distinguishes it from sibling tools like catalyst-specific or evidence-focused tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Best for mid/small-caps') and when the tool is less appropriate (mega-caps and thinly-covered names may return null data). However, it does not name an alternative tool, so it lacks the full 'alternatives' guidance.
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?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds valuable behavioral context: 'May be empty between scans' and shows the empty response shape (`{stocks:{}}`). It also explains the underlying signal logic (Q-Scores + corroborating signals), giving the agent a better mental model of what the results represent.
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—two sentences. The first defines the tool's output, the second gives usage context and a caveat. No redundant phrases; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no required parameters, no output schema), the description covers the key points: what it returns, when to use it, and the possible empty state. It could mention whether the list is sorted or if a limit must be set, but for a simple list tool with one optional parameter, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'limit' with default and max values (100% coverage). The description does not need to repeat parameter details. It adds no new parameter semantics, so baseline 3 is appropriate.
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 the purpose: 'StoQuant's current highest-conviction names' with a specific definition ('strongest Q-Scores backed by multiple corroborating signals'). It distinguishes itself from sibling tools like get_qscore (single-stock score) or get_hidden_gems by focusing on top-conviction picks as a starting point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use as the starting point for what does the platform like right now'. This gives a clear when-to-use context. It lacks explicit alternatives or exclusions, but the 'starting point' phrasing strongly implies this is a high-level overview tool.
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?
Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds context about the content type (narrative layer) but doesn't disclose details like data freshness or pagination. With minimal constraints (zero parameters), this is adequate but not rich.
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 two sentences, front-loaded with the core function, includes helpful examples in parentheses, and closes with a clear usage statement. Every word earns its place with no redundancy.
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 zero-parameter, read-only tool with no output schema, the description sufficiently explains what is returned (themes and sectors) and why to use it. The examples ground the concept for an agent, making the tool fully understandable without additional details.
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?
The tool has zero parameters, and schema description coverage is 100% (empty schema). The description doesn't need to elaborate on parameters, and it correctly avoids mentioning any. Baseline 4 is appropriate since no parameters require explanation.
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 the tool returns current macro investment themes with related sectors, providing specific examples (e.g., rate-cut beneficiaries, AI capex). It distinguishes itself from siblings by framing as the 'narrative layer' for thematic idea generation, which is unique among the many macro and stock tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for thematic idea generation that ties stocks to a macro thesis,' giving a clear usage context. It doesn't mention exclusions or alternatives, but the context is specific enough to differentiate it from other macro tools like get_macro_indicator or get_macro_dashboard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors beyond annotations: null/empty score handling before ~10am ET, unavailable dimensions contributing 0, and the sector-residualized methodology. These are meaningful operational details that annotations do not convey.
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 dense but well-organized, front-loading the core definition and then detailing the return structure. The listing of components is necessary because there is no output schema, but it is concise enough that every sentence delivers value.
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's complexity, the lack of an output schema, and only two input parameters, the description fully specifies the return fields, caveats, and selection of the scoring horizon. It leaves no critical gap for an agent to select or invoke the tool correctly.
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?
The description only says 'period selects the scoring horizon', which repeats the schema's description. It does not explain the difference between 30d and 90d or how the choice affects the score. The ticker parameter is self-evident. With 50% schema coverage, the description adds little value here.
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 the tool computes StoQuant's 0-100 composite Q-Score for a ticker, blending multiple dimensions. It explicitly positions it as 'the best single tool for is this a good stock right now', distinguishing it from sibling quote/ML tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a strong usage context ('best single tool for...') and a timing caveat about early morning data not yet refreshed. It stops short of explicitly naming alternatives or when-not-to-use, but the guidance is clear and sufficient.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows it is a safe read operation. The description adds useful context about the default recent window when dates are omitted, but does not disclose response dimensions or data completeness. No contradiction with annotations. This matches the calibration example where annotation-covered tools get a baseline of 3.
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 two sentences, front-loaded with the core purpose, and contains zero waste. It efficiently packs the tool's function, use case, and date format guidance into a compact form.
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?
With only 2 optional parameters, no output schema, and strong annotations, the description is sufficiently complete. It explains what the heatmap shows (hit-rate over time/ticker), when to use it, and how to specify dates. The agent has all necessary information to decide when to invoke and how to pass parameters correctly.
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?
The input schema already provides a pattern and description for YYYY-MM-DD dates with 100% coverage. The description goes beyond the schema by explaining the default behavior when dates are omitted ('omit for the default recent window'), which clarifies parameter optionality and default values. This adds meaningful semantics beyond the structured fields.
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 the tool produces a 'Hit-rate heatmap of signals over time/ticker', specifying both the resource (signals) and the output form (heatmap). It further clarifies meaning with 'which signal types worked when', distinguishing it from sibling tools like stoquant_get_signal_accuracy which likely returns a single accuracy value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: 'Use for backtest-style "has this signal been reliable lately" questions.' This provides clear contextual guidance. However, it does not explicitly name alternatives or state when not to use it, so it falls one step short of a top score.
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?
Annotations already mark the tool as read-only and open-world. The description adds meaningful context by explaining the two return fields (originalQScore and adjusted) and what the adjustment is based on (stage/regime). This goes beyond the annotations without contradicting them, offering value on top of the structured data.
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 the return values and usage guidance. No filler, every sentence earns its place. The tool name and title are not repeated unnecessarily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no output schema), the description conveys the core return fields and usage context. It lacks details about error handling or edge cases, but the annotations provide the safety profile, and the description is sufficiently complete for an agent to invoke it correctly.
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?
The schema has zero description for the ticker parameter, and the description only says 'for a ticker' without explaining the expected format or scope. Since schema_description_coverage is 0%, the description carries the burden but fails to significantly compensate beyond what the parameter name already implies.
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 the tool returns both the raw Q-Score and a stage/regime-adjusted variant for a ticker. It distinguishes itself from the sibling tool stoquant_get_qscore by explicitly pointing to it for a full breakdown, making the purpose unambiguous.
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?
Provides explicit guidance on when to use this tool: 'Use this when you want the score adjusted for the stock's lifecycle stage and current market regime rather than the raw composite.' It also names an alternative for the full breakdown, which is a clear when-not-to-use signal.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds behavioral context beyond this: it reveals that sources are 'credibility-weighted platform aggregates, not raw noise,' and lists exact output fields. This is valuable context that complements the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the first sentence front-loading the output fields, the second clarifying the use case, and the third adding a data quality note. Every sentence earns its place with no redundancy or fluff.
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 one-parameter read-only tool, the description is complete: it names the input, lists the key output fields, explains the intended use, and notes data quality. With readOnly and openWorld annotations, no further behavioral disclaimers are necessary. The absence of an output schema is mitigated by the explicit field list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter, ticker, with no schema description (0% coverage). The description mentions 'for a ticker' but does not specify format or example values. Since the parameter name is self-explanatory in context, the description adds minimal value; a 3 reflects that it is adequate but could be more explicit.
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 provides 'Current social-media buzz for a ticker' and enumerates the specific output fields (totalMentions, sentimentBreakdown, etc.). It distinguishes itself from siblings by focusing on current sentiment with credibility-weighted aggregates, making the resource and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage context: 'Use to read retail attention and crowd sentiment.' This tells the agent when to select this tool. However, it does not explicitly mention alternatives or when not to use it, though the distinct purpose partly differentiates it from sibling tools like get_social_trend or get_social_momentum.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate safety. It adds meaningful behavioral detail by explaining the ranking metric (Wilson lower-bound on true directional accuracy), which gives the agent insight into how the leaderboard is computed. It stops short of discussing response format or edge cases, but for a simple read-only tool this is strong.
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 clean sentences, front-loaded with the core output (leaderboard of social sources) and followed by a clear use case. No wasted words; every sentence adds value.
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 one-parameter read-only tool with rich annotations, the description fully covers purpose, usage, and expected output (ranked list). There is no output schema, but the description hints at the structure well enough. No gaps remain for the agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'limit' parameter, which is documented with default and max. The description does not add further parameter details, so it meets the baseline of 3 where the schema does the heavy lifting. No additional semantics are 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 a specific action and resource: it returns a 'Leaderboard of social sources ranked by true directional accuracy (Wilson lower-bound on their calls)'. This distinguishes it from sibling tools like stoquant_get_social_sentiment or stoquant_get_accuracy_summary, focusing on source credibility rather than raw sentiment or signal accuracy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use to judge how much weight to give a platform or author's sentiment'. It implies an alternative (raw mention volume) by contrasting with it, but does not explicitly name a sibling tool or provide exclusion criteria. Still, the guidance is practical and actionable.
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?
Annotations already provide readOnlyHint, so safety is covered. The description adds behavioral context by mentioning signed magnitudes and directional effects on probability, which goes beyond annotations. It doesn't describe output format or edge cases, but the added context is meaningful.
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 concise sentences deliver core functionality and usage guidance with no unnecessary words. The description is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description covers purpose, usage context, and a key constraint. It hints at return content but lacks details on ordering or error behavior. Overall, it's sufficiently 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), but the description compensates for the most ambiguous parameter (horizon) by requiring it to match the prediction. The top parameter is already described in the schema, and ticker is self-evident from the tool name. Partial compensation is sufficient.
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 identifies the tool as explaining the top feature contributions behind an ML outperformance prediction, with signed magnitudes showing what pushed probability up/down. It distinguishes itself from sibling stoquant_get_ml_prediction by emphasizing the 'why' aspect.
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 states to use after stoquant_get_ml_prediction when the user asks why the model is bullish/bearish. It also provides a critical constraint that the horizon must match the prediction being explained, giving clear when-to-use guidance.
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?
Beyond the annotations (readOnlyHint=true, openWorldHint=true), the description adds valuable behavioral context: the tool may return a specific error early in the trading day, and the agent should treat that as 'not ready' rather than a failure. This is practical operational knowledge that annotations do not convey.
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 two sentences with no unnecessary words. It front-loads the core function and return values, then adds the caveat about early-day behavior. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and the annotations declare read-only safety, the description sufficiently covers what the tool returns (1-day and YTD returns) and an important edge case. It is complete for a simple, parameterless read-only tool.
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?
The tool has zero parameters, so baseline is 4. The description does not need to explain parameter semantics beyond what the schema (empty) already provides. It focuses on output semantics, which is appropriate.
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 the tool's function: it retrieves current performance (1-day and YTD returns) for major index ETFs like SPY, QQQ, and IWM. It also distinguishes itself by noting the use case of benchmarking an individual stock against the market, which differentiates it from sibling tools that focus on quotes, sectors, or signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Use to frame an individual stock against the market.' It also communicates an important temporal condition (early trading day behavior), which helps the agent decide when to call it. It does not explicitly list alternatives, but the use case is clear enough.
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?
Annotations already provide readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds value beyond this by disclosing what the response contains — regime, indicators, macroStress, sectorRotation with valid GICS names, calendar, and themes — which is useful behavioral context given there is no output schema. It does not mention data freshness or response size, but with annotations present the bar is lower.
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 the primary purpose. The first sentence is dense but well-organized, listing all components in a readable list. The second sentence provides usage context. No wasted words; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter, read-only dashboard with safety annotations, the description is nearly complete. It explains the aggregated nature, enumerates all six return components, and gives a practical usage guideline (first call before drilling into stocks). Minor gaps exist — e.g., what 'macroStress' measures or how 'favored' sectors are determined — but these are not critical given the tool's simplicity.
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?
With 0 parameters, the baseline is 4. The schema has no properties, and the description correctly does not invent parameter semantics. Instead, it clarifies the return semantics (which fields the dashboard includes), which compensates for the absence of an output schema and helps the agent understand what the tool produces.
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 the tool's function: 'Full top-down macro picture in one call' with an explicit enumeration of contents (regime, indicators, macroStress, sectorRotation, calendar, themes). This distinguishes it from granular siblings like stoquant_get_market_regime or stoquant_get_macro_indicator by framing it as the aggregate dashboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Best first call for "what's the macro backdrop" before drilling into stocks.' This tells the agent when to use it (as a top-down starting point) and implies when not to (for stock-specific questions). However, it does not explicitly name alternative sibling tools or exclusion cases, stopping short of a 5.
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?
Annotations declare readOnlyHint and openWorldHint, so the safety profile is already known. The description adds value by disclosing the output structure (`items` with publishedAt, headline, source/provider, category, sentiment label) and the temporal intent ('recent'). It doesn't discuss ordering or pagination, but the added return-shape detail goes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the core purpose and return fields, second gives usage context and an explicit alternative. Every clause contributes, with no filler or repeated schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully describes the primary return payload (`items` fields). It also covers when to use the tool and how it differs from the closest sibling. It could mention sorting or sentiment label values, but for a simple read-only headline tool, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (days and limit have descriptions, ticker does not). The description only says 'for a ticker' without explaining ticker format or clarifying the relationship between days/limit and the news results. It does not meaningfully enhance the parameter understanding beyond what the schema already provides, so a middle score is appropriate.
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 the tool retrieves 'Recent news headlines for a ticker', with a specific resource and scope. It enumerates the fields returned inside `items` and explicitly distinguishes this tool from the sibling `stoquant_get_news_events`, leaving no ambiguity about what it does.
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?
The description provides a concrete use case: 'Use for the latest narrative around a stock.' It also explicitly names an alternative, `stoquant_get_news_events`, for a combined news+filings+earnings view, giving clear when-to-use and when-not-to-use guidance.
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?
Annotations already declare readOnlyHint and openWorldHint, so the description doesn't need to restate safety. It adds useful context that the output is under `data` and enumerates the metrics included, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the core function, followed by usage guidance and a sibling link. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple single-parameter schema and no output schema, the description supplies the essential output contents ('under `data`'), use cases, and relationship to a key sibling. It lacks a detailed return structure but is complete enough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (ticker) and schema coverage is 0%, so the description must compensate. It clarifies the tool operates 'for a ticker', but provides no details on format or examples. This is adequate but minimal for a self-evident parameter.
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 states the tool provides quantitative analytics for a ticker, listing specific contents (factor exposures, correlation/quality metrics, risk decomposition). It distinguishes itself from the sibling stoquant_get_qscore by noting it complements the verdict with underlying detail.
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 recommends use for portfolio-construction and factor-tilt questions, and contrasts with stoquant_get_qscore (verdict) by positioning this tool as providing the underlying quant detail. This gives clear when-to-use and alternative context.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the data is historical and that the result is an array of records with specific fields, which is valuable context beyond the annotations. It doesn't discuss staleness, update frequency, or potential caveats, but it provides solid extra context.
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 only two sentences and front-loads the core purpose. It packs essential output field details and a usage heuristic without redundant filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema, the description carries the burden of explaining return values; it does so by listing all fields and some semantics (hitRate as 0-1, avgReturnPercent). However, terms like 'precision' and 'windowDays' are only named, not fully defined, and it doesn't differentiate from closely related sibling tools, leaving slight gaps.
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 baseline is 4. The description appropriately focuses on output semantics and does not need to explain parameter behavior. It adds value by describing what each returned field means, which is useful even with an empty schema.
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 the tool returns 'Historical track record per signal type' and enumerates the exact fields returned (signalType, hitRate, totalObservations, etc.). This distinguishes it from more generic siblings like get_accuracy_summary or get_signal_accuracy_heatmap by emphasizing per-signal-type granularity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to 'Use to weight how much to trust a given signal before acting on it' and provides a concrete heuristic ('prefer signals with high hitRate AND large totalObservations'). It clearly conveys when to use the tool, though it doesn't mention when not to use it or name direct alternatives.
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?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context: the exact surge threshold (2x+), the time window (last hour vs prior hour), and the included data (sentiment and a recent post snippet). It does not contradict annotations and provides value beyond them, though it omits details like result count or pagination.
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 succinctly written in two sentences: the first defines the output and features, the second provides the application context. Every phrase adds value, and the most critical information (what the tool returns) is front-loaded. No unnecessary wording or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, and annotations covering safety), the description adequately explains what the tool does, the signal definition, and how to use it. It could be slightly more complete by mentioning that it returns a list of tickers or any limitations, but it does not leave major gaps for an agent selecting this tool.
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?
The tool has zero parameters, and the schema coverage is 100% (empty properties). According to the rubric, 0 parameters earns a baseline of 4. The description does not need to explain parameters because none exist, and it clearly describes the output semantics instead.
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 specifies exactly what the tool does: returns tickers with a 2x+ surge in social mentions over the last hour versus the prior hour. It clearly defines the resource (social momentum) and the filter criteria, and distinguishes it from siblings by calling it 'the earliest social-momentum signal.' This is a specific verb-plus-resource statement that leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'Use to catch breakouts in attention before they are widely noticed.' This provides context for when to apply the tool, but it does not explicitly contrast with alternatives such as stoquant_get_social_trend or stoquant_get_trending_social. Since it lacks explicit when-not-to-use or alternative tool mentions, it earns a 4 rather than a 5.
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?
Annotations already declare readOnlyHint and openWorldHint, so the description adds value beyond them by providing concrete behaviors: the ~90-day lookback, 50-ticker limit, interval options and their meanings, and the return type (close prices only, not OHLCV). This is useful context that goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose and key constraints, and contains no redundant wording. Every clause adds information about the data scope, granularity, or output shape, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and relatively simple inputs, the description covers the essential behavior: time range, ticker limit, interval effect, and return type (close prices per ticker). It does not detail output ordering, missing data handling, or error cases, but for a straightforward data-retrieval tool, the provided information is adequate 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters (only interval has a description), but the description enriches both: it restates the ticker limit (already in schema) and, more importantly, expands the interval enum with plain-language meanings ('1d daily, 1wk weekly, 1mo monthly'). This compensates for the schema gaps, though ticker format is not detailed.
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 identifies the tool as returning historical price series for up to 50 tickers over ~90 days, with a specific use case for charting or trend/return computation. It distinguishes itself from sibling tools by explicitly stating it returns close prices only, not full OHLCV data, which separates it from quote tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by mentioning charting and trend/return analysis, and clarifies a limitation ('not full OHLCV') that helps rule out alternatives. However, it does not explicitly name alternative tools for different use cases, nor state scenarios when this tool should be avoided, so it stops short of full explicit guidance.
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?
The annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds substantial context beyond that: the exact return structure (five grids with cells containing label, value, and tone) and the semantics of tone values ('bullish'|'bearish'|'neutral'|'unknown'). This helps the agent understand what to expect.
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, well-structured paragraph that front-loads the purpose, then details the output structure, and ends with usage guidance. Every sentence adds value, though it is a bit lengthy. It is organized and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a minimal schema and no output schema, the description thoroughly explains the return format, interpretation (how to assemble bull/bear cases), and usage context. It covers the essential aspects for correct invocation and result processing. Minor gaps exist around edge cases like tickers with no evidence.
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?
The schema has one parameter 'ticker' with 0% description coverage, so the description carries the burden. It implicitly defines 'ticker' as the subject of the Q-Score evidence, which is sufficient for an agent to infer its meaning. However, it doesn't provide format constraints or examples, preventing a perfect score.
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 names a specific resource ('named, two-sided evidence behind a ticker's Q-Score') and elaborates on its content, distinguishing it from sibling tools by explicitly tying it to stoquant_get_qscore and the 'evidence layer' versus the 'dimension breakdown'. This is clear and specific.
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?
It explicitly says when to use the tool: 'Use this AFTER stoquant_get_qscore when the user asks WHY the score is what it is', and contrasts it with the dimension breakdown, giving clear selection guidance and an alternative. This is exemplary.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description only needs to add extra behavioral context. It does so by specifying the forward-looking 14-day window and listing the data fields (forecast, prior value, expected market impact), which goes beyond the annotation metadata.
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 exactly two sentences: the first states what the tool returns, the second explains when to use it. Every word earns its place, and key facts are front-loaded.
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 no parameters and no output schema, the description sufficiently covers what data is returned (forecast, prior, impact), the time window (~14 days forward), and the primary use case (flagging macro events). This is complete for a simple, read-only calendar tool.
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?
The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, but it enriches the tool's behavior by describing the calendar's content and time range, which is useful for an agent.
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 the tool provides a forward (~14 day) economic calendar with scheduled releases, forecast, prior value, and market impact. This specific verb+resource+scope is distinct from sibling macro tools like stoquant_get_macro_indicator or stoquant_get_macro_dashboard, which focus on individual indicators or broader dashboards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to flag upcoming macro events (CPI, FOMC, jobs) that could move positions,' giving a clear when-to-use context. It does not mention alternatives or exclusions, so it stops short of a 5, but the intended use case is well understood.
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?
Beyond the readOnly/openWorld annotations, the description discloses an important fallback behavior when the model cannot fit, explaining that uniform probabilities should be read as undetermined rather than a confident call. This adds meaningful behavioral context for interpreting results.
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 two sentences, front-loaded with the core definition and output, followed by a brief usage note and caveat. Every sentence earns its place without unnecessary detail.
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?
With no output schema and no parameters, the description carries the full burden of explaining the response. It covers the regime label, probability vector, and an edge case for model failure, making it complete for this tool's simplicity.
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?
The tool has zero parameters, so the schema already covers everything. The description does not need to add parameter semantics; the baseline of 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 explicitly states the tool provides a market-regime classification from a Hidden Markov Model over S&P 500 returns, listing the output components (regime label and probability vector). It clearly distinguishes this as a top-down market context tool from the many stock-level sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using it to set top-down context before stock-level calls, giving a clear usage scenario. It does not name specific alternatives or exclusions, but the context is sufficient for an agent to decide when to invoke it.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context about the nature of the results (risk/variance, screening criteria), which goes beyond annotations. It does not contradict annotations, but could have disclosed more about rate limits or result structure.
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 concise sentences front-load the core purpose and immediately follow with usage guidance and risk context. Every sentence adds value, with no redundant or extraneous text.
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 tool with a simple schema (one optional parameter) and no output schema, the description fully covers what the tool returns, its risk profile, and when to use it. It also differentiates from a sibling, making it contextually complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the only parameter ('limit'), so the description need not repeat it. The description focuses on tool purpose rather than parameter details, which is acceptable given the schema's completeness. Baseline score of 3 is appropriate.
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 ('Get') and resource ('multibagger candidates'), and clearly explains what the tool does: flags small/mid-caps with high upside potential based on revenue acceleration and improving fundamentals. It also distinguishes itself from sibling tool 'hidden gems' by noting higher risk/variance, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use for aggressive growth idea generation,' defining when to apply the tool. The comparison with hidden gems ('Higher risk/variance than hidden gems') implies a preference for more conservative scenarios, effectively providing an alternative and exclusion context.
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?
Annotations declare readOnlyHint, so no mutation risk. The description adds valuable behavioral context: prices are delayed per the data vendor, not tick-by-tick. This goes beyond the annotations and helps the agent set user expectations.
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?
Three sentences with no redundancy: first defines output, second gives usage and alternative, third adds a caveat. Every sentence earns its place.
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 one-parameter tool, the description covers all essential aspects: single ticker, output fields, batch alternative, and data delay. No output schema exists, but the listed fields suffice for the agent to understand what will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the 'ticker' parameter with examples (AAPL, BRK.B). The description reinforces 'ONE ticker' but adds no new parameter syntax or format details, so baseline 3 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 clearly states the tool's function: 'Real-time quote for ONE ticker' with specific fields (last price, change, bid/ask, high/low, volume). It explicitly differentiates from the sibling stoquant_get_quotes_batch by scope (single vs. batch).
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?
Provides explicit guidance: use for a single symbol, and for 2+ symbols use the batch tool. Also warns about data delay, setting expectations for when to use this tool.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe read-only nature is covered. The description adds valuable behavioral context about rate limit efficiency ('stays well under rate limits') and the return format ('one quote object per ticker'), which is beyond the structured data.
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 two sentences, front-loaded with the primary purpose, and every sentence adds value: what it does, when to use it, and what it returns. No waste.
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 single-parameter read-only tool with no output schema, this description is complete: it explains the functionality, the advantage over alternatives, and the return shape. No critical gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'tickers', and the schema already describes it as 'Up to 50 ticker symbols'. The description reinforces this but adds little semantic beyond what the schema provides, so the baseline of 3 is appropriate.
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 provides current quotes for up to 50 tickers in a single call, distinguishing it from the singular stoquant_get_quote tool by explicitly mentioning the batch nature and naming the sibling. The scope and resource are specific and unambiguous.
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?
The description explicitly states when to use this tool over the alternative: 'Preferred over calling stoquant_get_quote in a loop — same data, one request, stays well under rate limits.' This provides a clear when/when-not guideline and names the relevant sibling tool.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the tool's safe read-only nature is known. The description adds transparency beyond annotations by specifying the return fields (mentionCount, prevMentionCount, deltaPercent, etc.) and the time window ('last few hours'), which gives the agent a clear picture of what data to expect without contradicting 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and a compact list of output fields. It is concise and every sentence adds value, with no repetition or filler.
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 no-parameter, read-only list tool, the description is complete: it states what the tool returns, the time frame, and the intended use case. Since there is no output schema, the explicit listing of fields compensates. No critical information is missing for an agent to decide when to invoke this tool.
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?
The tool has 0 parameters, so schema coverage is 100% vacuously. Per the rubric, 0 params receives a baseline of 4. The description does not need to clarify parameters and instead focuses on output semantics, which is appropriate.
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 the tool returns the most-mentioned tickers across social platforms in the last few hours, with a specific list of fields. It distinguishes from siblings by emphasizing 'market-wide' discovery, differentiating it from tools like get_social_sentiment or get_social_trend that might focus on specific tickers or trend analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use for market-wide "what is retail talking about right now" discovery and early momentum.' This is clear context for when to use the tool, though it does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld, but the description adds valuable behavioral context: the benchmark preference (IWM/^RUT with SPY fallback), the meaning of spreadPp as 'the real edge', and inclusion of a Wilson confidence interval and dataSufficiency flag. This goes well beyond annotation hints.
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 dense sentence that front-loads the purpose and packs many details efficiently. While it is somewhat long and requires careful parsing, it contains no fluff and every clause adds useful 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?
With no parameters and no output schema, the description carries the full burden of explaining the return value. It thoroughly enumerates the fields, clarifies the benchmark fallback logic, and explains the significance of spreadPp and dataSufficient, making it effectively self-contained.
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?
The tool has zero parameters, so no parameter descriptions are needed. Per the rubric, a baseline of 4 is appropriate when there are no parameters and the schema provides full coverage.
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 begins with 'Platform-wide model scorecard' and enumerates the specific metrics returned, making it clear this is the aggregate accuracy summary for the whole platform. This distinguishes it from sibling tools like stoquant_get_signal_accuracy, which are more narrowly scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use to gauge overall reliability of StoQuant's signals right now,' giving a clear use case. It does not explicitly mention when not to use it or name alternative tools, but the platform-wide scope makes usage context sufficiently clear.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context: it is a curated, ranked 'hot list' of high-impact near-term catalysts, with examples of event types. It does not fully describe output format or sorting, but for a read-only list tool the added context is solid.
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 the core definition, followed by a clear usage directive. Every word contributes value; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and read-only/open-world annotations, the description gives enough context for an agent to understand what the tool returns and when to use it. It could be slightly richer on return structure, but the examples and scope make it adequately complete for a list-style tool.
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 zero parameters, so the description has no parameter semantics to add; per guidelines this yields a baseline of 4. The description does enhance meaning by explaining the scope and content of the returned list, which compensates for the empty schema.
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 a specific verb+resource+scope: it returns a 'cross-ticker hot list' of catalysts. It also lists concrete examples (FDA decisions, activist stakes, dilution events) and explicitly distinguishes itself from the per-ticker sibling tool stoquant_get_catalysts.
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?
It explicitly says 'Use for market-wide what's about to move discovery' and contrasts with the per-ticker tool, providing clear context for when to choose this tool over an alternative. This mirrors the high-scoring calibration example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds operational context: 'can occasionally time out on cold cache — retry once if so'. This discloses failure modes and retry behavior beyond the annotations, which is valuable for an agent.
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?
Three sentences, front-loaded with core capability, then use case, then performance caveat. Every sentence earns its place with no filler, making it concise and well-structured.
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?
Even without an output schema, the description lists indicators (RSI, MACD, Bollinger Bands, moving averages) so the agent can infer response shape. It covers alternatives, performance, and use case; complete for a simple single-ticker quote 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 has 50% description coverage (timezone described, ticker not). Description only adds 'one ticker' constraint but does not explain ticker format or timezone semantics. It fails to compensate for the undocumented ticker parameter.
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?
Description states 'Quote plus computed technical indicators for one ticker' and enumerates RSI(14), MACD, Bollinger Bands, and moving-average context. This clearly distinguishes it from sibling tools like stoquant_get_quote, giving a specific verb+resource+scope.
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 says 'Use when you need momentum/overbought-oversold context, not just price' and warns 'Heavier than stoquant_get_quote', directly comparing with an alternative and setting usage expectations. This is clear when-to-use guidance with a named sibling.
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?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds behavioral context beyond annotations by describing the response shape (`data` for recent observations, a `count`) and providing concrete examples of series IDs. It does not mention limitations like date ranges, but for a simple read-only macro lookup, this is sufficient additional context.
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?
Three concise sentences: the first states the core function, the second lists common IDs with meanings, and the third gives usage guidance. Every sentence earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description sufficiently covers the return structure (`data`, `count`), gives representative series IDs, and points to the dashboard for broader context. The lack of an output schema is compensated by hints about the response shape. Minor omissions like units or data frequency are not critical given the tool's simplicity.
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?
The schema already has 100% coverage with a description and examples for seriesId. The description adds further semantic value by explaining what each common ID represents (e.g., DGS10 → 10y Treasury yield, UNRATE → unemployment), which helps the agent select the correct series without external knowledge.
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 that the tool retrieves latest values for a single FRED macro series, specifies the response structure under `data` with a `count`, and lists common series IDs with meanings. It also distinguishes itself from the dashboard sibling by explicitly saying 'Use for a single specific indicator; for the full picture use stoquant_get_macro_dashboard'.
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?
Explicit usage guidance is provided: 'Use for a single specific indicator; for the full picture use stoquant_get_macro_dashboard.' This tells the agent exactly when to choose this tool over the alternative, and implies it is not intended for broad multi-indicator views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint and openWorldHint annotations. It discloses the structure of the return value (data.prediction fields), the meaning of the isHeuristic fallback, and the early-day refresh limitation. These are non-obvious behavioral traits that an agent needs to correctly interpret results, making the description transparent and useful.
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 dense but logically organized, starting with purpose, then return fields, then alternative tool, then caveats. Every sentence carries useful information, but the long first sentence with semicolon-separated fields could be broken up for easier parsing. Despite this, there is no fluff or redundancy, earning a strong score.
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?
With no output schema, the description takes full responsibility for describing the return structure, which it does thoroughly. It also covers the heuristic fallback and timing edge case, making the tool's behavior predictable in both normal and exceptional conditions. The description is complete enough for an agent to invoke the tool, interpret results, and know when to consult a sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents horizon with an enum and description, covering 50% of parameters. The description adds little beyond the schema: it repeats that horizon is in trading days and does not clarify ticker's format or constraints. Since the coverage is exactly 50%, a baseline score of 3 is appropriate without substantial added parameter clarification.
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 the tool's function: it returns the ML model's probability that the ticker will outperform the S&P 500 over a horizon. It also explicitly distinguishes itself from a buy/hold/sell call and from the sibling tool stoquant_explain_ml_prediction, which covers the feature-level 'why'. This level of specificity and differentiation makes the purpose highly clear.
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?
The description provides explicit usage guidance: it directly names stoquant_explain_ml_prediction as the alternative for feature-level explanations, and warns that the prediction is not a buy/hold/sell signal. It also includes a timing caveat about early trading day data freshness, telling agents to treat null predictions as 'not yet computed' rather than errors. These are concrete when-to-use and when-not-to-use instructions.
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?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds context about the response structure (peers with qScore, quote, market cap) and explains the meaning of each `by` mode, revealing behavior beyond the schema. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence front-loads the core purpose and output structure, the second details parameter options and use case. No unnecessary verbiage.
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?
With no output schema, the description fills the gap by explaining the response format (peers with qScore, quote, market cap), the relation modes, and the intended use case. It provides sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), but the description extensively explains the `by` parameter with its four enum values and meanings ('sector' same sector, 'tag' shared tags, etc.). This adds critical semantics beyond the raw enum values. `limit` is already described in the schema, and `ticker` is self-explanatory.
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 identifies the tool's purpose: 'Find peers of a ticker under `peers`' with specific output fields (qScore, quote, market cap). It distinguishes itself from siblings by focusing on peer/related stock retrieval rather than other quote or screening functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use context: 'Use to build a comparison set or find alternatives to a name.' This clearly indicates when to use the tool, though it does not explicitly mention when not to use it or name alternative sibling tools.
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?
Annotations include readOnlyHint=true, and the description reinforces read-only behavior by focusing on 'get' results. It adds useful context beyond annotations: universe default (sp500), the 'full' option, and the fixed result count. No contradiction or missing safety profile for a simple query 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?
Two sentences deliver purpose, usage preference, parameter semantics, and a caveat about result count. No filler, front-loaded with the core action, and efficiently structured.
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 lightweight tool with two parameters and no output schema, the description is complete: it tells the agent what to expect (ranked stocks), where to get ids, which alternative to prefer, and what the universe parameter does. The fixed result count covers a potential surprise.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only screenId described), but the description compensates by explaining the universe options and defaults. It also clarifies that screenId values come from stoquant_list_prebuilt_screens, adding meaning beyond the schema's bare example.
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 and resource: 'Run one curated screen by its id' and 'get the ranked matching stocks.' It clearly distinguishes from stoquant_list_prebuilt_screens (listing) and stoquant_run_screener (custom screening) by emphasizing curated/pre-tuned filters.
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?
Explicit guidance is provided: 'Prefer this over stoquant_run_screener for common intents' and 'from stoquant_list_prebuilt_screens' for ids. It also explains the universe parameter default and recommends 'full' for broader coverage, plus notes the fixed result count.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description reinforces this with 'Read-only — nothing is mutated.' It also discloses additional behaviors: AND-combination of filters, error handling for unknown fields, and performance characteristics (full-universe scans may time out). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite being long, every sentence serves a purpose: scope, safety, return format, field list, units, error behavior, resource pointer, and performance tip. Information is front-loaded with the core purpose first, and no content is redundant with schema or annotations.
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?
No output schema exists, so the description explicitly explains the return shape (array with ticker, name, price, plus requested metrics). It covers all critical operational details: filters, operators, universe, sorting, error handling, and performance caveats. This is comprehensive for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has only 60% coverage, but the description compensates with exhaustive parameter semantics: full list of valid fields, units (decimals, raw USD), sort-only fields, and the 'between'/'in' operator meanings. This adds substantial value beyond the schema.
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 'Run a custom stock screen' with specific verb and resource, and distinguishes itself from sibling tools like stoquant_run_prebuilt_screen. It is unambiguous about the tool's core function.
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?
Provides explicit guidance on when to use this tool (custom screening vs prebuilt), recommends a specific universe and filter count to avoid timeouts, and names an alternative tool (stoquant_run_prebuilt_screen). 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.

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:

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

Score Badge

Copy to your README.md:

[![stoquant-mcp MCP server](https://glama.ai/mcp/servers/ohadf2015/stoquant-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ohadf2015/stoquant-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/ohadf2015/stoquant-mcp'

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