Skip to main content
Glama
alialtunar

hn-hiring-trends-mcp

by alialtunar

rising_skills

Read-onlyIdempotent

Compare recent and earlier Hacker News hiring posts to identify which skills gained or lost demand, with configurable months and top results.

Instructions

Which skills gained or lost demand: compares the share of posts mentioning ~70 known skills in the recent half of the period with the earlier half.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNo
monthsNo
response_formatNo'markdown' (default) or 'json'.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely useful behavioral context beyond them: the analysis compares the recent half of the period against the earlier half and draws on ~70 known skills. It does not disclose output shape or damping/limitations, but the method disclosure is the substantive part.

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?

A single tight sentence, front-loaded with the analytic question and then the comparison method. No filler, though the '~70 known skills' detail is somewhat optional.

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?

An output schema exists, so return-value explanation is not required, and the comparison methodology is stated. However, with two of three parameters undocumented anywhere, an agent still cannot confidently size 'top' or interpret 'months' from the definition alone.

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 only 33% -- 'top' and 'months' carry no descriptions in the schema. The description's reference to 'the period' loosely ties to 'months' but never explains what 'top' caps or how the two halves are derived. With low coverage, the description should compensate and does not.

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 gives a specific analytical verb and resource: it identifies which skills gained or lost demand by comparing mention shares between two halves of a period. That is concrete and distinguishable from a level-check like skill_demand, though it never names a sibling or explicitly contrasts itself with them.

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 framing ('gained or lost demand') -- an agent can infer this is the trend/change tool rather than a static demand tool. But there is no explicit statement of when to prefer this over skill_demand or the hiring_* siblings, and no exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.