WhatsHot

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct concern: source discovery, schema introspection, live fetching, history querying, searching, trend analysis, and storage stats. The main potential confusion is between query_history and search_history, but the descriptions make clear that querying returns persisted items with pagination while searching targets content and returns attributable evidence, which differentiates them sufficiently.
Naming Consistency4/5
Names mostly follow a verb_noun pattern with clear action prefixes (list_, get_, fetch_, query_, search_, get_). There's a minor deviation with get_source_schema vs fetch_current where 'fetch' and 'get' use different verbs for similar acquisition actions, but this is arguably intentional given that fetch_current accesses the network while get_source_schema is local.
Tool Count5/5
Seven tools is within the ideal 3-15 range and each tool appears to earn its place by covering a distinct dimension of the domain: discovery, introspection, live fetch, history retrieval, search, analytics, and storage management. No redundant or filler tools.
Completeness4/5
The surface covers the full lifecycle: source discovery, schema understanding, live fetching, persistence querying, search, trend analytics, and storage management. Minor gaps exist—such as the absence of explicit history write/capture control (though fetch_current implies an upstream capture mechanism) and possibly pagination/sampling controls for trend series—but no obvious dead ends that would cause agent failures.
Average 3.2/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 78 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds 'persisted historical items' and 'cursor pagination' context, which is useful. However, it does not describe the return format, how cursors are obtained (e.g., from previous responses), or the meaning of the output. With annotations covering the safety profile, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and avoids verbose filler. However, it is brief to the point of under-specification rather than tight-but-complete, warranting a minor deduction.
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 7 parameters with 0% schema description coverage, the tool needs substantial documentation to be usable. The description fails to explain parameter semantics, filtering behavior, cursor usage mechanics, or how this differs from sibling search_history. Despite having an output schema, the 0% parameter coverage and sibling ambiguity leave significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden for parameter meaning, but it adds nothing about the 7 parameters. The mention of 'kind' and 'cursor' exists in the schema but the description never explains their purpose, valid values, or interactions. The since/until date filters and board_key are entirely undocumented.
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 'Query persisted historical items with cursor pagination.' This gives a clear verb+resource (query historical items) and mentions pagination via cursor. However, it does not specify what 'historical items' are or how it differs from sibling tool search_history, which sounds like it does something similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus search_history, fetch_current, or other siblings. The presence of sibling search_history strongly suggests a similar purpose that should be disambiguated, but no distinction is provided. Context around kind/site/board_key filtering is entirely absent.
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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context—'rank and hot-value trends' hints at the return shape but not at time-bucket granularity or how since/until defaults behave. There's no contradiction, but the description doesn't substantially enrich 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the core purpose. It's appropriately concise with no filler. However, it's so terse that it sacrifices informative content—a slightly longer description that covers time-range parameters would be more valuable without risking verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters with 0% schema coverage, but an output schema exists, which somewhat offsets the need to explain return values. For a trend-series tool with time-range and bucketing parameters, the description omits critical information about how since/until/bucket shape the data. The single-sentence coverage of 'rank and hot-value trends for one historical item' is plausible but leaves the time-domain semantics unexplained, making this marginally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the full burden of parameter meaning. It mentions 'rank and hot-value trends' and a single historical item (implying site, board_key, item_id), but it fails to explain the time-related parameters (site, since, until, bucket). The 'bucket' enum ('10m','1h','6h','1d') is structural but its effect on the returned series isn't described. The description only loosely covers the three required params and none of the optional ones.
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 a specific verb+resource ('Get rank and hot-value trends') for a single historical item. It's reasonably clear, but 'for one historical item' is vague—it doesn't clarify whether 'item' refers to a product, a search term, or another entity. The description doesn't explicitly differentiate from siblings like query_history or search_history, though 'trends for one item' hints at a narrow single-item scope.
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 vs alternatives. Siblings include query_history and search_history, which likely relate to the same data domain, yet no distinguishing phrase or exclusion is given. The description implies a use case (viewing historical trend series) but provides no context on prerequisites, such as needing a board_key and item_id obtained from another tool first.
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, idempotentHint=true, and destructiveHint=false, so the safe read nature is established. The description adds value by noting the output contract — 'attributable evidence, not free-form summaries' — which tells the agent what kind of result to expect and that it should not treat results as synthesized summaries. This is meaningful behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short line, front-loaded with the core action and ends with a valuable contrastive note. Every word earns its place. It's appropriately concise for a search tool, though it could be slightly more informative without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and 7 parameters with rich structural metadata (date-time formats, cursor for pagination, nullable fields). The description covers the search-scope and output-nature aspects but remains thin given the tool's complexity — pagination semantics (cursor), date filtering (since/until), and site/board filtering are entirely unexplained. The output schema helps but the description still under-serves the filtering and pagination dimensions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the 7 parameters. It fails to do so — none of keyword, site, limit, since, until, cursor, or board_key are explained in the description. The only hint is that the tool searches across 'titles, descriptions, and newsflash content' and that keyword is required. With 7 parameters at 0% coverage, this is a notable gap.
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 the verb+resource ('Search persisted titles, descriptions, and newsflash content') and adds the distinctive 'attributable evidence, not free-form summaries' qualifier, which differentiates search_history from query_history. However, it's relatively terse and doesn't fully clarify how this differs from the closely named sibling 'query_history' — the differentiation is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. Given siblings like 'query_history' and 'fetch_current', there is no statement about what scenarios call for search_history specifically, nor exclusions. The agent receives no help choosing among the closely related search/query 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, destructiveHint=false, and idempotentHint=true, so the safe read-only profile is established. The description adds that it reveals boards and accepted parameters but doesn't disclose whether the site must be registered/valid first or what happens for an unknown site identifier.
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, compact sentence that front-loads the core function. It's efficient with no wasted words, though it could arguably add a brief note about the site parameter for no length penalty.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, which relieves the description of explaining return values. With one required parameter, annotations, and an output schema, the description is borderline adequate. The main gap is the undocumented 'site' parameter meaning, which leaves the description slightly incomplete for a tool that exists to explain schemas.
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 schema description coverage at 0% and 1 required parameter, the description provides zero guidance on what the 'site' parameter should contain (e.g., an ID, a name, a label). The description mentions 'a source' but doesn't clarify how 'site' maps to a source or where to obtain valid site values.
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 uses a specific verb (Describe) with a clear resource scope (one source, its boards, and accepted parameters). It distinguishes itself somewhat from sibling list_sources by focusing on a single source's detailed schema rather than enumerating sources, though it doesn't explicitly name the sibling or contrast with it.
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 conveys this is for exploring a specific source's structure (boards and parameters), which implies it should be used when you need details about one source rather than listing all sources. However, it doesn't explicitly state when to use this vs list_sources, or mention the required site parameter 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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond annotations: it explicitly states the tool may access the upstream website (external network dependency) and never persists a history capture (persistence behavior). This is valuable transparency about side effects and network behavior not covered by 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence states the action; the second adds the key behavioral caveat about upstream access and non-persistence. Every word earns its place, though it could name alternatives to siblings for a more complete picture.
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?
With an output schema present, the description doesn't need to explain return values. However, 4 parameters with 0% schema description coverage means parameter semantics are entirely undocumented. The tool touches an external website with network implications, and while the constraints are clear (read-only, non-persisting), the parameter meanings and usage patterns are not explained. Adequate for a fetch operation but leaves parameter understanding to inference.
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 0%, so the description does not explain any parameters. The description contributes no parameter-level detail. However, there is a rich output schema present, which reduces the burden on parameter documentation somewhat. The schema itself provides names (site, limit, params, path_type) but no semantic meaning, leaving the agent to guess at what 'path_type' or 'params' control.
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 a clear verb+resource: 'Fetch a current board.' It distinguishes from sibling tools by emphasizing 'current' (versus history-oriented tools like query_history, search_history, get_trend_series). However, 'board' is a domain-specific term not otherwise defined, and it doesn't explicitly name alternatives. The purpose is clear but somewhat generic without deeper context about what a 'board' represents.
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 context (fetching current data rather than history) by contrasting with the upstream website, which helps distinguish from the history-based siblings. It notes 'may access the upstream website but never persists a history capture,' which clarifies it's a live-fetch operation. However, it doesn't provide explicit when-to-use vs when-not-to-use guidance or name specific alternative 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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by annotations. The description adds the 'local history storage' scope context, which is useful. However, it doesn't clarify what 'freshness' measures or how it relates to source 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?
A single, efficient sentence with zero wasted words. Perfectly sized for a zero-parameter read-only stats 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?
Has an output schema, so return values are documented elsewhere. Zero parameters mean no param ambiguity. The tool is simple enough that a one-sentence description with rich annotations (read-only, idempotent, non-destructive) is nearly complete. Slight deduction for not hinting at what 'freshness' means or when it's useful.
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, and with no params, the baseline is 4. The description appropriately explains what is returned (storage counts and freshness) without any parameter burden to carry. Nothing is missing here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Return local history storage counts and freshness'), clearly indicating what data is retrieved. It doesn't explicitly differentiate itself from siblings like list_sources or get_source_schema, but the subject matter (storage stats) is distinct enough to be understood.
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?
There is no guidance on when to use this tool versus alternatives. No mention of what 'storage counts' refers to or when checking storage vs querying history would be appropriate. Sibling tools like list_sources and query_history exist, but no comparison is offered.
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 description adds 'without network access' as behavioral context beyond the annotations, which is genuinely useful. But the annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description contributes the offline/local nature of the operation but little else.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the purpose and the key behavioral constraint (no network access). Zero wasted words; every element 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?
This is a simple zero-parameter tool that lists sources. Given the rich annotations (read-only, idempotent, non-destructive), an output schema exists for return values, and there are no parameters to document, the description covers what's needed. It could perhaps mention what 'WhatsHot sources' consists of or how many there might be, but the description is adequate for a simple list operation.
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 schema provides no parameter information, so the baseline of 4 applies. The description correctly indicates there's nothing to configure - it's a simple listing operation. No parameter documentation burden exists.
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 has a clear verb+resource ('List all discoverable WhatsHot sources'). It distinguishes from siblings by explicitly noting 'without network access', which separates it from tools like fetch_current or get_trend_series that likely make network requests. It doesn't strongly differentiate from get_source_schema but the scope is clear.
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 phrase 'without network access' implies this is a safe, offline listing operation, which provides some usage context. However, there's no explicit statement of when to use this vs. alternatives like get_source_schema, nor any exclusions or prerequisites mentioned. It's implied rather than explicit.
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:

[![WhatsHot MCP server](https://glama.ai/mcp/servers/alisen39/WhatsHot/badges/card.svg)](https://glama.ai/mcp/servers/alisen39/WhatsHot)

Score Badge

Copy to your README.md:

[![WhatsHot MCP server](https://glama.ai/mcp/servers/alisen39/WhatsHot/badges/score.svg)](https://glama.ai/mcp/servers/alisen39/WhatsHot)

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/alisen39/WhatsHot'

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