Research Topic Institutions and Authors MCP Server

Find top institutions and authors on a research topic

find_research_topic_institutions_authors

Read-onlyIdempotent

Rank institutions and authors by research output for a topic using OpenAlex data, with ROR/ORCID identifiers, citation counts, h-index, and newest papers.

Instructions

Give a research topic as a keyword or OpenAlex topic ID. Returns one ranked row per institution or author with the most works on it, with ROR, ORCID, total works, citations, h-index, and newest papers on the topic. Data comes from OpenAlex. Pay per event on Apify: 0.006 USD per row.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_research_topic_institutions_authors"
  }
}

Input Schema

Name	Required	Description
`topics`	No	Keywords such as perovskite solar cells, or OpenAlex topic IDs such as T10247, up to 20. Each one gets its own ranked rows.
`to_year`	No	Count works published up to this year. Default no end.
`countries`	No	Two letter codes such as US or DE. Institution rows must be in one of these. Author rows come from works with an institution in one of these, and the author may be elsewhere.
`from_year`	No	Count works published from this year. Default 5 years before the current year.
`row_types`	No	institutions, authors, or both. Default both.
`max_authors`	No	Author rows per topic, up to 200. Default 25.
`search_scope`	No	title_abstract (default): a keyword must be in the title or abstract. fulltext: also the full text where OpenAlex holds it, which matches more and less precisely. Ignored for topic IDs.
`recent_papers`	No	Newest papers on the topic to add to each row, 0 to 10. Default 3. 0 skips them and uses far less of the OpenAlex budget.
`max_charge_usd`	No	Optional. The run stops before a charge that would pass this amount. Summary rows are always returned.
`max_institutions`	No	Institution rows per topic, up to 200. Default 25.
`openalex_api_key`	No	Optional. Your own free key from openalex.org/settings/api, with its own 1 USD a day of OpenAlex usage. Without one, the run shares a 0.10 USD daily budget with everyone on its address and keyword search can be limited. Never stored or logged.
`institution_types`	No	Any of education, healthcare, company, archive, nonprofit, government, facility, funder, other. Institution rows must be one of these. Author rows come from works with such an institution.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, non-destructive, idempotent, open-world traits, so the description's added value is the metered billing model (0.006 USD per row, Apify pay-per-event) and the upstream source (OpenAlex). Those are material behaviors an agent cannot get from the annotations; only the absence of throughput/rate-limit detail keeps it from a 5.

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?

Four tight sentences, front-loaded with the input contract, then the return shape, then provenance and cost. No sentence is filler, though the pricing fragment ('Pay per event on Apify: 0.006 USD per row') is slightly clipped rather than integrated into the flow.

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?

With no output schema and 12 optional parameters, the description usefully enumerates the returned fields so an agent knows what comes back. It omits the API-key/daily-budget tradeoff, but the schema covers that in detail, so what remains missing is minor.

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 coverage is 100%, so every one of the 12 parameters is documented, including the subtle countries and search_scope semantics. The description adds nothing parameter-specific beyond restating that topics can be keywords or topic IDs, which the schema already says, so the baseline 3 applies.

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?

States a concrete input (keyword or OpenAlex topic ID) and a concrete output (one ranked row per institution or author, with named fields like ROR, ORCID, citations, h-index). An agent knows exactly what resource is retrieved and in what shape, with no sibling tools to confuse it.

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 opening sentence implies when to use it (when you have a research topic and want ranked institutions/authors), and the pricing line hints that runs have real cost. But there is no explicit when-not guidance, no mention of alternatives or prerequisite decisions (e.g. when a topic ID is preferable to a keyword), leaving usage largely inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools

find_research_topic_institutions_authorsA