Skip to main content
Glama

Fiveable for AP Students

List free-response questions

list_frqs
Read-onlyIdempotent

Lists Fiveable's free-response (FRQ) practice prompts for an AP subject, optionally filtered by FRQ type, unit, and excluded IDs. Results use stable ID order; unchanged filters continue pagination. Returns prompt ids and summaries rather than full prompts. Cheap.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitYesMaximum prompts to list.
cursorNo
intentNoPrivacy-safe reason for the request. Use explain, quiz, notes, frq, or research; never send the student's raw prompt for analytics.
unitIdNoUnit ID or public unit slug from get_subject_outline.
frqTypeNoOptional FRQ type filter, e.g. "DBQ", "LEQ", "SAQ". Varies by subject.
excludeIdsNo
subjectSlugYesFiveable subject slug, e.g. "ap-bio". A course name such as "AP Biology" also resolves.
courseVariantNoAP Calculus only (subject ap-calc): 'ab' hides BC-only units and topics; 'bc' includes them. Defaults to the student's saved Fiveable course when they are connected.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoReadable tool result text for clients that consume structured output.
statusYesOperation status: completed, pending, partial, failed, unavailable, or a domain-specific outcome.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / courseVariant
      Added value: +{
      +  "description": "AP Calculus only (subject ap-calc): 'ab' hides BC-only units and topics; 'bc' includes them. Defaults to the student's saved Fiveable course when they are connected.",
      +  "enum": [
      +    "ab",
      +    "bc"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / subjectSlug / description
      Previous value: -"Fiveable subject slug, e.g. \"ap-bio\"."New value: +"Fiveable subject slug, e.g. \"ap-bio\". A course name such as \"AP Biology\" also resolves."
  3. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond those: stable ID ordering for pagination ('unchanged filters continue pagination'), a return-format disclosure ('prompt ids and summaries rather than full prompts'), and a cost signal ('Cheap'). These enrich the agent's model of side effects and behavior without contradicting 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four compact sentences, each earning its place: purpose+filters, pagination behavior, return format, and cost. The core purpose is front-loaded before behavioral details. The standalone 'Cheap.' sentence is a slightly informal touch but adds real signal; overall minimal waste.

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 an output schema exists (covering return structure), 8 parameters, and rich annotations, the description covers the essentials: what is listed, how filtering works, pagination stability, and cost. The privacy aspect of intent is left to the schema description, but the description is still adequate for correct invocation without major gaps.

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 75%, so most parameters (limit, intent, unitId, frqType, subjectSlug, courseVariant) already have descriptions. The tool description adds value for the undocumented excludeIds by mentioning 'excluded IDs' and contextualizes cursor via the pagination statement. It does not, however, elaborate on parameter formats or valid values, so it compensates only partially for the 25% 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?

The description states a specific verb-resource pair ('List free-response practice prompts for an AP subject') and names the filter dimensions (FRQ type, unit, excluded IDs). It clearly distinguishes itself from siblings such as get_frq (single prompt) by framing this as a listing operation, and from list_practice_questions by scoping to FRQs. No ambiguity about what the tool does.

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 the tool through 'Returns prompt ids and summaries rather than full prompts,' which hints that get_frq is the alternative for full-prompt needs, and 'optionally filtered' signals a discovery-style listing. However, it never explicitly names the sibling or states a when-not-to-use condition, so the routing guidance is implied rather than explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.