Skip to main content
Glama
harpd-dev

harpd-mcp

Official
by harpd-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Search Harpd AI products

search_products
Read-only

Search Harpd's open catalog of 1,122 AI products by query, category, or verification state. Returns ranked products with provenance and promotional rankPoints clearly distinguished from editorial quality.

Instructions

Search the Harpd open product catalog (1,122 AI products) by free text, category and verification state. Returns each product with its board position (rank) and its rankPoints. IMPORTANT: rankPoints are promotional placement bought with Credits on Harpd Rank, NOT an editorial quality score. Ordering by rankPoints orders by promotional placement, not by merit. Every record carries full provenance (source, dataset path, updatedAt, license, attribution, evidence).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoOrdering. "rank" = board position ascending. "rankPoints" = descending by promotional placement bought with Credits, which is NOT a quality ordering. "relevance" only applies when `query` is set.relevance
limitNoMaximum number of records to return (1-200, default 20).
queryNoFree-text query matched against product name, slug, description, product type, website and category name.
offsetNoNumber of records to skip before the page starts. Must be >= 0.
categoryNoExact Harpd category slug, e.g. "developer", "agents", "ai-media".
verifiedNoFilter by Harpd verification state.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

It discloses the non-obvious behavior that rankPoints are paid promotional placement, not editorial quality, which prevents a serious misinterpretation. This adds meaningful context beyond the readOnlyHint/openWorldHint annotations, though it does not address rate limits or exact response formatting.

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-structured and front-loaded with the main action and key output. The rankPoints warning is valuable but partially redundant with the sort parameter description, making it slightly longer than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description covers the important operational context: catalog size, available filters, ordering semantics, returned fields (rank, rankPoints), and full provenance. This is enough for an agent to call and interpret results correctly.

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 the schema already documents sort, limit, query, offset, category, and verified clearly. The description mostly repeats the rankPoints warning and lists search dimensions, adding little meaning beyond what the schema provides.

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 names a specific verb ('Search'), a specific resource ('the Harpd open product catalog'), and the main search dimensions ('free text, category and verification state'). It also states the return value includes rank and rankPoints, making it distinct from the sibling get_* tools.

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 makes the use case clear: search a broad catalog by free text, category, or verification state, rather than fetching a single product. It does not explicitly say when not to use it or name alternatives such as get_product or get_rankings, so it falls short of full routing guidance.

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

Deploy Server

Other Tools