Skip to main content
Glama

prepare_submission

Read-onlyIdempotent

Prepares local files and computes hashes for assignment submission without logging in or writing to the campus.

Instructions

Prepara archivos y hashes localmente; no inicia sesión ni escribe en el campus.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "course_id": "<course_id>",
      "activity_id": "<activity_id>",
      "files": "<files>"
    },
    "name": "prepare_submission"
  }
}

Input Schema

NameRequiredDescriptionDefault
filesYesRutas locales de archivos regulares; no carpetas.
course_idYesID de la materia o módulo, según el parámetro.
activity_idYesID de la materia o módulo, según el parámetro.

Output Schema

NameRequiredDescriptionDefault
filesYes
course_idYes
activity_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior1/5

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

The description says it 'prepares files and hashes locally' and 'does not write to the campus', which implies it may write locally. This contradicts the readOnlyHint: true annotation, which asserts no writes anywhere. The contradiction is material and misleads about side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single, front-loaded sentence that efficiently conveys the tool's local scope and its difference from remote operations. Every clause serves a purpose without redundancy.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description gives useful local-only context, it contradicts the readOnlyHint annotation and does not clarify what 'prepares' entails (e.g., hashing algorithm, file validation). Given the presence of an output schema and full schema coverage, these gaps are partially mitigated, but the contradiction leaves the behavioral picture incomplete and misleading.

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 parameters are fully documented in the schema. The description does not mention any parameters, adding no extra meaning beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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 ('Prepara') and resource ('archivos y hashes') with a clear scope ('localmente'). It distinguishes itself from siblings by explicitly stating it does not log in or write to the campus, which contrasts with login, upload_files, and submit_assignment.

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 usage by contrasting local preparation with remote operations ('no inicia sesión ni escribe en el campus'), suggesting it should be used for offline preparation before remote submission. However, it does not explicitly name alternatives or state when to choose it over them, leaving the guidance implicit.

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