Skip to main content
Glama

Lessons from real Godot projects

godot_lessons

Look up Godot 4 lessons from real project failures by error message, symptom, rule, or topic to get the cause, fix, and how to test it.

Instructions

Answer from lessons learned in real Godot 4 projects and on this machine: what went wrong, why in Godot terms, the fix, and how to test it. Find them by query (words such as 'helicopter slides off moving ship', or a lesson id), by error (a Godot message exactly as printed: the lessons that explain it), by rule (the lessons behind a review or model rule), or narrow by topic (gdscript, physics, rendering, import, models, world, performance, gameplay, ui, audio, tooling, process). Without any of them it lists the lessons. gaps: true instead lists the Godot errors seen on this machine (and by other installs) that no review rule predicted and no lesson explains yet: what to teach Godotwright next. Use it when Godot shows an error you do not understand, and before you build moving platforms, vehicles, ships, large worlds, runtime-loaded models, shaders or headless tests. detail brief gives the title and fix; full adds symptom, cause, test, rules and the Godot message. Returns plain text; lessons learned here are marked. It counts which lessons were shown in the local learning file (GODOTWRIGHT_LEARN=0 turns that off). Say whether one helped with godot_feedback (lesson).

Input Schema

NameRequiredDescriptionDefault
gapsNolist what Godotwright cannot predict yet instead of lessons
ruleNoa rule id from godot_review or godot_model_lint, e.g. api/infer-variant
errorNoa Godot error or warning message, as printed
limitNomax lessons (default 5; 20 when listing)
queryNowords, or a lesson id
topicNoonly lessons of this topic
detailNobrief: short output with capped lists; full: everything (default for this premium profile: full).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2

TDQS

A4.2/5.0
Behavior4/5

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

With readOnlyHint=false the side effect would otherwise look contradictory to a lookup tool, but the description explicitly explains it: 'It counts which lessons were shown in the local learning file (GODOTWRIGHT_LEARN=0 turns that off).' It also discloses the return format (plain text, locally-learned lessons marked) and what detail levels yield. Lacks limits/pagination nuance, but the key non-obvious side effect is covered.

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

Conciseness3/5

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

Front-loaded with purpose and usage, and most sentences carry weight. However it re-enumerates all twelve topic enum values verbatim from the schema and packs multiple modes into long run-on sentences, which adds length without new information.

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?

Seven optional parameters and no output schema, yet the description explains the four lookup modes, the list fallback, the gaps mode, the detail levels, and the return type. An agent can call it correctly without guessing; only the interaction between limit and detail is left implicit.

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

Parameters4/5

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

Schema coverage is 100%, so 3 is the baseline, but the description genuinely adds semantics: query accepts free words like 'helicopter slides off moving ship' or a lesson id, error must be 'a Godot message exactly as printed', gaps:true switches the whole result set to unlearned errors, and no parameter at all means list mode. That mapping of modes to parameters goes beyond 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: 'Answer from lessons learned in real Godot 4 projects and on this machine', with the shape of an answer (what went wrong, why in Godot terms, the fix, how to test it). This is clearly distinct from sibling godot_lesson_add (which writes lessons) and from godot_fix/godot_check.

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 concrete triggers: 'Use it when Godot shows an error you do not understand, and before you build moving platforms, vehicles, ships, large worlds, runtime-loaded models, shaders or headless tests.' It also closes the loop by naming godot_feedback as the follow-up. It does not explicitly say when to reach for godot_fix or godot_check instead, so the routing is not fully exhaustive.

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