Skip to main content
Glama
gscfwid

NCCN Guidelines MCP Server

by gscfwid
OverviewSchemaRelated ServersScoreDiscussions
Python

🏥 NCCN Guidelines MCP Server

Python MCP License Version

PyPDF HTTPX NCCN

A Model Context Protocol (MCP) server that provides access to NCCN (National Comprehensive Cancer Network) clinical guidelines.

🔬 How It Works

This project follows a systematic approach to provide accurate medical guidance:

  1. 🧠 Problem Analysis: Understands the clinical question or scenario

  2. 📋 Guidelines Retrieval: Searches the NCCN index for relevant guidelines

  3. 📄 Page-by-Page Reading: Downloads and extracts specific pages from guidelines

  4. 🎯 Evidence-Based Response: Provides answers based on the extracted content

💡 Note: This system does not use RAG (Retrieval-Augmented Generation) to ensure accuracy. Instead, it reads guidelines directly, which may result in longer response times during index initialization and PDF downloading/reading, but provides more reliable and precise medical guidance.

Related MCP server: Mutation Clinical Trial Matching MCP

✨ Features

  • 📚 Guidelines Index: Automatically fetches and maintains an up-to-date index of NCCN guidelines

  • ⬇️ PDF Download: Downloads NCCN guideline PDFs with authentication support

  • 📝 Content Extraction: Extracts specific pages from PDF documents with layout preservation

  • 🚀 Smart Caching: Index is cached for 7 days to minimize server load

🛠️ Installation

  1. Clone the repository:

git clone https://github.com/gscfwid/NCCN_guidelines_MCP
cd NCCN_guidelines_MCP

  1. Install dependencies using uv:

uv sync

⚙️ Configuration

🔧 Configure Client (Note: Supports only agents, such as Cursor, Cline, Claude desktop, etc.)

⚠️ Important: Claude desktop may warn about insufficient context length when running this MCP.

Add this to your Client configuration:

Configuration with Environment Variables

{
  "mcpServers": {
    "nccn-guidelines": {
      "command": "uv",
      "args": ["--directory", "<abslute_direction_of_NCCN_guidelines_MCP>", "run", "server.py"],
      "env": {
        "NCCN_USERNAME": "<your_nccn_username>",
        "NCCN_PASSWORD": "<your_nccn_password>"
      }
    }
  }
}

⚠️ Important Notes

  • 👤 NCCN Account Registration: Please note that the NCCN username and password mentioned above must be registered on the official NCCN website.

  • 🚀 First-time Setup: When you first start the MCP server, it needs to generate the YAML index of NCCN guidelines. This process takes 1-2 minutes, so please wait before attempting to use the server.

  • ⏱️ Response Times: Due to the non-RAG approach for accuracy, expect longer response times during guideline downloading and PDF reading processes.

💬 Prompts

To have better response, please add the prompt in the file of prompt.md to the instruction of your Agent Client before your Question.

🛠️ Available Tools

  1. 📊 get_index: Get the raw contents of the NCCN guidelines index YAML file.

  2. 📥 download_pdf: Download NCCN guideline PDFs

    • url: PDF URL to download

    • filename (optional): Custom filename

    • username (optional): NCCN login username (defaults to NCCN_USERNAME env var)

    • password (optional): NCCN login password (defaults to NCCN_PASSWORD env var)

  3. 📖 extract_content: Extract content from PDF pages

    • pdf_path: Path to PDF file

    • pages (optional): Comma-separated page numbers (e.g., "1,3,5-7")

💡 Usage Example

Here are some example questions you can ask:

  1. 🔬 What are the available first-line immunotherapy options for ES-SCLC?

  2. 🎯 What is the initial chemotherapy for triple-negative breast cancer?

  3. 🧬 What are the immunotherapy options for neuroendocrine tumors?

Available Tools

3 tools
download_pdfB
Download a PDF file from the specified URL, with optional NCCN login credentials.

Args:
    url: The URL of the PDF file to download
    filename: Optional custom filename for the downloaded file
    username: Optional NCCN username/email for authentication (defaults to NCCN_USERNAME env var)
    password: Optional NCCN password for authentication (defaults to NCCN_PASSWORD env var)

Returns:
    String indicating success/failure and the path to the downloaded file
ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions authentication requirements (NCCN credentials with environment variable fallbacks) and the return value format, which adds useful context beyond basic functionality. However, it lacks details on error handling, network timeouts, file size limits, or whether the operation is idempotent, which are important for a download 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 description is well-structured with a clear opening sentence followed by organized 'Args' and 'Returns' sections. Each sentence adds value, though the parameter explanations could be more concise. The front-loaded purpose statement is effective, but the bullet-point style might be slightly verbose for a tool with schema documentation gaps.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (download with optional auth), no annotations, low schema coverage (0%), but presence of an output schema, the description is partially complete. It covers authentication needs and return format, but lacks details on error cases, performance characteristics, or how it interacts with sibling tools. The output schema existence reduces the need to fully document returns, but other behavioral aspects remain underspecified.

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?

