Skip to main content
Glama
Sign In

GitRanks Contribute

by com.gitranks
OverviewDiscussionsAdmin

Submit a lesson

submit_lesson

GitRanks Learn (invite-only): submits the lesson on your fix that a Learn claim's lessonBrief describes (4 to 6 steps of typed blocks, questions with their key), once the claim's patch passed its checks. Our checks and a short review run at once: on a pass the contributor takes the lesson on gitranks.com and only then approves the pull request; on a fail the findings come back, one per line, to fix and submit again. A new patch needs a new lesson.

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": {
      "attemptId": "<attemptId>",
      "lesson": "<lesson>"
    },
    "name": "submit_lesson"
  }
}

Input Schema

NameRequiredDescriptionDefault
lessonYesThe lesson on your fix, in the shape the claim's lessonBrief gives
attemptIdYesThe attemptId of your claim or follow-up (24 hex characters), as its start or the contributions list answered it

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare non-read-only, open-world, non-idempotent. The description adds the invite-only gate, that checks and review run concurrently, that failure returns findings 'one per line' to fix and resubmit, and that a new patch invalidates the lesson — all real behavior not encoded in annotations. Missing: whether resubmission against the same attemptId is allowed or what a duplicate submission returns.

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?

Preconditions and outcome are front-loaded, and the pass/fail branch is packed into one dense sentence with no filler. The last sentence ('A new patch needs a new lesson') earns its place as a stale-submission warning.

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?

For a nested two-parameter submission tool with full schema coverage and no output schema, the description covers the prerequisite, the synchronous check/review behavior, and the retry loop. It stops short of explaining what a successful response contains or how to recover from a non-findings error.

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 the baseline is 3. The description does add a few constraints beyond the schema — '4 to 6 steps of typed blocks' (the schema only allows 1–8) and 'questions with their key' — which meaningfully narrow the payload. These gains are modest against an already richly documented schema, so a 3 is appropriate.

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+resource: submitting 'the lesson on your fix that a Learn claim's lessonBrief describes', with the invite-only Learn context making it distinct from the patch/proof submission siblings. An agent can tell this is the lesson-authoring submission step of a Learn claim, not a patch or proof submission, without opening the schema.

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 a clear precondition ('once the claim's patch passed its checks') and a re-submission rule ('A new patch needs a new lesson'), and describes the pass/fail consequence chain. It does not name an alternative tool for the non-Learn case, but the context is unambiguous.

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

All GitRanks Contribute toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources