How do I use NGSS MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NGSS MCP Server show me all physical science standards for middle school" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

NGSS MCP Server

by Sallvainian

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

NGSS MCP Server

npm version License: ISC

Status: ✅ v1.2.2 Published to npm

⚠️ Middle School Standards Only This MCP server provides access to NGSS Middle School (MS) standards only. It does not include Elementary (K-5) or High School (HS) standards.

Model Context Protocol (MCP) server providing programmatic access to Next Generation Science Standards (NGSS) for middle school education.

What's New in v1.2.2

Platform-Specific Configurations: Fixed MCP server configurations for macOS/Linux, Windows, and WSL
- macOS/Linux: Direct npx command
- Windows: cmd /c npx wrapper
- WSL: wsl npx command
Installation Options: Four clear installation methods (npm, MCP config, Smithery, Docker)
Smithery Deployment: Fixed module field for TypeScript runtime support
Docker Support: Comprehensive Docker installation documentation

See full release history in CHANGELOG.md

Related MCP server: Skolverket MCP Server

Features

55 Middle School Standards: Complete coverage of NGSS middle school standards
3D Framework Support: Full Science & Engineering Practices (SEP), Disciplinary Core Ideas (DCI), and Crosscutting Concepts (CCC)
Multi-Index Database: Optimized O(1) lookups by code, domain filtering, and relevance-scored search
High-Performance Caching: LRU cache with TTL for 60x faster repeated queries
Performance Metrics: Real-time query performance tracking and cache statistics
Input Validation: Comprehensive validation and sanitization for all query parameters
8 Powerful Tools: Comprehensive API for standard lookup, search, filtering, and unit planning
MCP Protocol: Native integration with Claude Desktop, Continue, and other MCP-compatible AI assistants

Database Statistics

Total Standards: 55
Physical Science: 19 standards
Life Science: 21 standards
Earth & Space Science: 15 standards
Database Size: 80 KB (optimized)
Index Sizes: 55 codes, 3 domains, 343 full-text keywords

Installation

Option A: Install from npm

Install via npm:

npm install ngss-mcp

Or with a specific version:

npm install ngss-mcp@1.0.0

Or install globally:

npm install -g ngss-mcp

Prerequisites:

Node.js 18+ or Bun runtime
npm or bun package manager

Option B: Configure as MCP Server

Add to your MCP configuration file:

macOS/Linux:

{
  "mcpServers": {
    "ngss": {
      "command": "npx",
      "args": ["-y", "ngss-mcp"]
    }
  }
}

Windows:

{
  "mcpServers": {
    "ngss": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "ngss-mcp"]
    }
  }
}

WSL:

{
  "mcpServers": {
    "ngss": {
      "command": "wsl",
      "args": ["npx", "-y", "ngss-mcp"]
    }
  }
}

Option C: Install via Smithery

Install directly from Smithery to use with Claude Desktop or other MCP clients:

npx -y @smithery/cli install @sallvainian/ngss-mcp --client claude

This will automatically configure the server in your Claude Desktop settings.

Option D: Install via Docker

Run the MCP server in a Docker container for isolated, reproducible deployments.

Using Docker Compose (recommended):

Create a docker-compose.yml file:

version: '3.8'
services:
  ngss-mcp:
    image: node:18-alpine
    working_dir: /app
    command: npx -y ngss-mcp
    stdin_open: true
    tty: true
    volumes:
      - ngss-data:/root/.npm
volumes:
  ngss-data:

Then run:

docker-compose up -d

Using Dockerfile:

Create a Dockerfile:

FROM node:18-alpine

WORKDIR /app

# Install the MCP server globally
RUN npm install -g ngss-mcp

# Expose stdio for MCP protocol
CMD ["ngss-mcp"]

Build and run:

docker build -t ngss-mcp .
docker run -i ngss-mcp

Claude Desktop Configuration for Docker:

{
  "mcpServers": {
    "ngss": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "ngss-mcp"]
    }
  }
}

Install from Source

# Clone repository
git clone <repository-url>
cd NGSS-MCP

# Install dependencies
bun install  # or npm install

# Build TypeScript
bun run build  # or npm run build

Available Tools

1. `get_standard`

Retrieve a specific NGSS standard by its code identifier.

Input:

{
  "code": "MS-PS1-1"
}

Output:

