Grey Ridge Jobs MCP

search_hn_hiring

Search the current month's Hacker News “Ask HN: Who is hiring?” thread to find live job postings, parsed into structured fields and filterable by keyword or remote-only.

Instructions

Search the CURRENT month's Hacker News "Ask HN: Who is hiring?" thread for live job postings, normalized into the same unified schema as search_jobs (title, company, location, remote, employment_type, salary, url, source_platform). The monthly thread id is auto-discovered (it rotates on the 1st of every month) and each free-text post header is parsed into structured fields. Optionally filter by a keyword and/or remote-only. No company list needed — this is the whole thread. source_platform is "hn"; url is the apply link when present, else the HN permalink.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_hn_hiring"
  }
}

Input Schema

Name	Required	Description
`query`	No	Case-insensitive substring filter over title + company + snippet (e.g. "rust", "senior backend"). Omit for all posts.
`maxResults`	No	Cap postings returned (default 50, max 200).
`remoteOnly`	No	Keep only postings classified as remote. Default false.
`includeDescription`	No	Include the post body snippet as the description. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full load and does well: it discloses auto-discovery of the rotating monthly thread id, that free-text headers are parsed into fields, the source_platform value, and the url fallback to the HN permalink. It omits failure behavior (e.g., what happens before the thread is posted) and any rate/volume limits.

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-loaded with the resource and the return shape, then the discovery/parsing mechanics, then filters. Dense and largely waste-free, though the trailing sentences about source_platform and url could be trimmed given the field list already appears earlier.

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?

No output schema exists, so the description usefully enumerates the returned fields and the url semantics. For a 4-param, zero-required read tool it is complete enough, with only edge-case behavior (empty/unposted thread, pagination beyond maxResults cap) left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented with defaults and examples. The description adds only the high-level note that keyword and remote-only filters exist, which the schema already covers in more detail; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search the CURRENT month's HN "Ask HN: Who is hiring?" thread') plus scope ('live job postings, normalized into the same unified schema as search_jobs'). An agent can distinguish this from search_jobs and list_platforms without opening the schema.

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?

Explains when to prefer this source: 'No company list needed — this is the whole thread,' and signals it returns the same unified shape as search_jobs. It gives clear context but does not explicitly say when NOT to use it (e.g., past months or non-HN sources).

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

Deploy Server