semanticscholar-mcp

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct resource or operation: authors vs. papers, search vs. retrieval, citations vs. references. The only bulk operation (batch_get_papers) is clearly a convenience variant of get_paper, not an ambiguous alternative.
Naming Consistency5/5
All tools follow the verb_noun pattern with snake_case (get_, search_, batch_get_). The naming is consistent and predictable, with entity types and actions clearly reflected in the command.
Tool Count5/5
Nine tools is appropriately scoped for a scholarly search and retrieval server. Each tool addresses a distinct need without redundancy or bloat.
Completeness5/5
The tool surface covers the core read-only academic workflows: searching authors and papers, retrieving details, listing an author's papers, finding citations and references, getting recommendations, and batch retrieval. There are no obvious missing operations for this domain.
Average 3.1/5 across 9 of 9 tools scored. Lowest: 1.7/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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided and no behavioral detail in the description, the agent cannot learn what side effects, return formats, or limitations exist. The description adds nothing beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short phrase), but this brevity is due to under-specification rather than efficient writing. It is not well-structured or front-loaded since it contains no informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-author tool with sibling tools and no annotations or output schema, the description is deeply inadequate. It fails to explain return fields, differences from search_authors, or any usage context. Completeness is minimal.
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?
The input schema already provides descriptions for both parameters (e.g., 'Semantic Scholar 作者 ID', '返回字段'), giving 100% coverage. The description adds no additional parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取作者详细信息' is simply a rephrase of the tool name/title 'Get Author Details'. It restates the name without adding any distinguishing information against sibling tools like get_author_papers or search_authors. This is a tautology, not a clear specification of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description does not mention any context, prerequisites, or exclusions, leaving the agent without any decision support for tool selection.
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, the description carries the full burden but only conveys the tool's purpose. It does not disclose pagination, matching behavior, result format, or any operational side effects, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it is more under-specified than appropriately concise. It communicates the basic purpose yet lacks the context that would make the brevity effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a need to differentiate from sibling author tools, this one-phrase description is incomplete. It does not explain return values, pagination behavior, or when it should be preferred over related tools.
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 100% for all three parameters (query, limit, offset), so the schema already documents their meaning. The description adds no parameter-level value, meeting the baseline for full coverage.
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 states a clear verb+resource ('search academic authors'), which distinguishes it from siblings like search_papers and get_author. However, it lacks explicit scope details such as searching by name or result behavior, so it stops short of the most precise standard.
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 given for when to use this tool versus alternatives like get_author or get_author_papers. There are no exclusions, prerequisites, or contextual cue to aid selection.
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 disclosing behavioral traits. It only mentions basic search/filter capabilities, omitting important details such as pagination behavior, sorting, rate limits, authentication requirements, or what happens when no results are returned. This is insufficient for a tool with no annotation support.
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 a single, efficient sentence with no redundant wording. It clearly conveys the tool's purpose and general capability, earning its place without unnecessary detail. However, it lacks any extension such as usage context, which would make it more valuable while still being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a rich schema with 7 parameters, the description fails to provide contextual information about return values, pagination defaults, result structure, or any practical usage scenarios. Since there is no output schema to clarify return data, the description should compensate but does not, making it inadequate for a tool of this complexity.
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?
The schema describes all 7 parameters with clear descriptions (100% coverage), so the baseline is 3. The description's phrase 'supports keyword search and filtering conditions' adds only a high-level summary of the parameter set, not enhancing the schema's meaning or providing additional context about parameter usage or relationships.
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 a specific verb+resource: "搜索学术论文" (search academic papers), and distinguishes itself from siblings like search_authors by focusing on papers rather than authors. It also mentions keyword search and filtering, which aligns with the tool's intended function.
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 gives no guidance on when to use this tool versus alternatives (e.g., get_paper for retrieving a specific paper by ID). It simply states the basic functionality without exclusions or alternative recommendations, leaving the agent to infer usage context from the sibling names.
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 only states the core action and does not mention pagination behavior, return format, rate limits, or potential errors. As a read operation, side effects are minimal, but the agent has no information about response structure or operational nuances.
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 a single, front-loaded sentence with no filler. It efficiently conveys the purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, yet the description does not explain the return values or pagination details. While the schema documents parameters, the agent has no insight into what the reference list contains (e.g., titles, authors) or how to handle paging. This leaves significant gaps for a tool that could return potentially large lists.
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?
All three parameters (paperId, limit, offset) have exhaustive descriptions in the input schema, providing 100% coverage. The tool description adds no additional parameter semantics beyond what the schema already offers, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (获取/get) and clearly identifies the resource as the paper's reference list, explicitly clarifying that these are works cited by the paper. This distinguishes it from the sibling tool get_paper_citations, which would retrieve works citing the paper.
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 explicit guidance is provided on when to use this tool versus alternatives like get_paper_citations or get_paper. The differentiation is only implicit through the wording of the description, not directly stated.
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, but it only states the batch size limit (which is already present in the schema's maxItems). It does not mention return format, what happens when invalid IDs are passed, ordering, pagination, or any error/edge-case behavior. This is a significant gap for a tool with no structured safety hints.
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?
A single, front-loaded sentence effectively communicates the core purpose. No filler or redundancy. It is appropriately concise, though it lacks any additional structured details that might naturally be included (e.g., noting the optional 'fields' parameter).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters but no annotations and no output schema. The description only says 'detailed information', leaving unclear what the response shape is, how the 'fields' parameter affects results, and how failures are handled. This is incomplete for an agent aiming to invoke it correctly without additional context.
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 100% (both 'paperIds' and 'fields' have descriptions). The description adds no new meaning beyond restating the limit already captured by maxItems. Baseline 3 is appropriate because the schema carries the parameter semantics.
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 uses a specific verb ('批量获取' / batch get) plus resource ('论文' / papers) and explicitly scopes it with a maximum of 500. It clearly distinguishes itself from the sibling 'get_paper' (single paper retrieval) and 'search_papers'.
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 intent is implied: use this when fetching multiple paper details at once. However, there is no explicit statement about when to use it over alternatives, nor any exclusions or prerequisites. It provides clear context but no direct comparison to 'get_paper' or other siblings.
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 full responsibility for disclosing behavior. It only mentions fetching a list but does not disclose pagination behavior (limit/offset), ordering, potential rate limits, authentication needs, or return format. This is a significant gap for a tool that may return large lists.
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 a single, clear sentence with no redundancy. It is front-loaded and efficient, though it could be slightly expanded to mention pagination without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values and behavioral details. It only states the basic purpose, leaving pagination, result shape, and edge cases undocumented. This is insufficient for an agent to use the tool fully, especially since sibling tools show the system has more complex interactions.
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 100%, so parameters are already documented. The description does not add extra meaning beyond 'specified author', which aligns with authorId. Baseline of 3 is appropriate because the schema carries the weight and the description adds no contradiction or extra nuance.
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 states the exact action: '获取指定作者的论文列表' (get the list of papers for a specified author). This clearly distinguishes it from siblings like get_author (author details) and search_papers (general paper search).
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 purpose itself implies when to use it: when you need papers by a specific author. However, the description does not explicitly state when not to use it or mention alternatives like search_papers, so usage guidance remains implicit.
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 of behavioral disclosure. It only states the core function and omits details about pagination, default limits, sorting, return format, or any side effects. With no annotations, this is a significant gap.
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 a single, concise sentence in Chinese that conveys the essential purpose without extraneous information. It is front-loaded and easy to parse.
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?
For a simple list tool with three parameters and no output schema, the description provides adequate purpose but lacks return value details, pagination behavior, and ordering information. It is functional but has clear gaps that could confuse an agent.
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?
The input schema already describes all parameters with 100% coverage, so the baseline is 3. The description adds minimal extra meaning by clarifying that paperId refers to the paper being cited, but this is a marginal enhancement over the schema's generic '论文 ID'.
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 fetches a list of papers that cite a specified paper, using a specific verb and resource. It distinguishes itself from sibling tools like get_paper_references by explicitly noting the direction ('who cited this paper').
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 when to use the tool (when needing citing papers) but does not explicitly name alternatives or exclusions. No contrast with get_paper_references or other siblings is provided, so the usage context is clear but not reinforced.
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, the description carries the full burden. It only states the basic function without disclosing how recommendations are generated, whether they are content-based or citation-based, or what limits apply. It does not mention any side effects, permissions, or output characteristics, leaving significant behavioral ambiguity.
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 a single, concise sentence that immediately states the core function. It is front-loaded and contains no unnecessary words or repetition.
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?
The tool is relatively simple with only three parameters, all well-documented in the schema. However, there is no output schema and no annotations, and the description does not mention return format, default behavior, or any edge cases. It is minimally viable but leaves notable gaps for an agent seeking full context.
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?
The schema description coverage is 100%, as all parameters have descriptive Chinese labels explaining their purpose. The tool description itself adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.
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 uses a specific verb ('获取' / 'get') and resource ('推荐的相关论文' / 'recommended related papers') based on specified papers. It clearly distinguishes this from sibling tools like get_paper_citations or get_paper_references, making it the only recommendation-oriented tool.
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 have specific papers and want similar ones, use this tool. However, it provides no explicit guidance on when not to use it or how it differs from alternatives like get_paper_references. The context is clear but not elaborated.
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 full responsibility for behavioral disclosure. While it mentions support for multiple ID formats, this is already documented in the input schema. The description does not disclose important behavioral aspects such as return format, error handling for invalid IDs, whether fields are optional, or any rate limits or authentication requirements.
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 a single, front-loaded sentence that immediately states the tool's purpose and key capability (multiple ID formats). It contains no filler or redundancy, making it highly efficient and easy to parse.
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 low tool complexity, full schema coverage for all parameters, and absence of an output schema, the description is largely sufficient. It clearly identifies the tool's purpose and primary input types. The only missing element is explicit usage guidance, but the description is adequate for a straightforward retrieval tool.
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 100%, so the schema fully documents both 'paperId' and 'fields'. The description adds minimal value beyond the schema by repeating the ID format support, which is already in the schema's parameter description. It neither clarifies parameter syntax nor provides additional context about how fields affect the response.
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 '获取' (get) and the resource '论文详细信息' (detailed paper information), with specific mention of multiple ID formats. This distinguishes it from sibling tools like get_author (which gets author details) and search_papers (which searches rather than retrieves a specific paper).
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 the tool should be used when you need detailed information about a paper identified by various ID formats. However, it does not explicitly mention when to use this tool over alternatives such as batch_get_papers or get_paper_citations, nor does it provide any exclusion criteria.
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:

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

Score Badge

Copy to your README.md:

[![semanticscholar-mcp MCP server](https://glama.ai/mcp/servers/xbghc/semanticscholar-mcp/badges/score.svg)](https://glama.ai/mcp/servers/xbghc/semanticscholar-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/xbghc/semanticscholar-mcp'

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