{
  "code": "MS-PS1-1",
  "grade_level": "MS",
  "domain": "Physical Science",
  "topic": "Structure and Properties of Matter",
  "performance_expectation": "Develop models to describe the atomic composition of simple molecules and extended structures.",
  "sep": {
    "code": "SEP-1",
    "name": "Develop a model to predict and/or describe phenomena.",
    "description": "Science and Engineering Practices Developing and Using Models..."
  },
  "dci": {
    "code": "PS1.A",
    "name": "Structure and Properties of Matter",
    "description": "Disciplinary Core Ideas..."
  },
  "ccc": {
    "code": "CCC-1",
    "name": "Patterns can be used to identify cause and effect relationships.",
    "description": "Crosscutting Concepts..."
  },
  "keywords": ["develop", "model", "describe", "atomic", "composition", "molecules"],
  "lesson_scope": {
    "key_concepts": [...],
    "prerequisite_knowledge": [],
    "common_misconceptions": [],
    "depth_boundaries": {"include": [], "exclude": []}
  }
}

Valid Code Format: MS-(PS|LS|ESS)\d+-\d+

MS-PS1-1 through MS-PS4-3 (Physical Science)
MS-LS1-1 through MS-LS4-6 (Life Science)
MS-ESS1-1 through MS-ESS3-5 (Earth & Space Science)

2. `search_by_domain`

Find all NGSS standards in a specific science domain.

Input:

{
  "domain": "Physical Science"
}

Accepted Values:

"Physical Science" or "physical-science"
"Life Science" or "life-science"
"Earth and Space Science" or "earth-space-science"

Output:

{
  "domain": "Physical Science",
  "count": 19,
  "standards": [
    {
      "code": "MS-PS1-1",
      "topic": "Structure and Properties of Matter",
      "performance_expectation": "Develop models to describe the atomic composition..."
    }
  ]
}

3. `get_3d_components`

Extract the three-dimensional learning components for a specific standard.

Input:

{
  "code": "MS-LS2-1"
}

Output:

{
  "code": "MS-LS2-1",
  "framework_components": {
    "Science and Engineering Practices (SEP)": {
      "code": "SEP-1",
      "name": "Analyze and interpret data to provide evidence...",
      "description": "Science and Engineering Practices..."
    },
    "Disciplinary Core Ideas (DCI)": {
      "code": "LS2.A",
      "name": "Interdependent Relationships in Ecosystems",
      "description": "Disciplinary Core Ideas..."
    },
    "Crosscutting Concepts (CCC)": {
      "code": "CCC-1",
      "name": "Patterns can be used to identify cause and effect...",
      "description": "Crosscutting Concepts..."
    }
  }
}

3D Framework Components:

SEP: Science & Engineering Practices - What scientists and engineers do
DCI: Disciplinary Core Ideas - Key concepts to understand
CCC: Crosscutting Concepts - Themes that connect across disciplines

4. `search_standards`

Perform full-text search across all NGSS standard content.

Input:

{
  "query": "ecosystem interactions",
  "domain": "Life Science",
  "limit": 5
}

Parameters:

query (required): Search text (min 2 characters)
domain (optional): Filter by domain
limit (optional): Maximum results (default: 10, must be positive integer)

Output:

{
  "query": "ecosystem interactions",
  "domain": "Life Science",
  "totalMatches": 3,
  "results": [
    {
      "code": "MS-LS2-2",
      "domain": "Life Science",
      "topic": "Ecosystems: Interactions, Energy, and Dynamics",
      "relevance": 0.89,
      "performance_expectation": "Construct an explanation that predicts patterns...",
      "keywords": ["construct", "explanation", "predicts", "patterns", "interactions"]
    }
  ]
}

Search Scope:

Performance expectations
Topics
Keywords
All 3D components (SEP, DCI, CCC)

5. `search_by_practice`

Filter NGSS standards by Science & Engineering Practices (SEP).

Input:

{
  "practice": "Developing and Using Models",
  "detail_level": "minimal"
}

Valid SEP Values (10 options):

"Asking Questions and Defining Problems"
"Developing and Using Models"
"Planning and Carrying Out Investigations"
"Analyzing and Interpreting Data"
"Using Mathematics and Computational Thinking"
"Constructing Explanations and Designing Solutions"
"Engaging in Argument from Evidence"
"Obtaining, Evaluating, and Communicating Information"
"Define the Criteria and Constraints of a Design Problem"
"Unknown"

Output:

{
  "practice": "Developing and Using Models",
  "total": 8,
  "standards": [
    {
      "code": "MS-PS1-1",
      "topic": "Structure and Properties of Matter",
      "performance_expectation": "Develop models to describe..."
    }
  ]
}

