purdue-mcp

Search the Purdue course catalog

search_courses

Find Purdue courses by subject code, course number, or title keyword to retrieve titles, credit hours, and descriptions.

Instructions

Find courses by subject code, course number, and/or title keyword — returns titles, credit hours, and descriptions. Source: Purdue.io.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_courses"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Default 25.
`number`	No	Course number, e.g. '18000' or '180' (short forms are zero-padded).
`subject`	No	Subject abbreviation, e.g. 'CS', 'MA', 'ENGR'.
`title_contains`	No	Keyword in the course title.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Aug 18, 2026

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It indicates this is a search/query operation (read-only), but does not explicitly state that it is non-destructive, mention rate limits, pagination, default limit behavior, or what happens when no results are found. The description is too minimal to fully inform an agent about side effects or safety.

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 succinct sentences that front-load the purpose and return values. Every word adds value, and there is no fluff.

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 no output schema, the description explains that the tool returns titles, credit hours, and descriptions, which is sufficient for a basic search. However, it omits details about pagination, ordering, or the interaction between parameters (e.g., all optional). It is mostly complete for a simple search tool but could be slightly more informative.

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 each parameter has a description. The tool description only summarizes the criteria generally (subject, number, title keyword) without adding new semantics beyond the schema. The baseline of 3 is appropriate since the schema already does the heavy lifting.

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 uses a specific verb 'Find' and resource 'courses', and lists the search criteria (subject, number, title keyword) and return fields (titles, credit hours, descriptions). It clearly states what the tool does but does not differentiate it from sibling tools like course_sections or course_availability.

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, nor does it specify prerequisites, exclusions, or when not to use it. For example, it doesn't mention that course_sections should be used after a course is found, or that all parameters are optional but at least one is recommended.

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