The input schema has 0% description coverage with only one parameter ('url') documented structurally. The description adds semantic meaning for 'url' and introduces three additional parameters ('filename', 'username', 'password') not present in the schema, creating inconsistency. While it explains these parameters' purposes and defaults, the mismatch between schema and description reduces reliability, and it doesn't fully compensate for the schema's lack of documentation.

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?

The description clearly states the action ('Download a PDF file') and resource ('from the specified URL'), with additional context about NCCN login credentials. It distinguishes from sibling tools like 'extract_content' and 'get_index' by focusing on file retrieval rather than content processing or indexing. However, it doesn't explicitly differentiate from potential similar download tools beyond the PDF-specific mention.

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 description implies usage for downloading PDFs from URLs, particularly mentioning NCCN authentication contexts, but doesn't provide explicit guidance on when to use this versus alternatives like 'extract_content' (which might handle PDF content extraction) or general file download tools. No explicit when-not-to-use scenarios or prerequisite conditions are stated beyond the optional authentication parameters.

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

extract_contentA
Extract content from specific pages of a PDF file.

Args:
    pdf_path: Path to the PDF file (relative to the downloads directory or absolute path)
    pages: Comma-separated page numbers to extract (e.g., "1,3,5-7"). 
           If not specified, extracts all pages. Supports negative indexing (-1 for last page).

Returns:
    Extracted text content from the specified pages
ParametersJSON Schema
NameRequiredDescriptionDefault
pdf_pathYes
pagesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the extraction process and return value ('Extracted text content'), but lacks details on error handling, performance limits, or authentication needs. It does not contradict annotations, but offers only basic operational context.

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 description is well-structured with a clear purpose statement, parameter explanations, and return value. It is front-loaded and efficient, though the parameter details could be slightly more concise. Every sentence adds value without redundancy.

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?

Given the tool's moderate complexity, no annotations, and an output schema present, the description is fairly complete. It covers purpose, parameters, and returns, but lacks usage guidelines and deeper behavioral context. The output schema reduces the need to explain return values in detail.

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

Parameters5/5

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

The description adds significant meaning beyond the input schema, which has 0% description coverage. It clarifies 'pdf_path' as a path relative to downloads or absolute, and details 'pages' with examples, default behavior, and support for negative indexing. This fully compensates for the schema's lack of descriptions.

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?

The description clearly states the tool's purpose: 'Extract content from specific pages of a PDF file.' It specifies the verb ('extract') and resource ('content from PDF'), but does not explicitly differentiate from sibling tools like 'download_pdf' or 'get_index', which likely serve different purposes (downloading files and indexing content).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions that pages can be specified or all pages extracted, but does not indicate scenarios where this tool is preferred over siblings like 'get_index' or 'download_pdf', nor does it outline prerequisites or exclusions.

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

get_indexA
Get the raw contents of the NCCN guidelines index YAML file.

Returns:
    String containing the raw YAML content of the guidelines index
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the return type (raw YAML content as a string) and that it fetches from a specific file, which is useful context. However, it doesn't mention behavioral traits like error handling, performance, or any constraints (e.g., file size limits, authentication needs). The description adds some value but lacks comprehensive behavioral details.

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?

The description is front-loaded with the core purpose in the first sentence, followed by a clear return statement. Both sentences earn their place by providing essential information without redundancy. It's appropriately sized and structured for a simple tool with no parameters.

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?

Given the tool's simplicity (0 parameters, no annotations, but has an output schema), the description is mostly complete. It explains what the tool does and the return value, which is sufficient since the output schema likely covers return details. However, it could benefit from more behavioral context (e.g., any limitations or dependencies) to be fully comprehensive.

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

Parameters4/5

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

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately focuses on the tool's purpose and output. A baseline of 4 is applied as per the rules for zero parameters.

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?

The description clearly states the specific action ('Get the raw contents') and resource ('NCCN guidelines index YAML file'), distinguishing it from sibling tools like download_pdf and extract_content which handle different operations on different resources. It precisely communicates what the tool does without ambiguity.

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 description implies usage by specifying the resource (NCCN guidelines index YAML file), suggesting it's for accessing this particular data. However, it lacks explicit guidance on when to use this tool versus alternatives like extract_content, which might process the content, or download_pdf for PDF files. No exclusions or prerequisites are mentioned.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: download_pdf handles file retrieval, extract_content processes PDF pages for text, and get_index fetches metadata. The descriptions clearly differentiate these operations, eliminating any potential for misselection.

Naming Consistency5/5

All three tools follow a consistent verb_noun pattern (download_pdf, extract_content, get_index) with clear, descriptive names. There are no deviations in style or convention, making the set predictable and easy to understand.

Tool Count3/5

With only 3 tools, the set feels thin for a guidelines server, potentially lacking operations like search, filtering, or guideline-specific queries. While the tools cover basic PDF handling and index access, the scope suggests more could be needed for comprehensive agent workflows.

Completeness3/5

The tools provide core PDF download and content extraction, plus index access, but there are notable gaps for a guidelines domain: no tools to search, list, or retrieve specific guidelines by criteria, and no update or management functions. This limits agent capabilities beyond basic file operations.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gscfwid/NCCN_guidelines_MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server