6. `search_by_crosscutting_concept`

Filter NGSS standards by Crosscutting Concepts (CCC).

Input:

{
  "concept": "Patterns",
  "detail_level": "minimal"
}

Valid CCC Values (8 options):

"Patterns"
"Cause and Effect"
"Scale, Proportion, and Quantity"
"Systems and System Models"
"Energy and Matter"
"Structure and Function"
"Stability and Change"
"Unknown"

Output:

{
  "concept": "Patterns",
  "total": 6,
  "standards": [
    {
      "code": "MS-LS2-2",
      "topic": "Ecosystems: Interactions, Energy, and Dynamics",
      "performance_expectation": "Construct an explanation..."
    }
  ]
}

7. `search_by_disciplinary_core_idea`

Filter NGSS standards by Disciplinary Core Ideas (DCI).

Input:

{
  "dci": "Definitions of Energy",
  "detail_level": "minimal"
}

Valid DCI Values (14 options):

"Definitions of Energy"
"Earth's Materials and Systems"
"Evidence of Common Ancestry and Diversity"
"Forces and Motion"
"Growth and Development of Organisms"
"Interdependent Relationships in Ecosystems"
"Natural Hazards"
"Organization for Matter and Energy Flow in Organisms"
"Structure and Function"
"Structure and Properties of Matter"
"The History of Planet Earth"
"The Universe and Its Stars"
"Wave Properties"
"Weather and Climate"

Output:

{
  "dci": "Definitions of Energy",
  "total": 4,
  "standards": [
    {
      "code": "MS-PS3-1",
      "topic": "Energy",
      "performance_expectation": "Construct and interpret graphical displays..."
    }
  ]
}

8. `get_3d_components`

(Renumbered from Tool 3 - functionality unchanged)

9. `get_unit_suggestions`

Get intelligent curriculum unit suggestions based on an anchor standard, using binary compatibility scoring across domain, SEP, CCC, and DCI dimensions.

Input:

{
  "anchor_standard": "MS-PS1-1",
  "unit_size": 5,
  "detail_level": "minimal"
}

Parameters:

anchor_standard (required): Standard code to base suggestions on
unit_size (optional): Total standards in unit including anchor (default: 5, range: 2-8)
detail_level (optional): Response detail level (minimal/summary/full)

Output:

{
  "anchor": {
    "code": "MS-PS1-1",
    "domain": "Physical Science",
    "topic": "Structure and Properties of Matter"
  },
  "unit_size": 5,
  "suggestions": [
    {
      "code": "MS-PS1-2",
      "compatibility_score": 8,
      "domain_match": true,
      "sep_match": true,
      "ccc_match": true,
      "dci_match": true
    }
  ]
}

Compatibility Scoring (Binary Matching per ADR-001):

Domain Match: +3 points (same science domain as anchor)
SEP Match: +2 points (same Science & Engineering Practice)
CCC Match: +2 points (same Crosscutting Concept)
DCI Match: +1 point (same Disciplinary Core Idea)
Maximum Score: 8 points (perfect alignment across all dimensions)

Use Cases:

Curriculum planning: Build thematically coherent units
Cross-domain exploration: Discover connections between science domains
Differentiation: Find standards with varying complexity levels
Unit sequencing: Identify logical progressions of concepts

Data Model (ADR-001)

The NGSS-MCP server uses a single-object data model for 3D framework components:

Each standard has ONE sep object: standard.sep.name
Each standard has ONE ccc object: standard.ccc.name
Each standard has ONE dci object: standard.dci.name

This ensures consistent data structure and simplifies filtering operations. See docs/adr/001-use-single-object-3d-framework-structure.md for details.

Error Handling

All tools return structured error responses with isError: true:

{
  "error": "Not Found",
  "message": "Standard MS-PS1-99 does not exist in the database",
  "code": "STANDARD_NOT_FOUND"
}

Error Codes:

STANDARD_NOT_FOUND: Requested standard code doesn't exist
INTERNAL_ERROR: Server error (database not initialized, parsing error, etc.)

Development

Project Structure

