seneca_search_programsSearch program codes or names within one catalog snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | Teaching-period code; not a curriculum semester | |
| as_of | No | Use the snapshot captured at or before this ISO-8601 time | |
| limit | No | ||
| query | No | ||
| cursor | No | Cursor from next_cursor | |
| fields | No | ||
| snapshot_id | No | Immutable snapshot id | |
| source_code | No | Source code, such as seneca |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description doesn't need to repeat that. It adds the 'one catalog snapshot' scope, which is useful context beyond the schema. However, it doesn't disclose pagination behavior, result shape, or any other behavioral traits, so it adds only marginal value over the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no fluff. The core action and scope are front-loaded. It's appropriately concise, though it could include a bit more detail without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no mention of return format or pagination, the description is insufficient for an agent to fully understand the tool's behavior. The 'one catalog snapshot' is helpful but doesn't cover the full context needed for correct invocation, such as how to specify a snapshot or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%, meaning about 37% of parameters are undocumented in the schema. The description only hints at 'program codes or names' which relates to query and possibly fields, but it doesn't explain term, as_of, limit, cursor, snapshot_id, or source_code. Since coverage is moderate and the description doesn't compensate for the gaps, it adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb 'Search' and resource 'program codes or names', and adds the scope 'within one catalog snapshot', which helps differentiate from sibling search tools like seneca_search_courses. However, it doesn't explicitly name any sibling or elaborate on the difference, so it's clear but not fully distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It implies a single-snapshot scope but doesn't mention that seneca_list_snapshots or seneca_search_courses might be more appropriate for other scenarios. There are many sibling search tools, and without explicit conditions, an agent may pick the wrong one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool has a unique purpose, and the descriptions are detailed enough to clearly distinguish between search, list, get, and specific operations across domains. No two tools overlap in function.
Domain tools follow a consistent '<domain>_<verb>_<noun>' pattern, but gateway-level tools like 'call_tool', 'find_capability', 'inspect_tool', 'search_services', and 'status' lack the prefix, introducing a minor inconsistency. Overall still readable and predictable.
With 35 tools, the count exceeds the typical 3–15 range, but this is a gateway aggregating multiple distinct domains (holidays, laws, opendata, recalls, etc.), making the larger set justified. The count feels appropriate for the server's purpose.
Each domain offers a full set of operations: search, list, get, and domain-specific actions (like count_business_days or get_document_changes). Gateway meta-tools cover discovery, inspection, and invocation, leaving no obvious gaps.