unusual-whales-mcp

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
The tools are grouped into distinct categories (alerts, congress, darkpool, etc.), but some overlap exists between uw_flow, uw_options, and uw_stock regarding options data, which could cause misselection by an agent.
Naming Consistency5/5
All tool names follow a consistent 'uw_<category>' pattern with lowercase nouns, making it predictable and easy to understand.
Tool Count5/5
With 16 tools covering a wide range of financial data, the count is well-scoped for the server's purpose, providing comprehensive coverage without being excessive.
Completeness5/5
The server covers a comprehensive set of financial data domains (alerts, congress, darkpool, earnings, ETFs, flow, insider, institutions, market, news, options, politicians, screener, seasonality, shorts, stocks), leaving no obvious gaps for its intended use.
Average 3/5 across 16 of 16 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 77 commits in the last 12 weeks
- Last stable release on January 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) are consistent with read operations, but the description inadequately addresses the mismatch between the listed actions (with parameters) and the empty input schema, creating confusion about actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with bullet points but is lengthy and contains redundant detail. The content is not concise given the inaccurate relationship to the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite listing many actions, the description lacks details on how to invoke them (no selector parameter), does not mention return values, and fails to explain the discrepancy with the input schema. Incomplete for a complex multi-action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage), yet the description details actions with required/optional parameters. This adds misleading information that contradicts the schema, providing no helpful meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists many market-wide data actions (e.g., market_tide, sector_etfs) but the input schema is empty, providing no way to select an action. This makes the tool's purpose unclear and potentially misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling uw_* tools. The description implies many capabilities but does not differentiate or advise on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies parameters (ticker, expiry, etc.) but the input schema declares no properties, creating a direct contradiction. Annotations indicate read-only and idempotent behavior, but the description fails to address this mismatch or other behavioral traits like rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose but becomes verbose with a long list of 30+ actions. Each line is informative, but the overall length could overwhelm an agent. Structure is clear but not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite covering many actions, the description omits the parameter structure (missing from schema), return format, usage examples, and authentication needs. For a complex tool with no output schema, this is insufficient.
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?
With zero parameters in the schema, baseline is 4 according to rules. The description adds rich parameter info for each action (e.g., ticker required, optional filters), but these are not formalized in the schema, reducing reliability. Overall, it adds value but is inconsistent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool accesses UnusualWhales stock data, but the input schema has no properties, contradicting the detailed parameter requirements listed for each action. This inconsistency undermines clarity, making it unclear what the agent should send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists many actions but provides no guidance on when to use this tool versus sibling tools like uw_options or uw_flow. No context on use cases or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, openWorldHint, and idempotentHint, which cover safety. The description adds no behavioral detail beyond action names, and contradicts the schema by implying parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but the contradiction with the schema undermines its value. Front-loading is acceptable but misleading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a schema with zero parameters, the description is incomplete. It does not explain how to specify the action (e.g., missing action parameter), leaving critical gaps.
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?
Input schema has zero parameters, but description says actions like holdings require 'name'. This contradicts the schema, adding misleading semantics. Schema coverage is 100% but description does not align.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it accesses institutional holdings and ownership data, and lists available actions. However, the input schema has no parameters, while the description implies required parameters for actions (e.g., name, ticker), creating confusion about how to invoke the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus sibling tools like uw_insider or uw_stock. The list of actions lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, which is consistent with 'access' and 'get'. However, the description lists actions that would require parameters (e.g., date, ticker) but the schema has no properties, creating a behavioral inconsistency that undermines trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a bullet list for actions, which is structured. However, the content is misleading due to the missing parameters, making it less efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without parameters or output schema, the description is incomplete. The three actions imply different input requirements, but none are defined, leaving the agent without enough information to use 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?
Schema coverage is 100% but the schema is empty. The description mentions actions that would typically need parameters but offers no way to pass them. This adds no value and confuses the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it accesses UnusualWhales earnings data and lists three actions (premarket, afterhours, ticker), which gives a general idea. However, the lack of parameters in the input schema contradicts the implied need for date or ticker inputs, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like uw_stock or uw_screener. There's no mention of prerequisites or context for each action, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, idempotentHint, but the description adds no extra behavioral context; worse, it mentions optional filters not present in the schema, contradicting the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short description, but the action list is front-loaded; however, it is incomplete and misleading, reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters in schema and no output schema, the description should specify the actual filtering mechanism; instead it misrepresents the input, leaving the agent confused.
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 has zero parameters, but the description lists optional filters (ticker, sources, etc.) that are not in the schema, creating a contradiction; no value added.
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 accesses UnusualWhales news headlines, with a specific verb 'Access' and resource 'news headlines', distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings like uw_market or uw_stock; the description does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, openWorldHint, and idempotentHint, which align with the description's 'get' and 'show' language. However, the description claims parameters exist (e.g., month, ticker) while the schema has none, creating confusion about the tool's actual behavior.
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 well-organized with clear bullet points for actions. It is front-loaded with the overall purpose and then details each action. It could be slightly more concise, but the structure is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the complexity of multiple actions, the description provides reasonable context for each action. However, the empty input schema means the agent cannot correctly invoke the tool, leaving a critical gap in completeness.
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 zero parameters, yet the description describes required and optional parameters for actions. This adds meaning beyond the schema but is inconsistent and misleading, as the agent cannot use these parameters based on the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool accesses UnusualWhales seasonality data and lists four distinct actions (market, performers, monthly, year_month). It distinguishes itself from sibling tools like uw_alerts and uw_flow by focusing on seasonality patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit details for each action, including required parameters (e.g., month for performers) and optional filters. However, it lacks guidance on when to use this tool versus others, and the mismatch with the empty input schema undermines usability.
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, openWorldHint, idempotentHint. Description adds no behavioral beyond listing actions. No additional context on data freshness, rate limits, or authorization.
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?
Description is short with clear list. Slightly inconsistent punctuation in bullet points (colons and parentheses), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with explicit actions, description is adequate. However, missing output schema and lack of parameters in schema leave ambiguity on how to invoke actions. The mention of a required parameter without schema support is a 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?
Input schema has zero parameters, but description mentions 'congress_trader' requires a name. This contradicts schema and could mislead agents. Schema coverage is 100% (no params), so description should not introduce undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states purpose: access congress trading data. Lists three actions. However, lacks explicit differentiation from sibling tools like uw_politicians, relying on name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lists actions but does not provide context for choosing this tool over other uw_ tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'ticker required' for all actions, but the input schema has zero parameters, creating a direct contradiction. Additionally, while annotations indicate read-only behavior, the description does not disclose the return format or any side effects. This is severely misleading.
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 uses a clear bullet-list structure to enumerate actions, making it easy to scan. The first sentence is somewhat generic, but overall it is efficient with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and multiple actions, the description fails to explain what each action returns or provide any example output. This leaves the agent with insufficient context to understand the response format, especially for an openWorldHint tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 coverage), yet the description states 'ticker required' without it appearing in the schema. This misleads the agent into thinking a parameter exists when it does not. For zero-parameter tools, the baseline is 4, but the false claim warrants a 1.
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 accesses UnusualWhales ETF data and lists specific actions (info, holdings, exposure, etc.), differentiating it from sibling tools that cover other data categories like alerts, congress, darkpool, etc.
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 by listing available actions, making it obvious when to use this tool (for ETF-related queries). However, it does not explicitly state when not to use it or mention alternatives, though the sibling list implies alternatives for other data types.
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, idempotentHint, and openWorldHint. Description adds the available actions but does not disclose details like authentication, rate limits, or whether filters are optional. Minimal added value beyond annotations.
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?
Description is concise with a clear list of actions. However, it could be more compact by removing redundancy. Front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description does not explain return values or data format. Given the complexity of screening results, this omission leaves agents uncertain about what to expect.
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?
Input schema has zero properties, yet description mentions 'various filters' for each action, implying parameters exist. This contradiction misleads about the tool's interface. The description fails to clarify the discrepancy.
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 clearly states it accesses UnusualWhales screeners for stocks, options, and analysts, listing three specific actions. This differentiates it from sibling tools like uw_stock or uw_options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Sibling tools like uw_stock or uw_options may overlap, and the description does not clarify the distinction.
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, openWorldHint, and idempotentHint, so the tool's safety profile is clear. The description adds behavioral context by detailing the four actions and their parameter requirements. It does not disclose any additional side effects or limitations beyond what annotations imply.
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 organized with a bullet-type list for actions, making it scannable. It is reasonably concise, though the first sentence could be more direct. The front-loading is good, with the high-level purpose first, then details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (four distinct actions) and the absence of an output schema, the description adequately covers the actions and required parameters. However, it lacks information on output format, error handling, and prerequisites. The empty input schema is a significant gap that the description cannot fully compensate for.
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 is empty, but the description implies required parameters (ticker_symbol, sector, ticker) for specific actions. While the description adds semantics not present in the schema, the mismatch between description and schema creates confusion. This severely undermines the tool's usability for an AI agent.
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 provides access to UnusualWhales insider trading data including transactions and flow. The verb 'access' and resource 'insider trading data' are specific. However, it does not differentiate from sibling tools like uw_flow or uw_stock, which may also provide similar data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists available actions and specifies required parameters for each (e.g., ticker_symbol for transactions, sector for sector_flow). It provides some usage context but no guidance on when to choose this tool over siblings or when not to use it. Alternatives are not mentioned.
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, openWorldHint, and idempotentHint. The description ('Access') aligns with these and adds no new behavioral context. No annotation contradiction.
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 short and front-loaded with the purpose, followed by a concise bullet list. Every sentence is meaningful, though the bullets could be integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at return structure. It only lists actions without describing what is returned (e.g., triggered alerts vs. configurations). A bit incomplete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the input schema, so the description need not explain any. The actions list provides context for what the tool does without requiring parameters.
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 access to user alerts and configurations, and lists two specific actions. It distinguishes itself from siblings which cover other financial data, but could be more specific about the resource (e.g., 'retrieve' instead of 'access').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the sibling tools – all other tools cover different domains, so this is clearly for alerts. However, no explicit guidance on when to use it vs. alternatives, or prerequisites.
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 readOnly, openWorld, and idempotent hints. The description adds value by disclosing the multiple action types (data, ftds, etc.) and that each requires a ticker, which is behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with a clear front-loaded purpose and bulleted actions, but each action repeats 'ticker required' unnecessarily. It is well-structured but could be more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (no parameters, no output schema), the description fails to explain how to provide the required ticker, which is critical for using the tool. This omission makes the description incomplete for an AI 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?
Schema coverage is 100% (no parameters), so baseline is 3. The description adds meaning by listing actions and stating ticker is required, but there is a mismatch: the schema lacks a ticker parameter. This confusion reduces the helpfulness of the parameter semantics.
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 provides UnusualWhales short selling data and lists specific actions (data, ftds, etc.), distinguishing it from sibling tools focused on other data types. However, it fails to explain how to specify the required ticker since the input schema has no parameters, creating ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for short selling data through its verb and listed actions, but provides no explicit guidance on when to use this tool versus alternatives (e.g., uw_options, uw_darkpool) or any exclusions, leaving the agent to infer context.
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 indicate readOnly, openWorld, and idempotent behavior. The description adds context about actions and filters but no additional behavioral details beyond what annotations provide.
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?
Description is very concise, front-loaded with the purpose, and structured with bullet-style actions. Every sentence is informative without 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 tool with no input parameters and rich annotations, the description adequately covers purpose and available actions. It does not explain return values, but given simplicity, completeness is high.
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?
Input schema has no parameters, so schema coverage is 100%. Description mentions filtering options but adds no specific parameter details since none exist. 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 clearly states the tool accesses UnusualWhales darkpool trade data and lists specific actions (recent, ticker). The name and context distinguish it from sibling tools which cover other data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not explain trade-offs or suggest when to choose uw_darkpool over other uw_* 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 already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context about the types of flow data and filtering options, which helps the agent understand what 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately structured with actions listed and notes on groups and filtering. However, it is somewhat verbose and could be more concise with clearer front-loading of essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should clarify the return format of each action. It describes what each action retrieves but not the structure. For a data retrieval tool, this is adequate but not 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 input schema has zero parameters, yet the description mentions several required parameters (e.g., date, flow_group, expiry) for specific actions. This creates confusion and inconsistency, undermining the usefulness of the description for parameter understanding.
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 accessing UnusualWhales options flow data and enumerates specific actions (e.g., flow_alerts, full_tape). This distinguishes it from sibling tools focusing on other data types like alerts, congress, or darkpool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description lists the available actions, it does not provide explicit guidance on when to use this tool over siblings or when to avoid it. Usage is implied by the mention of options flow data, but no exclusions or alternatives are given.
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, openWorldHint, and idempotentHint as true, indicating a safe, read-only operation. The description adds value by detailing multiple actions and their parameter requirements, which goes beyond what annotations provide. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and then uses a bulleted list of actions. It is concise given the amount of information, but could be more structured (e.g., markdown sections). No verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with multiple actions and no output schema. The description does not explain how to specify the action (e.g., hidden action field) or describe return values. Annotation coverage is good, but for a tool with empty schema and many actions, the description leaves 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, but the description describes parameters for each action (e.g., politician_id required for portfolio). This mismatch creates confusion: an agent relying on the schema would see no parameters, yet the description requires them. The description adds meaning but conflict with schema reduces usability.
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 'Access UnusualWhales politician portfolio and trading data' and lists specific actions (people, portfolio, recent_trades, holders, disclosures). This distinguishes it from siblings like uw_alerts or uw_congress, each focusing on different domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description describes each action's purpose (e.g., 'Get recent politician trades') but does not explicitly state when to use this tool over alternatives or provide exclusions. The sibling list offers context, but within the description, usage guidance is implicit rather than direct.
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, openWorldHint, and idempotentHint as true. Description adds action-specific parameter dependencies but no behavioral traits beyond what annotations imply.
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?
Description is well-structured with bullet points for each action, efficient in length, and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers actions and parameters adequately, but lacks description of return values or output format, which is notable given no output schema.
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?
Input schema is empty (0 parameters), yet description states 'id' is required and lists optional parameters for each action. This contradiction between description and schema reduces clarity. Schema coverage is 100% but only because schema has no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it accesses UnusualWhales option contract data and lists four specific actions (flow, historic, intraday, volume_profile), differentiating it from sibling tools that focus on other data types like alerts, congress, or darkpool.
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 detailed breakdown of each action with required and optional parameters, but does not explicitly state when to use this tool versus alternatives like uw_flow or uw_stock.
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:

[![unusual-whales-mcp MCP server](https://glama.ai/mcp/servers/erikmaday/unusual-whales-mcp/badges/card.svg)](https://glama.ai/mcp/servers/erikmaday/unusual-whales-mcp)

Score Badge

Copy to your README.md:

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

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