NGSS-MCP/
├── src/
│   ├── server/
│   │   ├── index.ts              # MCP server with 8 tools
│   │   ├── database.ts           # Multi-index database with caching
│   │   ├── query-cache.ts        # LRU cache with TTL and metrics
│   │   └── query-validation.ts   # Input validation and sanitization
│   │   └── integration.test.ts   # 87 comprehensive tests (100% coverage)
│   ├── constants/
│   │   └── enum-values.ts        # SEP and CCC enum values
│   ├── extraction/               # PDF extraction utilities
│   └── types/
│       └── ngss.ts               # Type definitions
├── scripts/
│   ├── test-query-interface.ts   # Comprehensive test suite
│   └── test-cache-performance.ts # Cache effectiveness validation
├── data/
│   └── ngss-ms-standards.json    # Extracted standards database
├── dist/                         # Compiled JavaScript
├── docs/
│   ├── adr/                      # Architecture Decision Records
│   │   └── 001-use-single-object-3d-framework-structure.md
│   └── Middle School By Topic NGSS.pdf

Build Commands

# Compile TypeScript
bun run build

# Development mode (watch)
bun run dev

# Extract standards from PDF (requires pdf-extraction MCP)
bun run build-data

# Test PDF extraction
bun test

Testing

# Run comprehensive query interface tests (32 tests)
bun run scripts/test-query-interface.ts

# Test cache performance and effectiveness
bun run scripts/test-cache-performance.ts

Test Coverage:

✅ All 8 MCP tools (comprehensive integration tests)
✅ Data validation (ADR-001 compliance: SEP/CCC/DCI single objects)
✅ Backward compatibility (Tools 1-4 unchanged from v1.0.1)
✅ Tool regression (Tools 5, 6, 8 smoke tests)
✅ Input validation and error handling
✅ Cache effectiveness (60x speedup verification)
✅ Performance stress testing (100+ queries)
✅ Edge cases and boundary conditions
✅ 87 total test cases, 100% pass rate, 100% code coverage

Architecture

Database Module (database.ts):

Code Index: Map<string, Standard> - O(1) lookups by standard code
Domain Index: Map<string, Standard[]> - Grouped by science domain
Full-Text Index: Map<string, Set<string>> - Comprehensive search
Query Cache: LRU cache with TTL for search result caching
Performance Metrics: Real-time query statistics and timing
Input Validation: Integrated validation for all query parameters

Query Cache Module (query-cache.ts):

QueryCache Class: Generic LRU cache with TTL expiration
Cache Metrics: Hits, misses, evictions, hit rate tracking
LRU Eviction: Automatic removal of least recently used entries
TTL Management: Automatic expiration of stale entries
Detailed Statistics: Top entries and age tracking
Cache Key Generation: Deterministic key creation from parameters

Query Validation Module (query-validation.ts):

QueryValidator Class: Static validation methods for all input types
Format Validation: Standard code, domain, query string checks
Range Validation: Limit parameter bounds checking
Security Validation: Injection pattern detection and sanitization
Sanitization: Text cleaning and normalization
Error Messages: Clear, actionable validation error messages

MCP Server (index.ts):

High-level McpServer class from @modelcontextprotocol/sdk
Zod schema validation for all tool inputs
Graceful shutdown handling (SIGINT/SIGTERM)
StdioServerTransport for MCP protocol communication
Error handling with structured responses

Data Quality

✅ 100% 3D Completeness: All standards include SEP, DCI, and CCC components
✅ Valid Standard Codes: All codes match pattern MS-(PS|LS|ESS)\d+-\d+
✅ Clean Text: No embedded newlines or control characters
✅ Complete Topics: Full topic names (e.g., "Structure and Properties of Matter")

Source Data

PDF Source: Middle School By Topic NGSS.pdf (3.6 MB)
Extraction Method: Pattern-based extraction via pdf-extraction MCP server
Generated: October 15, 2025
Validation: Schema-validated with Zod, 100% completeness verified

License

MIT

Contributing

Contributions welcome! Please ensure:

TypeScript strict mode compliance
Zod schema validation for new inputs
Test coverage for new features
Documentation updates for API changes

Support

For issues, questions, or feature requests, please open an issue on the repository.

Performance

Query Caching:

LRU Cache: 100-entry capacity with intelligent eviction
TTL Expiration: 5-minute Time-To-Live for cached results
Cache Hit Rate: 79-90% in typical usage patterns
Speed Improvement: 60x faster average for cached queries
- searchStandards: 64x speedup (0.16ms → 0.002ms)
- Domain-filtered search: 10x speedup (0.04ms → 0.004ms)

Query Performance:

Code lookups: <0.01ms (O(1))
Domain searches: <0.05ms
Keyword searches: 0.01-0.20ms (first query)
Cached queries: 0.002-0.005ms
Stress test: 100 lookups in 0.04ms (0.0004ms per lookup)

