hackerearth-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HACKEREARTH_KEY | Yes | Your HackerEarth client-secret API key. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run_codeA | Executes a snippet of code on HackerEarth's cloud servers in any of 24 languages. Use when the user wants to test code, see real output instead of predicted output, or check whether a program works. Needs the code and the language identifier, call list_languages if unsure of the exact name. Requires HACKEREARTH_KEY to be set; every run consumes the key owner's HackerEarth API quota. Returns the program's printed output and any error messages. |
| list_languagesA | Returns the list of programming languages HackerEarth can execute, with the exact identifiers to pass to run_code. Use this when you are unsure which language name to use, or when the user asks what languages are available. Takes no inputs. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: one enumerates supported languages and the other executes code. There is no overlap in their intent or expected inputs, so an agent cannot confuse them.
Both names follow a clean verb_noun pattern (list_languages, run_code) in consistent snake_case. The convention is predictable and readable.
The domain (remote code execution) is narrow, so a small surface is defensible, but two tools is on the thin side. There is little room for the set to grow without adding value, making it borderline under-scoped.
The pair covers the essential lifecycle: discover a language, then run code and receive output/errors. Minor gaps exist (e.g. no explicit async job-status or quota-check operation), but core functionality is intact and workable.