Allows looking up public GitHub user records by username using the GitHub public API.
A read-only MCP server generated from a verified FirstCall recipe. It exposes one tool, github_user_lookup, which looks up public user records by username using the GitHub public API.
This repository is built from FirstCall, a local-first verified API recipe workbench for turning request sources into redacted agent-ready API tool packages.
Generated TypeScript MCP server artifact from FirstCall.
inputSchema, outputSchema, structuredContent, and MCP tool annotations.
Environment-variable-only secret handling. This server does not require secrets.
Read-only public API call to https://api.github.com/users/${username}.
Related MCP server: GitHub Read MCP Server
Tool name: github_user_lookup
Method: GET
URL template: https://api.github.com/users/${username}
Required input: username
Required secrets: none
npm install
npm run build
npm startFor clients that can run a GitHub-hosted npm package through npx:
{
"mcpServers": {
"firstcall-api-lookup": {
"command": "npx",
"args": ["-y", "github:rad1092/firstcall-api-lookup-mcp"]
}
}
}For a local checkout:
{
"mcpServers": {
"firstcall-api-lookup": {
"command": "node",
"args": ["/absolute/path/to/firstcall-api-lookup-mcp/dist/server.js"]
}
}
}Build the local checkout before using the second config:
npm install
npm run builddocker build -t firstcall-api-lookup-mcp .
docker run --rm -i firstcall-api-lookup-mcpThis server is generated from a verified FirstCall recipe. The generated MCP server is an artifact, not the source of truth for FirstCall package import. FirstCall keeps verification, packaging, validation, inspection, and local re-verification as explicit steps.
No real tokens or secrets are committed here.
This server does not require environment variables.
Response previews are redacted by the generated server for common secret-looking keys.
The tool is read-only and carries MCP annotations as advisory hints.
Policy and local verification remain FirstCall's guardrails; MCP annotations are not security controls.
Verified API tool recipes for AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | path |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| ok | Yes | |
| body_preview | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations clearly indicate read-only, non-destructive, idempotent behavior. The description adds no additional behavioral context beyond what the annotations already provide. Since annotations are explicit, the bar is lower, and a score of 3 is appropriate as the description does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is vague and uninformative. It does not earn its place; conciseness should provide value, not just brevity. The sentence could be replaced with nothing without loss of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a simple structure with one parameter and an output schema, the description fails to explain the tool's core function (looking up GitHub users). A complete description would state the purpose clearly; this one is insufficient for an agent to understand its role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single parameter 'username' described as 'path'. The description adds no further meaning, so it does not enhance understanding beyond the schema. Baseline score of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Verified API tool recipes for AI agents' is extremely generic and does not specify what the tool does. It lacks a verb and resource, and fails to distinguish it from any other tool. The tool name 'github_user_lookup' hints at the purpose, but the description does not reinforce it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about the tool's purpose or appropriate use cases, leaving the agent to infer from the name alone. No exclusion criteria or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0github_user_lookupOnly one tool exists, so there is no risk of confusion between tools. However, the vague description 'Verified API tool recipes for AI agents' does not clearly distinguish its purpose.
With a single tool, naming consistency is not a significant issue, but the name 'github_user_lookup' uses a noun-heavy pattern that is not a standard verb_noun convention.
A single tool for a server named 'firstcall-demo-mcp-server' suggests an extremely narrow scope, likely insufficient for meaningful interaction without additional tools.
The single tool only covers user lookup, which is a minimal subset of potential GitHub operations. Obvious gaps like repository or issue management exist, making the surface incomplete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
PerfectPost is a LinkedIn content management platform. This MCP server gives AI assistants read and write access to a user's PerfectPost account: published posts with their engagement analytics, drafts lifecycle (create / edit / schedule), and LinkedIn profile data.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
OAuth-protected, read-only-by-default MCP server for provenance-labeled QuillCaddie project memory.
Public, read-only MCP server for FarmNeural company facts, packages, and capabilities.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rad1092/firstcall-api-lookup-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