Performance Metrics API:

Real-time query statistics via getQueryMetrics()
Cache statistics via getCacheStats()
Per-method performance tracking
Hit rate and eviction monitoring

Input Validation

All query methods include comprehensive validation:

Validation Rules:

Standard Codes: Must match format MS-(PS|LS|ESS)\d+-\d+
Domains: Must be one of: Physical Science, Life Science, Earth and Space Science
Query Strings: 1-500 characters, sanitized for security
Limit Parameters: 1-100 (positive integers only)
Injection Protection: Blocks suspicious patterns and control characters

Validation Errors: Throw descriptive errors with clear messages:

// Invalid standard code
Error: Invalid standard code format. Expected: MS-{PS|LS|ESS}{number}-{number}

// Invalid domain
Error: Invalid domain. Must be one of: Physical Science, Life Science, Earth and Space Science

// Invalid limit
Error: Limit cannot exceed 100

// Empty query
Error: Query must be at least 1 character

Benefits:

Prevents malformed requests
Clear error messaging
Security hardening against injection
Input sanitization for all text fields

Available Tools

8 tools

get_3d_componentsGet 3D Framework ComponentsB

Extract the three-dimensional learning components (SEP: Science and Engineering Practices, DCI: Disciplinary Core Ideas, CCC: Crosscutting Concepts) for a specific standard (e.g., MS-PS1-1, MS-LS2-3, MS-ESS3-1)

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	NGSS standard code (format: MS-{PS\|LS\|ESS}{number}-{number})
`detail_level`	No	Response detail level: minimal (code, topic, PE 50 chars), summary (+ keywords top 3, PE 150 chars), full (complete standard)	full

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are present, but the description implies a read-only operation via 'Extract'. However, it does not disclose any behavioral traits such as performance characteristics, error handling, or data freshness.

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 a single sentence that is front-loaded with the verb and resource. It is concise but could benefit from a more structured listing of the three components.

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 no output schema, the description does not explain the return format or response fields. It covers the main purpose but lacks completeness for a tool with only two parameters and no annotations.

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 the description adds no additional meaning beyond what the schema already provides for the two parameters. The description does not mention the 'detail_level' parameter or its values.

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 explicitly states the verb 'Extract' and the resource 'three-dimensional learning components for a specific standard', with concrete examples. It clearly differentiates from siblings like search_by_* and get_standard.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., get_standard which might also return 3D components). 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.

get_standardGet NGSS Standard by CodeA

Retrieve a specific NGSS standard by its code identifier (e.g., MS-PS1-1, MS-LS2-3, MS-ESS3-1)

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	NGSS standard code (format: MS-{PS\|LS\|ESS}{number}-{number})
`detail_level`	No	Response detail level: minimal (code, topic, PE 50 chars), summary (+ keywords top 3, PE 150 chars), full (complete standard)	full

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It states 'Retrieve,' indicating a read-only operation, but does not disclose error behavior (e.g., invalid code), authorization needs, or rate limits. The description is minimal but not misleading.

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?

A single focused sentence that is front-loaded with the action and object. No unnecessary words or repetition. Every token serves a purpose.

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 no output schema, the description does not explain the return format or what 'full' entails. For a tool with two parameters and potential variations in detail_level, more context on output structure would improve completeness.

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?

Schema coverage is 100%, but the description adds value by providing concrete code examples that illustrate valid inputs (e.g., MS-PS1-1). This goes beyond the schema's pattern and description, making parameter usage clearer.

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 verb ('Retrieve') and resource ('specific NGSS standard'), and uniquely identifies it by code identifier with concrete examples (e.g., MS-PS1-1). This distinguishes it from sibling search tools and get_3d_components.

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 when you have a known code, but does not explicitly guide when to use this tool versus search alternatives or mention prerequisites. Sibling tools like search_standards are not referenced, so guidance is only implicit.

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

get_unit_suggestionsGet Unit Planning SuggestionsA

Recommend compatible NGSS standards for curriculum unit planning based on 3D framework overlap (domain, SEP, DCI, CCC). Example: Given anchor "MS-PS3-1" (energy), suggest 2-7 compatible standards that share similar practices, concepts, or disciplinary ideas for a cohesive unit

ParametersJSON Schema

Name	Required	Description	Default
`anchor_code`	Yes	The anchor NGSS standard code (e.g., "MS-PS3-1")
`unit_size`	No	Total number of standards in the unit (2-8), including the anchor
`detail_level`	No	Response detail level: minimal (code, topic, PE 50 chars), summary (+ keywords top 3, PE 150 chars), full (complete standard)	summary

