Cerebrum

Reception report for a paper

get_reception_report

Read-only

Build the standing reception report for one paper: the citation statement counts Cerebrum holds for it, the reception tallies served via scite.ai, and its retraction status under the multi signal rule, where a paper counts as retracted only when at least two of the three checking channels agree. A clean read prints no retraction line at all, and a status no channel could settle is reported as unknown.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "doi": "<doi>"
    },
    "name": "get_reception_report"
  }
}

Input Schema

Name	Required	Description	Default
`doi`	Yes	The DOI of the paper to report on.

Output Schema

Name	Required	Description	Default
`doi`	Yes
`tallies`	Yes
`retraction`	Yes
`heldSentences`	Yes
`statementCounts`	Yes
`statementsStatus`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), and the description goes well beyond them: it discloses the two-of-three-channel retraction rule, that a clean read omits the retraction line entirely, and that unsettled statuses report as 'unknown'. That is exactly the kind of result-interpretation context an agent needs and cannot get from annotations. It stops short of noting failure behavior when the external scite.ai source is unavailable.

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?

Two sentences, both load-bearing, with the report contents front-loaded before the retraction rule that qualifies them. No filler, no restatement of the tool name, and the output quirks are placed after the scope so the reader gets purpose first and edge cases second.

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?

An output schema exists, so return structure need not be explained, and the description still covers the two non-obvious output behaviors (silent omission when clean, 'unknown' when unsettled). Combined with the annotations, an agent has enough to call it correctly; the only real gap is the lack of routing guidance against get_statements and get_trending.

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% and the single parameter 'doi' is fully documented in the schema, so the baseline applies. The description adds only that the report concerns 'one paper', which is marginal meaning beyond the schema. No format expectations or lookup-failure semantics for the DOI are given.

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?

States a specific verb and resource ('Build the standing reception report for one paper') and enumerates the three components it aggregates: Cerebrum citation statement counts, scite.ai reception tallies, and retraction status. It does not name or contrast with get_statements, even though 'citation statement counts' overlaps that sibling's territory, so an agent cannot fully disambiguate from the description alone.

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?

Usage is only implied: the word 'standing' and the multi-source aggregation suggest this is the composite view to pick when all three signals are wanted, versus a single-signal sibling. There is no explicit when-to-use/when-not statement, no mention of get_statements as the narrower alternative, and no stated prerequisites such as whether the DOI must already be indexed.

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

All Cerebrum tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.