Skip to main content
Glama
jaipandya

product-hunt-mcp

by jaipandya

get_post_comments

Retrieve comments for Product Hunt posts using ID or slug, with sorting and pagination options to analyze user feedback.

Instructions

    Retrieve comments for a specific post by post ID or slug, with optional sorting and pagination.

    Parameters:
    - post_id (str, optional): The post's unique ID.
    - slug (str, optional): The post's slug.
    - order (str, optional): Sorting order. Valid values: NEWEST (default), OLDEST, VOTES.
    - count (int, optional): Number of comments to return (default: 10, max: 20).
    - after (str, optional): Pagination cursor for next page.

    Returns:
    - success (bool)
    - data (dict): If successful, contains:
        - comments (list): List of comment objects (id, content, etc.)
        - pagination (dict): { end_cursor, has_next_page }
    - error (dict, optional)
    - rate_limits (dict)

    Notes:
    - Returns an error if the post is not found.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
post_idNo
slugNo
orderNo
countNo
afterNo

Implementation Reference

  • Handler function that executes the get_post_comments tool logic, fetching comments via GraphQL with pagination and validation.
    @require_token
    @handle_errors
    @validate_with_schema(POST_COMMENTS_SCHEMA)
    def get_post_comments(
        post_id: str = None,
        slug: str = None,
        order: str = None,
        count: int = None,
        after: str = None,
    ) -> Dict[str, Any]:
        """
        Retrieve comments for a specific post by post ID or slug, with optional sorting and pagination.
    
        Parameters:
        - post_id (str, optional): The post's unique ID.
        - slug (str, optional): The post's slug.
        - order (str, optional): Sorting order. Valid values: NEWEST (default), OLDEST, VOTES.
        - count (int, optional): Number of comments to return (default: 10, max: 20).
        - after (str, optional): Pagination cursor for next page.
    
        Returns:
        - success (bool)
        - data (dict): If successful, contains:
            - comments (list): List of comment objects (id, content, etc.)
            - pagination (dict): { end_cursor, has_next_page }
        - error (dict, optional)
        - rate_limits (dict)
    
        Notes:
        - Returns an error if the post is not found.
        """
        params = {
            k: v
            for k, v in {
                "post_id": post_id,
                "slug": slug,
                "order": order,
                "count": count,
                "after": after,
            }.items()
            if v is not None
        }
        logger.info("comments.get_post_comments called", extra=params)
    
        variables = {}
    
        # Prepare variables
        if post_id:
            variables["id"] = post_id
        if slug:
            variables["slug"] = slug
    
        # Apply pagination defaults
        pagination_vars = apply_pagination_defaults(count, after)
        variables.update(pagination_vars)
    
        # Apply order
        if order:
            variables["order"] = order
    
        result, rate_limits, error = execute_graphql_query(COMMENTS_QUERY, variables)
    
        if error:
            return format_response(False, error=error, rate_limits=rate_limits)
    
        # Check if post exists based on comments data
        post_exists = check_data_exists(result["data"], "post")
    
        if not post_exists:
            id_or_slug = post_id or slug
            return format_response(
                False,
                error={
                    "code": "NOT_FOUND",
                    "message": f"Post with ID/slug '{id_or_slug}' not found",
                },
                rate_limits=rate_limits,
            )
    
        # Extract comments
        comments_data = result["data"]["post"]["comments"]
    
        return format_response(
            True,
            data={
                "comments": comments_data["edges"],
                "pagination": extract_pagination(comments_data["pageInfo"]),
            },
            rate_limits=rate_limits,
        )
  • Input validation schema defining parameters and constraints for the get_post_comments tool.
    POST_COMMENTS_SCHEMA = {
        "requires_one_of": [["post_id", "slug"]],
        "post_id": {"type": str},
        "slug": {"type": str},
        "order": {"type": str, "valid_values": ["NEWEST", "OLDEST", "TOP"]},
        "count": {"type": int, "min_value": 1, "max_value": 20},
        "after": {"type": str},
    }
  • Registration point where register_comment_tools is called on the MCP server instance to register the get_post_comments tool among others.
    register_comment_tools(mcp)
  • The register_comment_tools function that defines and registers both get_comment and get_post_comments tools using @mcp.tool() decorators.
    def register_comment_tools(mcp):
        """Register comment-related tools with the MCP server."""
    
        @mcp.tool()
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a read operation (implied by 'retrieve'), includes error handling ('Returns an error if the post is not found'), mentions rate limits in the return structure, and details pagination behavior. However, it doesn't specify authentication requirements or potential side effects, leaving some gaps for a tool with no annotation support.

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 well-structured and front-loaded with the core purpose. Each section (Parameters, Returns, Notes) adds essential information without redundancy. Sentences are concise and directly relevant, such as specifying sorting options and error conditions. No wasted words or unnecessary elaboration.

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?

For a tool with no annotations and no output schema, the description does an excellent job covering purpose, parameters, return structure, and error handling. It explains the return format in detail (success, data with comments and pagination, error, rate_limits), which compensates for the lack of output schema. The only minor gap is the absence of explicit authentication or permission requirements, which could be relevant for API tools.

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

Parameters5/5

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

Given 0% schema description coverage, the description fully compensates by providing comprehensive parameter details. It explains all 5 parameters, including their types, optional status, valid values for 'order', defaults for 'order' and 'count', and the purpose of 'after' for pagination. This adds significant value beyond the bare schema, making parameter usage clear and actionable.

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 clearly states the specific action ('Retrieve comments for a specific post') and identifies the resource ('post by post ID or slug'). It distinguishes this tool from siblings like get_post_details (which retrieves post metadata) and get_comment (which retrieves a single comment). The verb 'retrieve' is precise and the scope is well-defined.

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 through the parameter descriptions (e.g., 'post ID or slug') but doesn't explicitly state when to use this tool versus alternatives like get_post_details or get_comment. No guidance is provided on prerequisites, such as whether authentication is required or what happens if both post_id and slug are provided. The usage is clear from context but not explicitly articulated.

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

Install Server

Other Tools

Latest Blog Posts

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/jaipandya/producthunt-mcp-server'

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