TDQS

A4.2/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 full burden. It mentions the tool suggests standards based on overlap, implying a read-only operation, but does not explicitly disclose behavioral traits such as no side effects, authentication needs, or rate limits. The example adds context but not comprehensive disclosure.

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 consists of two sentences: one stating purpose and one providing a detailed example. It is extremely concise, front-loaded with the main action, and contains no redundant information.

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, the description could do more to specify return structure, but it does outline detail_level options implicitly. Given sibling tools handle different queries, this tool's role is well contextualized. The example fills some gaps, making it reasonably complete.

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?

Schema coverage is 100%, so baseline is 3. The description adds value by giving a concrete example of parameter usage (anchor_code 'MS-PS3-1' and unit_size implied as 2-7) and clarifying the output (compatible standards), which enhances understanding beyond the schema's short descriptions.

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 tool's action ('Recommend compatible NGSS standards') and resource ('for curriculum unit planning'), with specific reference to 3D framework overlap (domain, SEP, DCI, CCC). It distinguishes itself from sibling tools that search or get individual components by focusing on suggestions for unit coherence.

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

Usage Guidelines4/5

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

The description includes an example with anchor 'MS-PS3-1', illustrating input usage and expected output size (2-7 compatible standards). It implicitly guides when to use (unit planning around an anchor), but does not explicitly state when not to use or mention alternative sibling tools.

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

search_by_crosscutting_conceptSearch Standards by Crosscutting ConceptB

Find all NGSS standards using a specific Crosscutting Concept (CCC). Examples: "Patterns", "Cause and Effect", "Systems and System Models", "Energy and Matter"

ParametersJSON Schema

Name	Required	Description	Default
`concept`	Yes	Crosscutting Concept name
`detail_level`	No	Response detail level: minimal (code, topic, PE 50 chars), summary (+ keywords top 3, PE 150 chars), full (complete standard)	full

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, and the description lacks details such as read-only behavior, return format, pagination, or authentication needs. For a search tool, it fails to disclose whether it returns a list or single item, or how results are ordered.

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 a single sentence followed by examples, which is concise and front-loaded. It could be slightly more efficient by integrating examples into a shorter phrase, but it remains clear and avoids fluff.

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?

For a two-parameter tool with enums, the description provides enough context for typical use. However, without an output schema, it omits details about the structure of the returned standards (e.g., whether full text is included). The lack of explicit mention of list versus single item or sorting is a minor gap.

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 description coverage is 100%, so baseline is 3. The description adds examples of CCC names, but they don't exactly match the enum values in the schema (full sentence descriptions vs. short names), which could cause confusion. The parameter semantics are not significantly enhanced beyond the schema.

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 verb 'find' and resource 'NGSS standards' filtered by a specific Crosscutting Concept (CCC). It distinguishes from sibling tools like search_by_practice or search_by_domain, as each targets a different dimension of standards.

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 when a CCC is known, but it does not explicitly guide when to use this tool vs. alternatives like search_by_disciplinary_core_idea. There are no exclusions or when-not conditions.

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

search_by_disciplinary_core_ideaSearch Standards by Disciplinary Core IdeaA

Find all NGSS standards using a specific Disciplinary Core Idea (DCI). Examples: "Definitions of Energy", "Interdependent Relationships in Ecosystems", "Weather and Climate"

ParametersJSON Schema

Name	Required	Description	Default
`dci`	Yes	Disciplinary Core Idea name
`detail_level`	No	Response detail level: minimal (code, topic, PE 50 chars), summary (+ keywords top 3, PE 150 chars), full (complete standard)	full

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states 'find all NGSS standards' indicating a read operation, but lacks details on response structure, pagination, rate limits, or error handling. The description adds little beyond the purpose.

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 a single clear sentence followed by relevant examples. No extraneous information, front-loaded with the core purpose. Every element earns its place.

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?

For a simple filter tool with 2 parameters and no output schema, the description covers the basic purpose and provides examples. However, it lacks detail on return format, pagination behavior, or potential limits. It is adequate but leaves gaps for a complete understanding.

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?

