ScholarScope MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. The tools cover different aspects of academic research: fetching full text, searching for papers/authors/institutions, getting author papers, and analyzing paper relationships (references, related works, citations). There is no overlap in functionality.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case throughout. The naming is predictable and readable: fetch_fulltext, papers_by_author, referenced_works_in_paper, related_works_of_paper, search_authors, search_institutions, search_papers, works_citing_paper.
Tool Count5/5
With 8 tools, this is well-scoped for an academic research server. Each tool earns its place by covering essential operations: searching across different entity types, fetching content, and analyzing paper relationships. The count is neither too thin nor too heavy for the domain.
Completeness4/5
The tool surface provides excellent coverage for academic research workflows: searching, fetching, and relationship analysis. Minor gaps exist, such as no direct tools for updating metadata or managing user collections, but agents can accomplish core research tasks effectively with the provided tools.
Average 3.6/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/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 mentions the API source and error handling, but lacks critical details like rate limits, authentication requirements, pagination behavior beyond the 'page' parameter, or what constitutes a 'failed' search. This leaves significant gaps for an agent to understand operational constraints.
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 well-structured with clear sections (Args, Returns) and uses efficient sentences. However, the first sentence could be more front-loaded with key details, and some redundancy exists (e.g., 'The search name to look for the institutions' could be tighter). Overall, it's concise but has minor room for improvement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers basic input semantics and return values, but lacks behavioral context (e.g., API limits, error conditions) and usage guidelines relative to siblings. The output schema reduces the need to detail return values, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds basic semantics for all three parameters (e.g., 'query' is a search name, 'sort_by' has two criteria, 'page' retrieves results), but doesn't provide deeper context like query syntax examples, how 'cited_by_count' sorting works, or pagination limits. This partially addresses the schema gap but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Searches for') and resource ('institutions') using a specific API ('OpenAlex API'), making the purpose unambiguous. However, it doesn't explicitly differentiate this tool from sibling tools like 'search_authors' or 'search_papers' beyond the resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_authors' or 'search_papers' for comparison, nor does it specify scenarios where searching institutions is appropriate over other search tools. Usage is implied by the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions that it returns a JSON object or error message. It lacks details on rate limits, authentication needs, pagination behavior beyond the 'page' parameter, or what happens with empty results.
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 well-structured with clear sections for Args and Returns, and each sentence adds value. It could be slightly more concise by integrating the default values more seamlessly, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage and an output schema present, the description adequately covers parameters but lacks behavioral context (e.g., error conditions, API constraints). The output schema reduces the need to detail return values, but more operational guidance would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining all 4 parameters: 'query' as the search name, 'sort_by' with criteria options, 'institution_id' as an optional filter with an example, and 'page' with its default. This adds meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for authors using the OpenAlex API, specifying the resource (authors) and action (search). However, it doesn't explicitly differentiate from sibling tools like 'search_institutions' or 'search_papers' beyond mentioning the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'papers_by_author' or other search tools. The description only states what it does without context about use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions the API (OpenAlex) and return format (JSON object with papers or error), but lacks details on rate limits, authentication needs, pagination behavior beyond the 'page' parameter, or what constitutes a 'failed' search. For a search tool with 6 parameters, this is insufficient.
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 well-structured with clear sections (Args, Returns) and uses bullet-like formatting for parameters. Every sentence adds value, but it could be more front-loaded by stating the core purpose more prominently before diving into parameters. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, but has output schema), the description is moderately complete. It explains parameters well and notes the return format, but lacks behavioral context (e.g., rate limits, error conditions). The output schema existence reduces the need to detail return values, but more operational guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear explanations for all 6 parameters, including optionality, defaults, and examples (e.g., author_id format). This adds significant meaning beyond the bare schema, though it doesn't cover all possible edge cases or advanced usage scenarios.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'searches for academic papers using the OpenAlex API,' which is a specific verb+resource combination. It distinguishes itself from siblings like 'search_authors' and 'search_institutions' by focusing on papers, but doesn't explicitly differentiate from 'fetch_fulltext' or 'works_citing_paper' in terms of search scope versus retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'papers_by_author' (which might fetch papers by a specific author) or 'search_authors' (which searches for authors instead of papers). It lacks explicit when/when-not instructions or named alternatives, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the API and error handling, it lacks critical details: authentication requirements, rate limits, pagination behavior beyond the 'page' parameter, whether results are cached, or what specific error conditions might occur. The description provides basic operational context but misses important behavioral traits.
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 well-structured with clear sections (purpose, args, returns) and efficiently conveys essential information. Every sentence serves a purpose, though the 'Returns' section could be slightly more concise given the existence of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with output schema), the description is adequate but has gaps. The output schema existence reduces the need to detail return values, but the description lacks context about API limitations, error specifics, and differentiation from sibling tools. It covers the basics but misses some operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the schema's lack of parameter documentation. It successfully explains all three parameters: 'author_id' (OpenAlex Author ID with example), 'sort_by' (sorting criteria with enum values), and 'page' (page number with default). The description adds meaningful context beyond what the bare schema provides.
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 ('searches for academic papers') and resource ('by a particular author using the OpenAlex API'), distinguishing it from sibling tools like 'search_papers' (general paper search) and 'search_authors' (author search). It provides a complete, unambiguous purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_papers' (which might allow broader searches) or 'referenced_works_in_paper' (which focuses on citations). It mentions the OpenAlex API but doesn't explain when author-specific searches are appropriate versus other search methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions retrieval from an API and potential error messages, but lacks details on rate limits, authentication needs, pagination behavior beyond the 'page' parameter, or what the JSON structure looks like (though output schema exists). For a tool with no annotation coverage, this leaves significant behavioral gaps.
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 front-loaded with the core purpose, followed by structured sections for args and returns. It's efficient with minimal waste, though the 'Returns' section could be slightly more concise given the output schema exists. Overall, it's well-structured and appropriately sized.
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 tool has an output schema (which handles return values), no annotations, and moderate complexity with 3 parameters, the description is fairly complete. It covers purpose, parameters, and basic behavior, but lacks deeper context like error handling details or API-specific constraints, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains each parameter's purpose: 'paper_id' as the target paper ID with an example, 'sort_by' as sorting criteria with options, and 'page' as page number with default. This adds meaningful context beyond the schema's titles and enums, though it doesn't detail format constraints beyond the example.
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 verb 'Retrieves' and the resource 'works that cite a given paper from the OpenAlex API', specifying the exact operation. It distinguishes from siblings like 'referenced_works_in_paper' (which would find works referenced by a paper) and 'related_works_of_paper' (which might find conceptually related works), making the purpose specific and differentiated.
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 when you need to find papers citing a specific paper, but it does not explicitly state when to use this tool versus alternatives like 'search_papers' (which might allow broader searches) or 'referenced_works_in_paper'. No exclusions or prerequisites are mentioned, leaving usage context somewhat implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 uses the OpenAlex API, may return empty results if full text is inaccessible, and returns a JSON object with a list of paper ids or an error message on failure. This covers operational context and error handling, though it could add more on rate limits or authentication needs.
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, followed by a note on limitations, and then clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), no annotations, and the presence of an output schema (which handles return values), the description is complete enough. It covers purpose, usage notes, parameter semantics, and return behavior, providing all necessary context for effective tool invocation without overloading with unnecessary details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds meaningful semantics by explaining that 'paper_id' is 'An OpenAlex Work ID of the target paper' and provides an example format ('https://openalex.org/W123456789'), which clarifies usage beyond the schema's basic string type. However, it does not detail constraints like valid ID patterns or length, keeping it from a score of 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gets referenced works used in the specified paper using the OpenAlex API.' It specifies the verb ('Gets'), resource ('referenced works'), and target ('specified paper'), but does not explicitly differentiate it from sibling tools like 'related_works_of_paper' or 'works_citing_paper', which prevents a score of 5.
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 provides implied usage guidance through the note about potential empty returns when 'the paper's full text is inaccessible,' which suggests when this tool might not be effective. However, it lacks explicit guidance on when to use this tool versus alternatives like 'related_works_of_paper' or 'works_citing_paper,' and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the API source (OpenAlex), notes that it may return empty results due to accessibility issues, and describes error handling on fetch failure. This covers operational context beyond basic functionality.
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 appropriately sized and front-loaded, with the core purpose in the first sentence, a critical note in the second, and structured sections for Args and Returns that add necessary detail without waste. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but with an output schema), the description is complete enough. It covers purpose, usage notes, parameter details, and return behavior, and since an output schema exists, it doesn't need to explain return values in depth, making it well-rounded for the context.
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 description adds significant meaning beyond the input schema, which has 0% coverage. It explains that 'paper_id' is an OpenAlex Work ID, provides an example format ('https://openalex.org/W123456789'), and clarifies it's for the target paper, fully compensating for the schema's lack of documentation.
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 ('Gets related works') and resource ('specified paper using the OpenAlex API'), distinguishing it from siblings like 'referenced_works_in_paper' or 'works_citing_paper' by focusing on general related works rather than specific citation directions.
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 provides implied usage through the note about empty returns when full text is inaccessible, which hints at when results might be limited. However, it lacks explicit guidance on when to use this tool versus alternatives like 'referenced_works_in_paper' or 'works_citing_paper', leaving the agent to infer based on the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations (readOnlyHint, idempotentHint) by disclosing potential access restrictions (paywalls, authentication) and possible partial outputs. This helps the agent understand real-world limitations, though it doesn't cover rate limits or detailed error handling.
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 with a clear main statement, a note section for important caveats, and separate Args/Returns sections. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, read-only/idempotent annotations, output schema exists), the description is complete. It covers purpose, usage notes, parameter meaning, and output behavior, with the output schema handling return value details, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the parameter's meaning ('Preferred full-text URL of the paper or work'), adding essential semantics not present in the schema. It clarifies what the URL represents, though it could provide more on format or validation.
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 tool's purpose with specific verbs ('retrieves', 'returns') and resources ('contents of a paper or work', 'preferred full-text URL'), distinguishing it from sibling tools that search or list papers rather than fetch full content. It precisely defines what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to get full-text content from a URL) but does not explicitly mention when not to use it or name specific alternatives among the sibling tools. It implies usage for retrieving text content rather than metadata or search operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ScholarScope-MCP MCP server](https://glama.ai/mcp/servers/ErikNguyen20/ScholarScope-MCP/badges/card.svg)](https://glama.ai/mcp/servers/ErikNguyen20/ScholarScope-MCP)

Score Badge

Copy to your README.md:

[![ScholarScope-MCP MCP server](https://glama.ai/mcp/servers/ErikNguyen20/ScholarScope-MCP/badges/score.svg)](https://glama.ai/mcp/servers/ErikNguyen20/ScholarScope-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ErikNguyen20/ScholarScope-MCP'

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