NGSS MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.2
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.
Average 3.7/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on October 21, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![NGSS-MCP MCP server](https://glama.ai/mcp/servers/Sallvainian/NGSS-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Sallvainian/NGSS-MCP)

Score Badge

Copy to your README.md:

[![NGSS-MCP MCP server](https://glama.ai/mcp/servers/Sallvainian/NGSS-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Sallvainian/NGSS-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Sallvainian/NGSS-MCP'

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