get_submission_content

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the tool's behavior: extracts readable text from uploaded files, returns typed text/URL for other types, and includes the submission comment thread. It also implies a read-only nature by focusing on fetching data. While it doesn't mention error handling or pagination, it gives a solid behavioral overview expected of a read tool.

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?

The description is concise at three sentences, but the first sentence is dense with information. It front-loads the core purpose and behavior, then adds the usage directive. There is minimal fluff, and each sentence adds value. It is well-structured for quick reading.

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?

Since an output schema exists, the description doesn't need to detail return values. It covers the essential context for using the tool: what it retrieves, how it handles different submission types, and when to use it. It doesn't discuss limitations like unsupported file types or context-specific details, but overall it provides sufficient contextual guidance for an agent to invoke the tool correctly.

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 description coverage is 0%, so the description must compensate. However, the description does not directly explain any of the three parameters (course_identifier, assignment_id, user_id). It implicitly references an assignment and a student, but does not clarify parameter formats, constraints, or how to obtain them. Given the low coverage and lack of explicit parameter explanation, this is a notable gap, though the parameter names are somewhat self-explanatory.

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 uses a specific verb phrase 'Pull what a student actually submitted' and clearly identifies the resource (assignment content) and the extraction behavior. It distinguishes itself from sibling tools like list_submissions by focusing on actual content rather than metadata, and explicitly mentions the alternative grading tools it supports.

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?

The description explicitly instructs to use this tool before grade_submission or grade_with_rubric, providing a clear when-to-use directive. It names the alternative grading tools that depend on this content, effectively explaining why this tool is the prerequisite. This is direct guidance beyond what the schema or annotations convey.

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