qidi-mcp

get_gcode_log

Read-onlyIdempotent

Retrieve recent G-code commands and Klipper replies from the console to diagnose print failures or inspect what a macro did.

Instructions

Recent G-code console history — the commands sent and Klipper's replies, exactly what the Fluidd console shows. The fastest way to see why something failed or what a macro actually did.

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": "get_gcode_log"
  }
}

Input Schema

Name	Required	Description	Default
`count`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.1Nov 9, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare this a safe, idempotent, non-destructive read, so the safety profile needs no restatement. The description adds that the window is 'recent' and what the entries contain, which helps interpret output, but says nothing about how far back it reaches or how the log is bounded.

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?

Two sentences, no filler, with the identity of the resource front-loaded and the practical use case following immediately.

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

Completeness3/5

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

An output schema exists, so return values need no explanation, and the log semantics are covered well. However, for a single-argument tool the only argument is left entirely unexplained, which is a real gap in an otherwise complete definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'count' has 0% schema description coverage and a default of 50, yet the description never mentions it, its units, or any maximum. With low coverage the description should carry that meaning and does not.

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?

Names a specific resource (G-code console history) and defines its contents precisely — commands sent plus Klipper's replies — with a concrete reference point ('exactly what the Fluidd console shows'). It does not distinguish itself from the nearby get_klipper_log sibling, so an agent may still hesitate between the two.

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

Usage Guidelines4/5

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

Gives two concrete diagnostic scenarios ('why something failed', 'what a macro actually did') that make the use case clear. It offers no exclusions or named alternatives, so it stops short of routing guidance.

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

Deploy Server