Skip to main content
Glama

Archive: Compare Terms

archive_compare_terms
Read-onlyIdempotent

Compare a course's sections across two archived terms to reveal instructor turnover, section-count changes, and capacity or fill shifts in one explicit diff.

Instructions

Diff one course's sections between two archived terms: instructor turnover, section-count delta, and capacity/fill movement, named explicitly rather than left for two separate archive_term_sections calls to be compared by eye.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
term_aYes
term_bYes
course_codeYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.1

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description usefully discloses the analysis dimensions produced, but says nothing about term validity requirements, error behavior, or whether courses missing from a term are omitted or flagged.

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?

One dense sentence that front-loads the core action ('Diff one course's sections between two archived terms') before listing the metrics. It is slightly clause-heavy but every clause carries information.

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?

An output schema exists, so return values need not be explained, and the compared dimensions are stated. However, with three undocumented parameters and no term-format or ordering conventions, an agent still lacks enough to construct a correct call confidently.

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?

Schema description coverage is 0% and all three parameters (course_code, term_a, term_b) are only bare strings in the schema. The description does not specify term code format, whether term_a must be the earlier term, or the course_code convention — so the description fails to compensate for the coverage gap.

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?

States a specific verb (diff/compare) and resource (one course's sections across two archived terms), and enumerates the dimensions compared (instructor turnover, section-count delta, capacity/fill movement). It also distinguishes itself from the sibling archive_term_sections by name, so an agent can route between them without opening schemas.

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 clause 'named explicitly rather than left for two separate archive_term_sections calls to be compared by eye' tells the agent this is the preferred path over manual comparison. It gives clear context but states no exclusions, such as what happens if a term is not archived or the course did not exist in one term.

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

Deploy Server

Other Tools