MCP server providing developer tools data including npm packages, Stack Overflow Q&A, GitHub trending repos, and code snippets for AI agents.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 7 of 7 tools scored.
Each tool targets a distinct data source and operation: GitHub repos, npm packages, PyPI packages, arXiv papers, GitHub search, Google Scholar, and Stack Overflow. Even the two GitHub tools differ in purpose (get specifics vs search). No overlap.
All tool names follow a consistent verb_noun pattern using snake_case: get_* and search_*. The verbs are precise and the nouns clearly indicate the target resource.
With 7 tools, the set is well-scoped for a developer toolkit covering package registries, code search, academic resources, and Q&A. Each tool serves a distinct purpose without bloat.
The set covers major developer resources (GitHub, npm, PyPI, arXiv, Google Scholar, Stack Overflow). Missing are tools for other registries (e.g., Maven, Docker Hub) and package search for npm/PyPI (only get by name), but core workflows are well represented.
get_github_repoAFetch detailed statistics and metadata for a GitHub repository. Returns star count, fork count, open issue count, primary programming language, project description, last updated timestamp, and contributor count. Use for evaluating open-source projects, competitive analysis, or monitoring project health.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository in format 'owner/repo' (e.g. 'facebook/react', 'kubernetes/kubernetes') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations (readOnlyHint, openWorldHint) by specifying the exact data returned (star count, fork count, etc.). It does not contradict annotations and provides useful details about the tool's output.
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?
Description is two sentences: first clearly states the action, second lists returns and use cases. No fluff, every sentence adds value.
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?
Tool has only one parameter, no output schema, but description lists all return values explicitly. Complete for a low-complexity tool.
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?
Schema covers 100% of parameters with a clear description, so the description does not need to add parameter details. It correctly avoids repetition.
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?
Description clearly states the tool fetches detailed statistics and metadata for a GitHub repository, listing specific data points (star count, fork count, etc.). It distinguishes itself from sibling tools like search_github which is for searching, and get_npm_package/get_pypi_package which are for other ecosystems.
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?
Description provides explicit use cases: 'evaluating open-source projects, competitive analysis, or monitoring project health.' While it does not explicitly state when not to use or alternatives, the context from sibling tools makes the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_npm_packageALook up Node.js package information from NPM registry. Returns latest version, download statistics (weekly/monthly), dependency list, package description, license, and GitHub link. Use for evaluating JavaScript libraries, checking maintenance status, or reviewing package popularity.
| Name | Required | Description | Default |
|---|---|---|---|
| package_name | Yes | NPM package name exactly as published (e.g. 'express', 'react', 'lodash', '@babel/core') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds value by listing the specific data fields returned (version, downloads, dependencies, license, GitHub link), which is helpful for an agent deciding whether to use the tool.
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 concise: two sentences that efficiently convey the tool's purpose, output, and usage context. Every sentence adds value with no redundancy.
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?
Given the simple input schema and absence of output schema, the description adequately covers what the agent needs to know: what data to expect and when to use it. It does not discuss error handling or rate limits, but for a read-only lookup tool, this is complete enough.
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?
Schema description coverage is 100%, with detailed examples for the package_name parameter. The description does not add additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate.
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 clearly states the tool looks up Node.js package information from the NPM registry, specifies the data returned (latest version, downloads, dependencies, etc.), and provides use cases. It effectively distinguishes itself from sibling tools like get_pypi_package and search_arxiv.
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?
The description provides clear use cases ('evaluating JavaScript libraries, checking maintenance status, reviewing package popularity'), implying when to use it. However, it does not explicitly mention when not to use it or compare with siblings, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pypi_packageARetrieve Python package information from PyPI (Python Package Index). Returns current version, download counts, dependencies, release history, package homepage, and PyPI page URL. Use for Python library evaluation, dependency analysis, or checking package quality metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| package_name | Yes | PyPI package name as listed in registry (e.g. 'numpy', 'django', 'flask', 'pandas') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, and the description aligns by describing a safe read operation. It adds detail about returned fields (version, downloads, etc.) without contradicting annotations. However, it does not mention potential rate limits or external API constraints.
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 extremely concise: two sentences that front-load the core purpose and return details. There is no extraneous information; every sentence adds value.
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?
Given the tool's simplicity (one parameter, no output schema but listed returns), the description fully covers what the tool does, how it works, and what it returns. No gaps remain for this use case.
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 single parameter 'package_name' is already well-described in the schema (100% coverage). The description adds no additional parameter-level information, so it meets the baseline of 3 without further enhancement.
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 clearly states the tool retrieves Python package information from PyPI, listing specific data returned like version and downloads. It distinguishes itself from sibling tools that target different registries (npm, GitHub).
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?
The description explicitly mentions use cases: 'Python library evaluation, dependency analysis, or checking package quality metrics.' Though it doesn't explicitly exclude scenarios, the use cases are well-defined and contextually differentiate from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_arxivASearch arXiv for academic papers in computer science, machine learning, AI, physics, and mathematics. Returns paper titles, authors, abstracts, submission dates, and direct PDF download links. Use for researching algorithms, ML techniques, or emerging CS topics.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Research topic in CS/ML/physics (e.g. 'transformer architectures', 'distributed systems', 'quantum algorithms') | |
| max_results | No | Papers to return (default 10, suitable for focused research) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, and the description adds context about the scope of search and returned data. It does not describe rate limits or error handling, but given annotations, the added transparency is sufficient.
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?
Three sentences, front-loaded with the main action, no redundant information. Every sentence adds value – purpose, return data, usage guidance.
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?
Given no output schema, the description comprehensively lists what is returned (titles, authors, abstracts, dates, PDF links). All relevant information for an agent to select and invoke the tool is present.
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?
Schema coverage is 100%, but description adds meaning: query is described as a research topic with examples, and max_results is described with a default value and suitability for focused research. This adds value beyond the schema.
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?
Description clearly states it searches arXiv for academic papers in specific domains (CS, ML, AI, physics, mathematics) and lists the data returned (titles, authors, abstracts, dates, PDF links). It distinguishes from siblings like search_google_scholar by specifying arXiv as the source and the fields covered.
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?
Explicitly states 'Use for researching algorithms, ML techniques, or emerging CS topics,' providing clear context for when to use. It does not explicitly mention when not to use or compare to alternatives, but the context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_githubASearch GitHub repositories by keyword to discover code, projects, and libraries. Returns matching repositories with star count, description, language, and URL. Use for finding libraries, examples, or competitive projects in specific domains.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keywords or project name (e.g. 'web framework', 'authentication library', 'data visualization') | |
| max_results | No | Number of repository results to return (default 10, up to 100 for broad searches) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe, read-only behavior. The description adds value by specifying the returned fields ('star count, description, language, and URL'), which is beyond what the annotations provide. No contradictions.
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 two sentences, front-loading the purpose and then detailing output. Every sentence contributes value without repetition or fluff.
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?
Given no output schema, the description adequately summarizes return values. It covers the tool's purpose, parameters, and output format. Though additional details like pagination or sorting could be included, the current description is sufficient for a search tool with two parameters.
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?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context for both parameters: query is explained with examples, and max_results is described with default and upper limit. This goes beyond bare schema definitions.
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 clearly states the verb 'Search', the resource 'GitHub repositories', and the purpose 'discover code, projects, and libraries'. It distinguishes itself from sibling tools like get_github_repo by focusing on search rather than retrieving a single repository.
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?
The description provides specific use cases: 'finding libraries, examples, or competitive projects in specific domains'. While it doesn't explicitly state when not to use it, the context is clear enough for an AI agent to decide when to invoke this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_google_scholarASearch Google Scholar for computer science research papers, citations, and academic publications. Returns paper title, authors, publication details, citation count, and link to paper. Use for finding research on CS topics, reviewing state-of-the-art, or citation tracking.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Computer science research topic (e.g. 'natural language processing', 'distributed consensus algorithms') | |
| max_results | No | Maximum papers to return (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds context about returned fields and domain focus, but does not disclose potential limitations (e.g., rate limits, coverage scope). No contradiction with annotations.
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?
Two sentences with no wasted words. First sentence defines action and scope, second sentence details returns and usage. Front-loaded and efficient.
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?
For a simple two-parameter tool with no output schema, the description adequately covers purpose, input, and output. Could mention pagination but not essential.
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?
Schema description coverage is 100%, so baseline is 3. The description reinforces the CS domain for the query parameter but adds no new parameter-specific semantics beyond what the schema provides.
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 clearly states the tool searches Google Scholar for computer science research papers, specifying the resource and action. It distinguishes from siblings like search_arxiv by focusing on Google Scholar and CS topics.
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?
The description provides explicit use cases: finding CS research, reviewing state-of-the-art, citation tracking. However, it does not mention when not to use it or compare with siblings like search_arxiv, which covers similar academic content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_stackoverflowASearch Stack Overflow Q&A platform for programming questions, solutions, and code examples. Returns matching questions, answer count, view count, accepted answer snippet, tags, and link to full discussion. Use for troubleshooting, code examples, or finding solutions to common problems.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Programming problem or question (e.g. 'how to merge arrays in javascript', 'python asyncio example') | |
| max_results | No | Number of Q&A results to retrieve (default 10, higher for comprehensive answers) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, signaling a safe, read-only operation. The description adds no further behavioral traits (e.g., rate limits, authentication). It is consistent but does not go beyond what annotations cover.
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?
Two concise sentences: one defining purpose and output, another giving usage guidance. No redundant information; every sentence adds value.
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?
Given the tool's simplicity (2 parameters, no output schema) and supportive annotations, the description covers purpose, output details, and usage. It lacks details like pagination or max limits, but is adequate for its complexity.
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?
Schema description coverage is 100%, with clear descriptions for both parameters including examples and defaults. The tool description does not add extra parameter context, so it meets the baseline of 3.
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 clearly states the tool searches Stack Overflow for programming questions, solutions, and code examples. It lists specific return fields, distinguishing it clearly from siblings like search_github or search_arxiv.
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?
It provides explicit usage context: 'Use for troubleshooting, code examples, or finding solutions to common problems.' This helps the agent decide when to use it, though it does not mention when not to use it or directly compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
