scopus-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct operation: paper retrieval, author profiles, citation count, citation timeline, paper search, affiliation search, and author search. No two tools overlap in purpose.
Naming Consistency5/5All tools follow the consistent pattern 'scopus_<verb>_<noun>' (e.g., scopus_get_abstract, scopus_search_authors). No mixing of styles or irregular names.
Tool Count5/57 tools is a reasonable number for a Scopus API wrapper, covering search, retrieval, and citation tracking without being overwhelming or insufficient.
Completeness4/5The tool set covers core Scopus operations (search, retrieve abstracts/authors, citation info). Minor gaps like pagination for large result sets or listing citing papers are absent but not critical for basic use.
Average 4.3/5 across 7 of 7 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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.
Tools from this server were used 11 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
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?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as rate limits, authentication requirements, error handling, side effects, or what happens when a query is malformed or returns no results. This is a significant gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the main purpose. It uses line breaks for readability and groups related information. A minor improvement could be trimming redundant phrasing, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description covers query usage well but lacks information on return values, pagination metadata, error messages, or practical limits. It is complete enough for basic use but not for robust agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds value for the 'query' parameter by explaining field codes and syntax, but for other parameters (count, start, view) it offers no additional meaning beyond the schema. It is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the Scopus academic database for papers using Boolean query syntax.' It specifies the action (search), the resource (Scopus academic database), and the method (Boolean query syntax), effectively distinguishing it from sibling tools like scopus_get_abstract and scopus_search_authors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed guidance on query syntax, including common field codes, Boolean operators, and an example. It also references a full syntax resource. However, it does not explicitly state when to use this tool vs. alternatives (e.g., scopus_search_authors for author searches), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the endpoint is lightweight and cached, indicating performance characteristics. However, it does not mention authentication requirements, rate limits, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no extraneous information. The purpose is front-loaded, and every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers the key aspects: what it does, how to use it (identifiers), and when to use it. It could be improved by mentioning behavior when both identifiers are provided or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by clarifying the conditional requirement that at least one of the two parameters must be provided, which is not captured in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current total citation count for a paper, specifying the action and resource. It is distinct from sibling tools like scopus_get_abstract or scopus_get_author.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use the tool ('for quick citation lookups without fetching the full abstract') and explains that at least one identifier (Scopus ID or DOI) is required. However, it does not explicitly exclude situations or mention alternatives.
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?
Discloses the return payload in detail (title, abstract, authors, affiliations, keywords, subject areas, citation count, DOI, open access status). With no annotations, the description carries the full burden, and it adequately communicates that this is a read operation with comprehensive output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no fluff, front-loading the core action. The two sections (identifier types and return fields) are clearly separated. Slightly more structured formatting could improve readability but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description sufficiently enumerates returned fields. Usage tips (strip prefix) add completeness. No mention of pagination, rate limits, or errors, but for a straightforward retrieval tool, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description adds significant meaning by listing identifier types and noting the stripping of 'SCOPUS_ID:' prefix. This goes beyond the schema's basic descriptions, helping agents construct valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Retrieve full paper details from Scopus using any supported identifier.' It lists identifier types and what is returned, distinguishing it from sibling tools that search or retrieve other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on identifier value formatting (strip 'SCOPUS_ID:' prefix) and lists supported identifier types, helping agents use the correct input. However, does not explicitly state when to use this tool versus siblings like scopus_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It lists the return fields (h-index, citation count, etc.) and gives example IDs. However, it does not mention rate limits, authentication needs, or potential error scenarios. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) with front-loaded purpose, a clear list of return values, and a usage hint. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers all necessary information: what the tool does, what it returns, and how to obtain the required input. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'author_id' is documented in the schema (100% coverage). The description adds value by clarifying it is a numeric string, specifying to not include the 'AUTHOR_ID:' prefix, and providing example IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve a researcher's full Scopus profile') and specifies the resource (by Scopus Author ID). It distinguishes from sibling tools by directing users to first use scopus_search_authors to find the ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (to get a profile given an ID) and provides a clear alternative (scopus_search_authors) for finding the ID first. While it doesn't list negative cases, the guidance is sufficient for a retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies read-only behavior with 'search' terminology but does not explicitly confirm safety or disclose any side effects. Adequate for a simple search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise; includes query examples and purpose in a few lines. Front-loaded with key action and examples. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two parameters and full schema coverage, the description is complete. It explains query format, parameters, and the significance of the output (affiliation_id). No output schema needed for understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. Description adds value by providing query examples and clarifying that the result is an affiliation_id, which aids understanding beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search for institution and affiliation records in Scopus.' Provides query examples and mentions output purpose (affiliation_id). Distinguishes from sibling tools like scopus_search_authors or scopus_search by focus on affiliations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives query examples and explains that output is needed for author searches. Implicitly guides when to use (for affiliations) but does not explicitly exclude alternative tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden of behavioral disclosure. It describes the search operation and query syntax but lacks details on rate limits, authentication, pagination, or error handling. The schema already covers count constraints, but the description does not add beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only a few sentences. It front-loads the main purpose, then provides key details (field codes, example) and a usage hint. There is no redundancy, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks an explanation of the return values (output fields). Since there is no output schema, the description should at least mention what information is returned (e.g., author IDs, names). It also does not address authentication or error scenarios. Given the simple nature of the tool, it is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the query parameter's schema description is generic ('Author search query'). The description adds significant value by listing supported field codes (AUTHLASTNAME, AUTHFIRST, ORCID, AF-ID) and providing an example, which is not present in the schema. This enhances the agent's understanding of how to construct queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for author profiles in the Scopus author index. It provides query field codes and an example, distinguishing it from sibling tools like scopus_search (general search) and scopus_get_author (retrieves full metrics from an author ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides the user to use scopus_get_author with the returned author_id to fetch full metrics, indicating when to switch to an alternative. It also includes query construction guidance with field codes and an example, making usage clear.
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?
No annotations are provided, so the description carries the full burden. It discloses the output (citations per year within a date range) and implies a read-only operation. However, it does not explicitly state that the tool is read-only or mention any potential side effects, rate limits, or error conditions. Still, the main behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences for the main function plus a separate sentence for prerequisites. It is front-loaded with the primary action, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description adequately explains the return value (citations per year within date range). Combined with the parameter descriptions, the tool is fully understandable for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context on how to obtain the scopus_id, which is value beyond the schema definitions for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a year-by-year citation timeline for a paper, with specific verb 'Get' and resource 'citation timeline'. It distinguishes from sibling tools like scopus_get_citation_count by emphasizing the yearly breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: requires a Scopus ID and directs to scopus_search or scopus_get_abstract to obtain it. This tells the agent when to use this tool and what prerequisites are needed.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/JOSETRA44/scopus-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server