Input schema has 100% coverage with full descriptions and enums for both parameters. The description provides example DCI values but these duplicate the enum list, adding no new meaning. Baseline 3 is appropriate given the schema already defines semantics clearly.

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 uses a specific verb 'find' and resource 'NGSS standards' with a clear filtering criterion 'by Disciplinary Core Idea (DCI)'. Examples further clarify the DCI values. It distinguishes from sibling tools like search_by_crosscutting_concept and search_by_practice.

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 use when a specific DCI is known but provides no explicit guidance on when not to use this tool or how it compares to alternatives like search_by_practice. Without exclusions or context, the usage scope is only implied.

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

search_by_domainSearch Standards by DomainB

Find all NGSS standards in a specific science domain (Physical Science, Life Science, or Earth and Space Science)

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Science domain to filter by
`offset`	No	Number of results to skip (for pagination)
`limit`	No	Maximum number of results to return (1-50)
`detail_level`	No	Response detail level: minimal (code, topic, PE 50 chars), summary (+ keywords top 3, PE 150 chars), full (complete standard)	full

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, and the description only states the purpose. It does not disclose behavioral traits such as read-only nature, side effects, or require permissions. As a search tool, read-only is implied but not explicit.

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 a single, clear sentence with no wasted words. It is well front-loaded with the purpose.

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?

The schema provides detailed parameter descriptions including enum values and defaults. However, there is no output schema, and the description does not explain the return format or behavior like pagination beyond what is in the schema. Some context is missing.

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?

Input schema has 100% description coverage for all 4 parameters. The description adds no additional meaning beyond the schema's parameter descriptions, so baseline 3 is appropriate.

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 'Find all NGSS standards in a specific science domain' with explicit values (Physical Science, Life Science, Earth and Space Science). It uses a specific verb and resource, and distinguishes from sibling tools like search_by_practice which filter by other criteria.

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 when to use (filter by domain) but does not explicitly state when not to use or mention alternative tools. With multiple sibling search tools, more explicit guidance would improve selection.

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

search_by_practiceSearch Standards by Science and Engineering PracticeA

Find all NGSS standards using a specific Science and Engineering Practice (SEP). Examples: "Developing and Using Models", "Analyzing and Interpreting Data", "Planning and Carrying Out Investigations"

ParametersJSON Schema

Name	Required	Description	Default
`practice`	Yes	Science and Engineering Practice name
`detail_level`	No	Response detail level: minimal (code, topic, PE 50 chars), summary (+ keywords top 3, PE 150 chars), full (complete standard)	full

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as pagination, error handling, or required scopes. It only describes the basic search action without detailing what happens on no results or limits.

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 one concise sentence with examples, front-loading the key action and resource. No unnecessary words.

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 simple two-parameter tool with a clear purpose, the description is mostly complete. It could mention the effect of detail_level briefly, but the schema already provides that information. Lacks guidance on response format.

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 description adds no additional parameter meaning beyond the schema's enum values and descriptions. The examples are shorter but do not clarify the exact format required.

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 it finds NGSS standards by a specific Science and Engineering Practice, with concrete examples distinguishing it from sibling tools that search by other criteria like crosscutting concepts or disciplinary core ideas.

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 via examples but does not explicitly state when to use this tool over alternatives or provide exclusions. No guidance on when not to use.

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

search_standardsSearch Standards (Full-Text)A

Perform full-text search across all NGSS standard content including performance expectations, topics, and keywords (e.g., "energy transfer", "ecosystems", "chemical reactions", "climate change")

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query text
`domain`	No	Optional: filter by domain
`limit`	No	Maximum number of results to return
`detail_level`	No	Response detail level: minimal (code, topic, PE 50 chars), summary (+ keywords top 3, PE 150 chars), full (complete standard)	full

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention result ranking, search algorithm specifics (e.g., case sensitivity, stemming), pagination, or any side effects. This is a significant gap for a search tool.

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 a single, well-structured sentence that includes examples. It is efficient and front-loaded with the core purpose, earning its place without extraneous text.

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 absence of an output schema, the description adequately covers the search function and parameter intent. However, it omits details like result ordering, pagination behavior, and exact response format, which would be useful for an agent.

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?

All parameters have descriptions in the schema, achieving 100% coverage. The description adds example search terms but does not elaborate on parameter usage beyond what the schema already provides. Baseline 3 is appropriate.

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 title 'Search Standards (Full-Text)' and description clearly state the tool performs full-text search across all NGSS standard content, with specific examples like 'energy transfer'. This distinguishes it from sibling tools that filter by specific attributes (e.g., search_by_domain).

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

Usage Guidelines4/5

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

