Skip to main content
Glama

Search teacher corpus

search_teacher_corpus
Read-onlyIdempotent

Search summaries of coaches' lessons for a swing fault or symptom: causes, corrections and drills, each with its source and link. Use it to explain a fault or suggest a fix even when no video is asked for. These summarise lessons; they are not observations of the player's swing: read get_swing_analysis first when there is one. For Morris's own instruction corpus use search_instruction, for short video clips search_drill_clips, and for scored drills get_drills. Attribute to a coach only what the source backs; to link a lesson, give its url exactly. Read-only.

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_teacher_corpus"
  }
}

Input Schema

NameRequiredDescriptionDefault
clubNoThe club involved, such as driver or 7-iron.
faultNoA fault code of the corpus, such as slice or over_the_top; balance for losing balance at the finish. Leave it out if unsure and describe the symptom.
chapterNoNarrow the search to one chapter of the corpus. Leave it out unless you know its exact name.
symptomNoWhat the player describes, in their words: «the ball starts left and curves right».

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / chapter / description
      Added value: +"Narrow the search to one chapter of the corpus. Leave it out unless you know its exact name."
    • addedInput schema / properties / club / description
      Added value: +"The club involved, such as driver or 7-iron."
    • changedInput schema / properties / fault / description
      Previous value: -"Fallo del corpus; para equilibrio al acabar el swing usa balance. Si no sabes su código, omítelo y describe el síntoma."New value: +"A fault code of the corpus, such as slice or over_the_top; balance for losing balance at the finish. Leave it out if unsure and describe the symptom."
    • addedInput schema / properties / symptom / description
      Added value: +"What the player describes, in their words: «the ball starts left and curves right»."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real substance: the provenance caveat that these are lesson summaries rather than observations of the player's swing, and the constraint that a coach may only be credited with what the source backs. The source/link fields and the 'read-only' restatement round out the behavioral picture.

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?

Purpose is front-loaded in the first clause, followed by use case, provenance, routing and attribution rules in a logical order; almost every sentence carries information. The 'give its url exactly' sentence is slightly ambiguous in this context and the closing 'Read-only.' duplicates the annotations, costing a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/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 steps in to describe the return shape (causes, corrections, drills, each with source and link) and the provenance limits of that content. Combined with full routing to four sibling tools, an agent has everything needed to call it correctly and interpret the results.

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 all four parameters (club, fault, chapter, symptom) are already documented, including the fault-code-vs-symptom distinction and the chapter exclusion rule. The description adds only a general framing of the fault/symptom split, and its 'give its url exactly' line refers to linking a lesson rather than to any parameter in this schema, so it does not meaningfully extend 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?

States a specific verb and resource ('Search summaries of coaches' lessons') plus the exact content returned (causes, corrections, drills, source, link) and the query surface (fault or symptom). An agent can distinguish it from search_instruction, search_drill_clips and get_drills without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes by alternative: use search_instruction for Morris's own corpus, search_drill_clips for short video clips, get_drills for scored drills, and precedents get_swing_analysis when one exists. It also gives a positive use case ('explain a fault or suggest a fix even when no video is asked for'), so both when-to-use and when-not-to-use are covered.

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.