Skip to main content
Glama

Psychedelics Knowledge Graph

get_paper

Get one paper, its credited authors, and its public relationships.

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": {
      "paper_id_or_doi": "<paper_id_or_doi>"
    },
    "name": "get_paper"
  }
}

Input Schema

NameRequiredDescriptionDefault
paper_id_or_doiYes
relationship_limitNo
include_relationshipsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full behavioral burden. It does add meaningful context by scoping relationships to 'public' ones and noting that credited authors are included, but it says nothing about failure modes for unknown IDs/DOIs, permission requirements, or how 'credited' is determined.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though the extreme terseness leaves it slightly under-sized for a three-parameter tool with no annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/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 shape need not be restated, but with zero annotation coverage and zero parameter documentation the definition should explain the relationship flag, the limit cap, and ID/DOI handling. As written, an agent knows what it fetches but not how to configure the fetch.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and none of the three parameters are explained. The phrase 'public relationships' gestures at include_relationships, but the boolean default, the meaning of relationship_limit (default 50), and the accepted formats for paper_id_or_doi are all undocumented.

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 ('Get one paper') plus the payload it returns ('credited authors', 'public relationships'), which distinguishes it from the plural search_papers sibling by scope. It does not explicitly name an alternative, so it stops short of a 5.

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 word 'one paper' implies single-record lookup by identifier versus a search tool, which is weak but usable guidance. There is no explicit statement of when to prefer this over search_papers or get_author_papers, and no prerequisites or exclusions.

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.