MCP server for ResearchTwin — inter-agentic research discovery across a federated network of researcher digital twins.
Exposes the ResearchTwin platform API as Model Context Protocol tools, enabling AI agents to discover researchers, explore publications, datasets, repositories, and compute S-Index impact metrics.
Tool | Description |
| List all researchers registered on the platform |
| Get a researcher's profile with S-Index score |
| Get comprehensive research context with all data source metrics |
| Get publications with citation counts |
| Get datasets with QIC (Quality × Impact × Collaboration) scores |
| Get code repositories with QIC scores |
| Search across all researchers for papers, datasets, or repos |
| Get geographic affiliations for all researchers |
Related MCP server: mcp-semanticscholar
URI | Description |
| Platform information and available tools |
pip install mcp-server-researchtwinOr install from source:
git clone https://github.com/martinfrasch/researchtwin.git
cd researchtwin/mcp-server
pip install -e .Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"researchtwin": {
"command": "mcp-server-researchtwin"
}
}
}Add to your Claude Code MCP settings:
{
"mcpServers": {
"researchtwin": {
"command": "mcp-server-researchtwin"
}
}
}To point at a local or self-hosted ResearchTwin instance:
RESEARCHTWIN_URL=http://localhost:8000 mcp-server-researchtwinOr in Claude Desktop config:
{
"mcpServers": {
"researchtwin": {
"command": "mcp-server-researchtwin",
"env": {
"RESEARCHTWIN_URL": "http://localhost:8000"
}
}
}
}Once connected, you can ask your AI agent:
"Who are the researchers on ResearchTwin?"
"Show me Martin Frasch's publications and S-Index score"
"Find all datasets related to fetal monitoring"
"What repositories have the highest QIC scores?"
"Show me the geographic distribution of the research network"
Python 3.10+
Network access to researchtwin.net (or your configured instance)
MIT
Search across all researchers for papers, datasets, or repositories matching a keyword.
Args: query: Search keyword (e.g. 'fetal', 'machine learning', 'turbulence'). type: Optional filter — 'paper', 'dataset', or 'repo'. Leave empty to search all types.
Returns matching items across all registered researchers, sorted by relevance. This is the primary tool for cross-researcher discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide a title ('Discover Research'), so the description carries the full burden. It effectively discloses key behavioral traits: it's a search operation (implied read-only, though not explicitly stated), returns items 'sorted by relevance,' and searches 'across all registered researchers.' However, it doesn't mention potential limitations like rate limits, auth needs, or result pagination, which would be helpful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the core purpose, followed by a clear 'Args' section with parameter details, then return behavior and contextual role. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, search functionality), the description is complete: it covers purpose, parameters, return behavior ('matching items... sorted by relevance'), and contextual role. With an output schema present, it doesn't need to detail return values, and the annotations are minimal, so the description adequately fills the gaps.
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 0%, so the description must compensate. It adds meaningful semantics: it explains that 'query' is a 'search keyword' with examples, and 'type' is an 'optional filter' with allowed values ('paper', 'dataset', 'repo') and the effect of leaving it empty. This goes beyond the schema's basic titles, though it doesn't detail format constraints (e.g., query length).
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's purpose with specific verbs ('search across all researchers') and resources ('papers, datasets, or repositories'), distinguishing it from sibling tools like get_papers or get_datasets which appear to be more specific. It explicitly identifies itself as 'the primary tool for cross-researcher discovery,' establishing its unique role.
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 guidance on when to use this tool vs. alternatives: it specifies that this is for 'cross-researcher discovery' and searching 'across all researchers,' implying that sibling tools like get_papers or get_datasets might be for single-researcher or type-specific queries. It also clarifies when to use the optional type filter vs. leaving it empty.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive research context for a researcher including all data source metrics.
Args: slug: Researcher identifier (e.g. 'martin-frasch').
Returns S-Index, paper impact, source connection status (Semantic Scholar, Google Scholar, GitHub, Figshare), dataset QIC scores, and repo QIC scores. More detailed than get_profile — use this when you need the full picture.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide a title, so the description carries the burden of behavioral disclosure. It describes what data is returned (S-Index, paper impact, source connection status, QIC scores), which adds useful context beyond the schema. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions. No contradiction with annotations exists.
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 efficiently structured: a purpose statement, parameter explanation with example, return value details, and usage guideline. Every sentence adds value without redundancy. It's front-loaded with the core purpose and appropriately sized for the tool's complexity.
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 has an output schema (which handles return values), the description focuses on purpose, parameters, and differentiation from siblings. It covers the essential context well, though it could benefit from mentioning behavioral aspects like performance or data freshness. The presence of an output schema reduces the need for return value details.
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 0%, so the description must compensate. It explains the 'slug' parameter as 'Researcher identifier (e.g. 'martin-frasch')', providing a clear example and clarifying its purpose. This adds meaningful semantics beyond the bare schema, though it doesn't detail format constraints or validation rules.
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 ('Get') and resource ('comprehensive research context for a researcher'), specifying it includes 'all data source metrics'. It explicitly distinguishes from sibling 'get_profile' by stating it's 'more detailed' and provides 'the full picture', 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'use this when you need the full picture' and contrasts it with 'get_profile' by noting it's 'more detailed'. This provides clear guidance on when to choose this tool over the alternative sibling, though it doesn't mention other siblings like 'get_papers' or 'list_researchers'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a researcher's datasets with QIC (Quality x Impact x Collaboration) scores.
Args: slug: Researcher identifier.
Returns Figshare datasets with DOIs, download/view counts, and QIC scores computed using FAIR-based quality assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide a title, so the description carries full burden. It describes the return data (Figshare datasets with DOIs, counts, and QIC scores) and mentions the QIC computation method, which adds useful behavioral context. However, it doesn't disclose potential limitations like rate limits, authentication needs, or pagination behavior.
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 well-structured with a clear purpose statement followed by Args and Returns sections. It's appropriately sized with no redundant information. The only minor improvement would be integrating the sections more seamlessly, but overall it's efficient and front-loaded.
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 moderate complexity (single parameter, output schema exists), the description is reasonably complete. It explains the purpose, parameter meaning, and return data, and the output schema will handle return value details. It could benefit from more behavioral context, but it covers the essentials adequately.
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?
With 0% schema description coverage for the single parameter 'slug', the description compensates by explaining it as a 'Researcher identifier.' This adds meaningful semantics beyond the schema's generic 'Slug' title. However, it doesn't provide format examples or constraints, leaving some ambiguity.
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 specific action ('Get a researcher's datasets') and resource ('datasets with QIC scores'), distinguishing it from siblings like get_papers or get_repos. It explicitly mentions the QIC scoring methodology, which provides additional specificity beyond a generic dataset retrieval.
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 implies usage context by specifying it retrieves datasets for a researcher, but it doesn't explicitly state when to use this tool versus alternatives like get_papers or list_researchers. No exclusions or prerequisites are mentioned, leaving the agent to infer appropriate scenarios based on the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get geographic affiliations for all researchers in the network.
Returns researchers with their institutional affiliations and coordinates, sourced from ORCID and Semantic Scholar. Useful for understanding the geographic distribution of the research network.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide a title, so the description carries full burden. It discloses data sources ('ORCID and Semantic Scholar') and output content ('institutional affiliations and coordinates'), which is useful behavioral context. However, it lacks details on rate limits, error handling, or whether this is a read-only operation (implied but not stated). 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?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by details on returns and usefulness. Every sentence earns its place by adding clarity without redundancy. It's concise and well-structured for easy comprehension.
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 0 parameters, annotations with only a title, and an output schema (which handles return values), the description is mostly complete. It covers purpose, data sources, and use case. However, it could improve by mentioning if the tool is read-only or has any behavioral constraints, but the output schema likely details the return structure, so this is minor.
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?
There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description adds value by explaining the scope ('all researchers in the network') and data sources, which compensates for the lack of parameters. Baseline for 0 parameters is 4, as it provides necessary context beyond the empty 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?
The description clearly states the tool's purpose: 'Get geographic affiliations for all researchers in the network.' It specifies the verb ('Get'), resource ('geographic affiliations'), and scope ('all researchers in the network'). It distinguishes from siblings like 'get_profile' (individual researcher) and 'list_researchers' (likely just listing names).
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 context: 'Useful for understanding the geographic distribution of the research network.' This indicates when to use it—for geographic analysis—but does not explicitly state when not to use it or name alternatives. For example, it doesn't specify if 'get_context' or 'list_researchers' might be better for non-geographic purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a researcher's publications with citation counts.
Args: slug: Researcher identifier.
Returns papers from Semantic Scholar and Google Scholar (merged, deduplicated) with titles, years, citation counts, and URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide a title, so the description carries the burden of behavioral disclosure. It adds valuable context beyond annotations by specifying data sources (Semantic Scholar and Google Scholar), merging and deduplication processes, and the return format (titles, years, citation counts, URLs). However, it lacks details on rate limits, error handling, 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.
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. Every sentence adds value without redundancy, making it efficient and well-organized for quick understanding.
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 has an output schema, the description need not detail return values, and it adequately covers the input parameter and behavioral context. However, it could be more complete by addressing potential issues like handling invalid slugs or data source availability, but it's sufficient for a read-only tool with good annotations.
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 0%, so the description must compensate. It explains that 'slug' is a 'Researcher identifier', adding meaning beyond the schema's generic 'Slug' title. This clarifies the parameter's purpose, though it could provide more details on format or examples.
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 ('Get') and resource ('a researcher's publications with citation counts'), making the purpose specific. It distinguishes from sibling tools like 'get_profile' or 'list_researchers' by focusing on publications rather than profiles or lists of researchers.
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 implies usage by specifying it retrieves publications for a researcher, but it does not explicitly state when to use this tool versus alternatives like 'get_profile' or 'get_context'. No exclusions or clear alternatives are mentioned, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a researcher's profile with S-Index score and summary metrics.
Args: slug: Researcher identifier (e.g. 'martin-frasch'). Use list_researchers to find valid slugs.
Returns structured profile with S-Index, h-index, paper count, citation count, and links to papers/datasets/repos endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide a title ('Get Researcher Profile'), so the description carries the burden of behavioral disclosure. It describes what the tool returns (structured profile with metrics and links) and mentions a prerequisite (using 'list_researchers' to find slugs), which adds useful context. However, it doesn't cover aspects like error handling, rate limits, or authentication needs. With minimal annotations, the description adds some value but could be more comprehensive.
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 well-structured and front-loaded: the first sentence states the purpose, followed by an 'Args:' section for parameters and a 'Returns:' section for output. Every sentence earns its place, with no wasted words. It's appropriately sized for a single-parameter tool with detailed parameter explanation.
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 low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return values), the description is largely complete. It covers purpose, parameter semantics, and output overview. However, it could improve by mentioning behavioral aspects like error cases (e.g., invalid slug) or linking to sibling tools more explicitly. The output schema reduces the need for return value details.
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 0%, so the description must compensate. It fully explains the single parameter 'slug': defines it as 'Researcher identifier,' provides an example ('martin-frasch'), and specifies how to obtain valid values ('Use list_researchers to find valid slugs'). This adds significant meaning beyond the schema, which only indicates it's a required string titled 'Slug.'
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's purpose: 'Get a researcher's profile with S-Index score and summary metrics.' It specifies the verb ('Get') and resource ('researcher's profile'), but doesn't explicitly differentiate it from sibling tools like 'list_researchers' (which lists researchers) or 'get_papers' (which gets papers). The purpose is clear but lacks sibling differentiation.
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 context on when to use this tool: to retrieve a specific researcher's profile. It mentions 'Use list_researchers to find valid slugs,' which implies an alternative tool for finding slugs, but doesn't explicitly state when not to use this tool or compare it to other profile-related siblings. The guidance is helpful but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a researcher's code repositories with QIC scores.
Args: slug: Researcher identifier.
Returns GitHub repositories with stars, forks, language, and QIC scores computed using FAIR-based quality assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide a title, so the description carries full burden. It discloses the tool fetches GitHub repositories with specific metrics (stars, forks, language, QIC scores) and mentions FAIR-based assessment, but doesn't cover rate limits, authentication needs, or pagination behavior. It adds useful context but leaves 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a purpose statement, Args section, and Returns explanation in just a few sentences. Every sentence adds value, and it's front-loaded with the core functionality.
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 has an output schema (so return values don't need explanation), 1 parameter with partial documentation, and no annotations, the description is reasonably complete. It covers purpose, parameter meaning, and output content, though could benefit from more behavioral details like error handling.
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?
With 0% schema description coverage and 1 parameter, the description compensates well by explaining 'slug' as a 'Researcher identifier' in the Args section, adding meaning beyond the bare schema. However, it doesn't specify format or examples for the slug.
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 ('Get') and resource ('a researcher's code repositories'), specifies the unique QIC score feature, and distinguishes from siblings like get_papers or get_datasets by focusing on code repositories with quality metrics.
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 implies usage for researchers' code repositories with quality assessment, but doesn't explicitly state when to use this vs. alternatives like list_researchers or get_profile. It provides context but lacks explicit guidance on exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all researchers registered on the ResearchTwin platform.
Returns researcher slugs and display names. Use a slug with other tools to explore a specific researcher's profile, papers, datasets, and repositories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided beyond a title, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns ('researcher slugs and display names') and how the output can be used with other tools. It doesn't mention limitations like pagination, rate limits, or permissions, but for a simple list operation with 0 parameters, this is reasonably complete.
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 perfectly concise and well-structured in two short paragraphs. The first sentence states the purpose, the second describes the return format, and the third provides usage guidance. Every sentence earns its place with no wasted words.
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 (0 parameters, no annotations beyond title, but with an output schema), the description is complete enough. It explains what the tool does, what it returns, and how to use the output. With an output schema handling return value documentation, the description doesn't need to detail the response structure further.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't add parameter information, maintaining focus on the tool's purpose and output. A baseline of 4 is applied for tools with no parameters.
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 ('List') and resource ('all researchers registered on the ResearchTwin platform'), making the purpose specific and unambiguous. It distinguishes this tool from siblings by focusing on listing researchers rather than getting specific resources like datasets, papers, or profiles.
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 context for when to use this tool ('to explore a specific researcher's profile, papers, datasets, and repositories') and mentions using the returned slugs with other tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1discoverget_contextget_datasetsget_network_mapget_papersget_profileget_reposlist_researchersEach tool has a clearly distinct purpose with no ambiguity. The tools are well-separated by function: discovery across researchers, getting different types of researcher-specific content (context, datasets, papers, repos, profile), listing researchers, and network mapping. The descriptions explicitly differentiate similar tools like get_context vs get_profile.
All tools follow a consistent verb_noun pattern with clear, descriptive names. The naming convention is perfectly uniform: discover, get_context, get_datasets, get_network_map, get_papers, get_profile, get_repos, list_researchers. Every tool name immediately communicates its function.
With 8 tools, this is well-scoped for a research platform. Each tool earns its place by covering distinct aspects of researcher data exploration: discovery, listing, detailed profiling, and specific content types. The count is appropriate for the domain without being overwhelming or insufficient.
The tool surface provides complete coverage for exploring a research network. It includes discovery across researchers, listing all researchers, comprehensive profiling (both summary and detailed context), and access to all research outputs (papers, datasets, repositories). The network map adds valuable geographic context, creating a well-rounded set with no obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Open scientific and engineering knowledge for AI agents: search, evidence, document publishing.
The open-source talent graph for humans and AI agents. Find developers.
Search 340M+ academic papers — citation graphs, semantic similarity, and AI literature reviews.
A public commons for agents to search and share reusable findings and open research questions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/martinfrasch/researchtwin'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
