Skip to main content
Glama

Count research papers

count_papers
Read-onlyIdempotent

Count papers matching filters, including linkedTrialRegistrationNumbers for curated relatedTrials links and accessTypes with canonical values 'open' or 'paywall'. With orderBy:'relevantInfluential', both count and sample use the same primary title-or-summary subject cohort before citation ranking. Returns { count: , sample: <top 5 representative papers for citation> }. Use for 'how many papers...?' / 'how often...?' questions. For 'top journals', 'papers per year', or 'study-design distribution' use aggregate_papers instead.

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": "count_papers"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
queryNo
dateToNo
topicsNoTopic slugs (e.g. "depressive-disorders", "ocd"). Common abbreviations like "PTSD", "TRD", "OCD" and short names like "depression", "anxiety" are auto-mapped to canonical slugs.
orderByNoSort order. "relevance" = best text match (default), "date" = newest first; use date for "latest"/"recent"/"new" questions. "citations" = most-cited first. "relevantInfluential" = citation-ranked papers that first qualify by the primary title-or-summary subject pattern; use only after the user confirms a subject axis for influential-literature discovery.relevance
dateFromNo
compoundsNoCompound slugs (e.g. "psilocybin", "mdma"). Street names ("shrooms", "ecstasy") and brand/program names ("COMP360", "MM-120") are auto-mapped.
accessTypesNoCanonical paper access status. Use ["open"] for open-access papers or ["paywall"] for paywalled / subscription-only papers.
authorSlugsNo
journalSlugNo
studyDesignNo"meta" = meta-analyses/reviews; "individual" = primary studies
linkedTrialSlugsNoSlugs of trials this paper is linked to (relatedTrials[]). Use to find papers from a specific trial.
outcomeMeasureSlugsNoSlugs of clinical / mental-health rating scales used as outcome measures (e.g. "beck-depression-inventory", "madrs", "y-bocs"). Common abbreviations like "BDI", "MADRS", "PHQ-9", "GAD-7", "Y-BOCS", "PCL-5", "MEQ-30" are auto-mapped.
linkedTrialRegistrationNumbersNoExact ClinicalTrials.gov IDs of trials linked through curated relatedTrials references (for example NCT03537014).

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare this as a safe, read-only, idempotent count operation. The description adds meaningful behavior beyond that: for orderBy:'relevantInfluential', count and sample share the same primary title-or-summary cohort before citation ranking, and the sample is the top 5 representative papers for citation. It does not discuss limits or rate behavior, but those are not central for a read-only count 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/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, followed by the special relevantInfluential behavior, return shape, and explicit alternative routing. It is efficient, though the return-shape sentence is somewhat redundant given the output schema and could be shortened.

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?

For a 14-parameter read-only count tool with an output schema and safety annotations, the description provides enough routing and behavioral context to call it correctly. The main gap is that many filter parameters rely on schema documentation rather than the description, which is acceptable but not fully comprehensive.

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 57%, so several parameters are documented only partially or not at all. The description clarifies linkedTrialRegistrationNumbers as curated relatedTrials links and repeats accessTypes canonical values, but it does not compensate for the remaining undocumented filters such as limit, date ranges, and author/journal filters.

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 the specific verb-resource pair (count papers) and immediately frames it around filters. It explicitly distinguishes itself from the sibling aggregate_papers tool for other aggregation questions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use guidance with quoted question patterns ('how many papers...?' / 'how often...?') and names the alternative aggregate_papers for 'top journals', 'papers per year', and 'study-design distribution'.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources