Skip to main content
Glama

Get Exam Paper by ID

paper_get
Read-onlyIdempotent

Retrieve a specific exam paper by its ID with question details

Input Schema

NameRequiredDescriptionDefault
exam_paper_idYesThe ID of the exam paper to retrieve

Output Schema

NameRequiredDescriptionDefault
idYes
tierYes
yearYes
titleYes
subjectYes
sectionsYes
created_atYesISO-8601 creation timestamp.
created_byYes
exam_boardYes
total_marksYes
paper_numberYes
duration_minutesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • removedOutput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / properties / created_by / anyOf
      Previous value: -[
      -  {
      -    "additionalProperties": false,
      -    "properties": {
      -      "email": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ]
      -      },
      -      "id": {
      -        "type": "string"
      -      },
      -      "name": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ]
      -      }
      -    },
      -    "required": [
      -      "id",
      -      "name",
      -      "email"
      -    ],
      -    "type": "object"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "properties": {
      +      "email": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      },
      +      "id": {
      +        "type": "string"
      +      },
      +      "name": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      }
      +    },
      +    "required": [
      +      "id",
      +      "name",
      +      "email"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / sections / items / additionalProperties
      Removed value: -false
    • removedOutput schema / properties / sections / items / properties / questions / items / additionalProperties
      Removed value: -false
    • removedOutput schema / properties / sections / items / properties / questions / items / properties / mark_schemes / items / additionalProperties
      Removed value: -false
    • removedOutput schema / properties / sections / items / properties / questions / items / properties / mark_schemes / items / properties / mark_points / items / additionalProperties
      Removed value: -false
  2. Changed2 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Changed2 schema fields changed
    • removedOutput schema / properties / sections / items / properties / questions / items / properties / mark_schemes / items / properties / points_total
      Removed value: -{
      -  "type": "number"
      -}
    • changedOutput schema / properties / sections / items / properties / questions / items / properties / mark_schemes / items / required
      Previous value: -[
      -  "id",
      -  "description",
      -  "marking_method",
      -  "points_total",
      -  "mark_points",
      -  "content"
      -]New value: +[
      +  "id",
      +  "description",
      +  "marking_method",
      +  "mark_points",
      +  "content"
      +]
  4. Changed5 schema fields changed
    • removedOutput schema / properties / created_by / additionalProperties
      Removed value: -false
    • addedOutput schema / properties / created_by / anyOf
      Added value: +[
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "email": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      },
      +      "id": {
      +        "type": "string"
      +      },
      +      "name": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      }
      +    },
      +    "required": [
      +      "id",
      +      "name",
      +      "email"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / created_by / properties
      Removed value: -{
      -  "email": {
      -    "anyOf": [
      -      {
      -        "type": "string"
      -      },
      -      {
      -        "type": "null"
      -      }
      -    ]
      -  },
      -  "id": {
      -    "type": "string"
      -  },
      -  "name": {
      -    "anyOf": [
      -      {
      -        "type": "string"
      -      },
      -      {
      -        "type": "null"
      -      }
      -    ]
      -  }
      -}
    • removedOutput schema / properties / created_by / required
      Removed value: -[
      -  "id",
      -  "name",
      -  "email"
      -]
    • removedOutput schema / properties / created_by / type
      Removed value: -"object"
  5. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and a closed world, so the safety profile is covered. The description adds that question details come back in the payload, which is useful context, but says nothing about behavior when the ID is invalid or missing. With annotations carrying the main burden, a 3 is appropriate.

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 short sentence with the key information front-loaded and no wasted clauses. It is close to minimal, though 'with question details' is slightly vague about what is actually returned.

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?

A simple read tool with one fully documented required parameter, a rich annotation set, and an output schema that handles return-value explanation. Nearly everything an agent needs to call it correctly is present; only error/not-found behavior is unaddressed, which is minor here.

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?

The single parameter has 100% schema description coverage ('The ID of the exam paper to retrieve'), so the schema does the work. The description only restates that lookup is by ID and adds no ID format, source, or validation details, matching the baseline 3 for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Retrieve a specific exam paper by its ID') and adds that question details are included, which distinguishes it from a bare list call. It doesn't explicitly contrast with siblings like paper_list or submission_get, so an agent must infer the single-record vs. collection split.

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?

Usage is only implied by 'by its ID' — the agent can infer this is the single-record fetch when an exam_paper_id is known. There is no explicit when-to-use, no mention of when to prefer paper_list or another sibling, and no prerequisite or not-found guidance.

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.

Resources