The description provides context by listing content types and example queries, implying usage for general text search. However, it lacks explicit guidance on when to use this tool vs alternatives like search_by_domain or search_by_disciplinary_core_idea.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv1.2.2Feb 6, 2026
- First observedget_3d_components
- First observedget_standard
- First observedget_unit_suggestions
- First observedsearch_by_crosscutting_concept
- First observedsearch_by_disciplinary_core_idea
- First observedsearch_by_domain
- First observedsearch_by_practice
- First observedsearch_standards

Deploy Server

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

TDQS

A3.9/5.0

Scored 2026-05-04 00:20 across 8 tools

Disambiguation5/5

Each tool targets a distinct aspect: retrieving a standard, extracting 3D components, getting unit suggestions, or searching by specific facets (practice, crosscutting concept, disciplinary core idea, domain, or full-text). There is no overlapping functionality that would cause confusion.

Naming Consistency4/5

Tool names consistently use a verb_noun pattern with 'get_' for retrievals and 'search_by_' for searches. Minor deviations include the abbreviation '3d' and compound noun 'unit_suggestions', but overall the pattern is clear.

Tool Count5/5

With 8 tools, the server covers the main operations needed for NGSS standards: retrieval, component extraction, recommendation, and multiple search dimensions. This is a well-scoped set that feels neither too sparse nor excessive.

Completeness4/5

The tool surface covers core tasks: standard lookup, component extraction, and flexible searching by major facets. Minor gaps exist, such as no direct grade-band filtering or a 'list all' function, but these can be worked around via full-text search.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

science A
io.github.pipeworx-io
Science MCP — free science data APIs
Open Data Research & Data Government Data
352
groundOAuth
fyi.ground
Reference data API for classification systems, real-time world data, and unit conversions
Search Open Data
2
Sugra API A
ai.sugra
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Search Open Data Data Platforms
1122
Vocab Voyage A
io.github.jaideepdhanoa
20 MCP tools + 17 widgets for SAT/ISEE/SSAT/GRE/GMAT/LSAT prep. Flashcards, quizzes & games. Hosted.
Education & Learning Tools Text Summarization
312

Related MCP Servers

OpenEdu MCP Server
Education & Learning Tools Search
Cicatriiz
A
license
Not graded
quality
D
maintenance
A comprehensive Model Context Protocol server providing educational resources and curriculum planning support with intelligent filtering across multiple educational APIs.
Updated a year ago (2025-06-03 22:11 UTC)
11
MIT
Skolverket MCP Server
Education & Learning Tools Government Data Open Data
isakskogstad
A
license
A
quality
D
maintenance
Enables LLMs to access Swedish educational data through Skolverket's open APIs, allowing users to search curricula, courses, schools, adult education programs, and analyze educational requirements and standards. Provides comprehensive tools for teachers, students, guidance counselors, and educational researchers to interact with official Swedish education data.
Updated 5 months ago (2026-04-22 09:20 UTC)
27
10
MIT
NASA MCP Server
Open Data Aerospace & Astrodynamics Government Data
BACH-AI-Tools
A
license
B
quality
D
maintenance
Provides standardized access to 20+ NASA data sources including astronomy pictures, Mars rover photos, near-Earth objects, satellite imagery, space weather, and planetary data through a unified interface optimized for AI consumption.
Updated 9 months ago (2025-12-04 05:37 UTC)
23
9 npm
ISC
common-standards-mcp
Education & Learning Tools Open Data
smilne3
A
license
Not graded
quality
B
maintenance
A read-only MCP server for querying U.S. K-12 academic standards via the Common Standards Project API.
Updated 2 months ago (2026-07-13 14:21 UTC)
MIT

NGSS MCP Server

What's New in v1.2.2

Features

Database Statistics

Installation

Option A: Install from npm

Option B: Configure as MCP Server

Option C: Install via Smithery

Option D: Install via Docker

Install from Source

Available Tools

1. get_standard

2. search_by_domain

3. get_3d_components

4. search_standards

5. search_by_practice

6. search_by_crosscutting_concept

7. search_by_disciplinary_core_idea

8. get_3d_components

9. get_unit_suggestions

Data Model (ADR-001)

Error Handling

Development

Project Structure

Build Commands

Testing

Architecture

Data Quality

Source Data

License

Contributing

Support

Performance

Input Validation

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `get_standard`

2. `search_by_domain`

3. `get_3d_components`

4. `search_standards`

5. `search_by_practice`

6. `search_by_crosscutting_concept`

7. `search_by_disciplinary_core_idea`

8. `get_3d_components`

9. `get_unit_suggestions`