Skip to main content
Glama
xiaobenyang-com

HackerNews-Search

get-user

get-user

Retrieve HackerNews user profiles to check karma scores, read bios, verify account creation dates, and confirm user existence before searching their content.

Instructions

Retrieve public profile information for a HackerNews user.

Returns user profile including karma, bio, and account creation date. Use this to:

  • Check user reputation (karma score)

  • Read user bio and about information

  • See when account was created

  • Verify user existence before searching their content

Features:

  • Username (case-sensitive)

  • Karma score (total upvotes received)

  • About/bio text (may contain HTML)

  • Account creation date (Unix timestamp)

Examples:

  • Get famous user: { "username": "pg" }

  • Check moderator: { "username": "dang" }

  • Verify author: { "username": "tptacek" }

Username validation:

  • Alphanumeric characters and underscores only

  • Case-sensitive

  • Must exist on HackerNews

Returns error if user doesn't exist or username format is invalid.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
usernameYes

Implementation Reference

  • src/mcp.ts:90-132 (registration)
    Dynamically fetches tool list from remote API and registers each tool, including "get-user" if present in the list for mcpID 1777316659382275, using parsed Zod schemas.
    for (const apiDesc of apiDescList) {
        let inputSchema = JSON.parse(apiDesc.inputSchema);
        const zodDict: Record<string, z.ZodTypeAny> = {};
    
        Object.entries(inputSchema.properties).forEach(([name, propConfig]) => {
            let zodType;
            let pt = (propConfig as { type: string }).type;
            switch (pt) {
                case 'string':
                    zodType = z.string();
                    break;
                case 'number':
                    zodType = z.number();
                    break;
                case 'boolean':
                    zodType = z.boolean();
                    break;
                case 'integer':
                    zodType = z.int32();
                    break;
                case 'array':
                    zodType = z.array(z.any());
                    break;
                case 'object':
                    zodType = z.object(z.any());
                    break;
                default:
                    zodType = z.any();
            }
    
            if (inputSchema.required?.includes(name)) {
                zodDict[name] = zodType;
            } else {
                zodDict[name] = zodType.optional();
            }
        });
    
    
        addToolXiaoBenYangApi(
            apiDesc.name,
            apiDesc.description ? apiDesc.description : apiDesc.name,
            zodDict);
    }
  • Core handler implementation that executes all tools, including "get-user", by proxying the call with toolName to the remote https://mcp.xiaobenyang.com/api endpoint.
    const calcXiaoBenYangApi = async function (fullArgs: Record<string, any>) {
        // 发起 POST 请求
        let response = await fetch('https://mcp.xiaobenyang.com/api', {
            method: 'POST',
            headers: {
                'XBY-APIKEY': apiKey,
                'func': fullArgs.toolName,
                'mcpid': mcpID
            },
            body: new URLSearchParams(fullArgs)
        });
        const apiResult = await response.text();
    
        return {
            content: [
                {
                    type: "text",
                    text: apiResult // 将字符串结果放入 content 中
                }
            ]
        } as { [x: string]: unknown; content: [{ type: "text"; text: string }] };
    };
  • Helper function that registers each dynamic tool on the MCP server, providing schema and proxy handler.
    const addToolXiaoBenYangApi = function (
        name: string,
        desc: string,
        params: Record<string, ZodType>
    ) {
        server.registerTool(
            name,
            {
                title: name,
                description: desc,
                inputSchema: params,
            }
            ,
            async (args: Record<string, any>) => handleXiaoBenYangApi(args, name)
        )
    };
  • Parses the remote tool's JSON schema into a Zod inputSchema dictionary used for registration.
    Object.entries(inputSchema.properties).forEach(([name, propConfig]) => {
        let zodType;
        let pt = (propConfig as { type: string }).type;
        switch (pt) {
            case 'string':
                zodType = z.string();
                break;
            case 'number':
                zodType = z.number();
                break;
            case 'boolean':
                zodType = z.boolean();
                break;
            case 'integer':
                zodType = z.int32();
                break;
            case 'array':
                zodType = z.array(z.any());
                break;
            case 'object':
                zodType = z.object(z.any());
                break;
            default:
                zodType = z.any();
        }
    
        if (inputSchema.required?.includes(name)) {
            zodDict[name] = zodType;
        } else {
            zodDict[name] = zodType.optional();
        }
    });
  • Intermediate handler that validates and prepares arguments before calling the core proxy function.
    const handleXiaoBenYangApi = async (args: Record<string, any>, toolName: string) => {
        // 校验aid是否存在
        if (toolName === undefined || toolName === null) {
            throw new Error("缺少必要参数 'aid'");
        }
        // 合并参数
        const fullArgs = {...args, toolName: toolName};
        // 调用API
        return calcXiaoBenYangApi(fullArgs);
    };
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 and does well by disclosing key behavioral traits: it specifies that the username is case-sensitive, returns error conditions (user doesn't exist or invalid format), and describes the return format (karma, bio, creation date). However, it doesn't mention rate limits, authentication needs, or pagination, leaving some gaps for a tool with no annotation coverage.

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 appropriately sized and front-loaded with the core purpose, followed by organized sections (Returns, Use this to, Features, Examples, Username validation, Returns error). Some redundancy exists (e.g., 'Username' mentioned in multiple sections), but overall it's efficient with zero wasted sentences.

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?

Given the complexity (simple read operation), no annotations, no output schema, and 0% schema coverage, the description is quite complete: it covers purpose, usage, parameters, behavior, and error conditions. However, it lacks details on output structure (e.g., exact JSON format) and potential side effects like rate limits, which would be helpful for full completeness.

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?

The input schema has 0% description coverage for the single parameter 'username', but the description compensates fully by detailing username validation rules (alphanumeric/underscores, case-sensitive, must exist), providing examples of usage, and explaining its semantics in the 'Features' and 'Username validation' sections. This adds significant meaning beyond the bare schema.

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 public profile information') and resource ('for a HackerNews user'), distinguishing it from sibling tools like get-item or search-posts that handle posts rather than user profiles. The verb 'retrieve' is precise and the scope 'public profile information' 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage scenarios in a bulleted list (e.g., 'Check user reputation', 'Verify user existence before searching their content'), which clearly indicates when to use this tool. It also implicitly distinguishes it from siblings by focusing on user profiles rather than posts, though it doesn't explicitly name alternatives.

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/xiaobenyang-com/HackerNews-Search'

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