Skip to main content
Glama
malkreide

hn-tech-signal-mcp

by malkreide

lobsters_hot

Read-onlyIdempotent

Fetch hot Lobste.rs stories with tag filters and result limits to surface curated tech signals. Returns JSON with titles, URLs, scores, comments, tags, submitters, and timestamps.

Instructions

Fetch the hottest stories from Lobste.rs, a curated tech community.

Lobste.rs is smaller and more technically focused than HackerNews. Invitation-only membership ensures higher signal-to-noise ratio.

Args: params (LobstersHotInput): - limit (int): Stories to return (1–25) - tag_filter (Optional[str]): Tag substring filter (e.g. 'ai', 'ml')

Returns: str: JSON with count, stories[]. Each story: title, url, score, comments, tags, submitter, submitted_at, lobsters_url.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
storiesYes
fetched_atYes
tag_filterYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.5.0
    • addedOutput schema / $defs
      Added value: +{
      +  "LobstersStory": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "comments": {
      +        "anyOf": [
      +          {
      +            "type": "integer"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ],
      +        "title": "Comments"
      +      },
      +      "lobsters_url": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ],
      +        "title": "Lobsters Url"
      +      },
      +      "score": {
      +        "anyOf": [
      +          {
      +            "type": "integer"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ],
      +        "title": "Score"
      +      },
      +      "submitted_at": {
      +        "title": "Submitted At",
      +        "type": "string"
      +      },
      +      "submitter": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ],
      +        "title": "Submitter"
      +      },
      +      "tags": {
      +        "anyOf": [
      +          {
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ],
      +        "title": "Tags"
      +      },
      +      "title": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ],
      +        "title": "Title"
      +      },
      +      "url": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ],
      +        "title": "Url"
      +      }
      +    },
      +    "required": [
      +      "title",
      +      "url",
      +      "score",
      +      "comments",
      +      "tags",
      +      "submitter",
      +      "submitted_at",
      +      "lobsters_url"
      +    ],
      +    "title": "LobstersStory",
      +    "type": "object"
      +  }
      +}
    • addedOutput schema / additionalProperties
      Added value: +false
    • addedOutput schema / properties / count
      Added value: +{
      +  "title": "Count",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / fetched_at
      Added value: +{
      +  "title": "Fetched At",
      +  "type": "string"
      +}
    • removedOutput schema / properties / result
      Removed value: -{
      -  "title": "Result",
      -  "type": "string"
      -}
    • addedOutput schema / properties / stories
      Added value: +{
      +  "items": {
      +    "$ref": "#/$defs/LobstersStory"
      +  },
      +  "title": "Stories",
      +  "type": "array"
      +}
    • addedOutput schema / properties / tag_filter
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "title": "Tag Filter"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "result"
      -]New value: +[
      +  "tag_filter",
      +  "fetched_at",
      +  "count",
      +  "stories"
      +]
    • changedOutput schema / title
      Previous value: -"lobsters_hotOutput"New value: +"LobstersHotOutput"
  2. First observedv0.2.4

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the source's curation model and a return-shape sketch, but stays silent on pagination, rate limits, or freshness/recency behavior of 'hot' stories.

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?

Front-loads purpose, then compact Args/Returns blocks. The Lobste.rs-vs-HackerNews flavor earns its place by aiding tool selection, though 'higher signal-to-noise ratio' is closer to marketing than operational guidance.

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?

An output schema exists, annotations cover the safety profile, and the description still summarizes the return payload (count, story fields). For a single-parameter read tool this is nearly complete; only pagination/freshness semantics are missing.

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 reported schema coverage at 0%, the description carries the burden and does document both fields: limit as a 1–25 range and tag_filter as a tag substring filter with examples. It adds the 'substring' nuance, though it doesn't clarify whether multiple tags are accepted or how the filter interacts with the hot ranking.

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?

States a specific verb (Fetch) and resource (hottest stories) with an explicit source (Lobste.rs), then contrasts it against HackerNews, which maps directly to the sibling hn_top_stories. An agent can choose between the two without opening either schema.

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 comparative framing ('smaller and more technically focused', 'invitation-only … higher signal-to-noise') implies when this source is preferable, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage must be inferred from the source characterization.

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