Skip to main content
Glama
Sign In
callimachus

callimachus

by BetaBots-LLC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

linked_commits

Read-only

Finds Git commits likely produced by a coding thread by matching its files against git log in the same time window, returning short SHA, subject, and file-overlap count.

Instructions

Git commits a thread likely produced, inferred by matching its files against git log in the same time window: short SHA, subject, file-overlap count. Empty until the user runs cal commits in the repo.

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": {
      "thread_id": "<thread_id>"
    },
    "name": "linked_commits"
  }
}

Input Schema

NameRequiredDescriptionDefault
thread_idYesThread id to find produced commits for.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.11.4
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "commits": {
+          "items": {
+            "properties": {
+              "committedAt": {
+                "type": "integer"
+              },
+              "overlap": {
+                "type": "integer"
+              },
+              "sha": {
+                "type": "string"
+              },
+              "shortSha": {
+                "type": "string"
+              },
+              "subject": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              }
+            },
+            "required": [
+              "sha",
+              "shortSha",
+              "subject",
+              "committedAt",
+              "overlap"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "commits"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "notice": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "notice"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}
  2. Changed3 schema fields changedv0.11.3
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / thread_id / description
      Previous value: -"The thread id (from a search/recent result) to find produced commits for."New value: +"Thread id to find produced commits for."
    • removedInput schema / title
      Removed value: -"LinkedCommitsArgs"
  3. Addedv0.6.2

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior: results are heuristic ('likely produced', 'inferred by matching'), and the tool returns empty until `cal commits` has populated data. It does not discuss confidence, ambiguous matches, or ordering beyond file-overlap count.

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?

Two sentences, front-loaded with what the tool does and its inference mechanism, followed by the empty-state caveat. No filler; the only mild redundancy is restating fields that the output schema already defines.

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?

An output schema exists, so return-value detail is not required, and the description covers the inference mechanism and the empty-result precondition. For a single-parameter read tool this is nearly complete; the missing piece is what an agent should do when the result is empty.

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?

With one required parameter at 100% schema coverage, the schema already fully documents thread_id. The description only implicitly clarifies that the thread's associated files drive the matching, adding marginal meaning beyond the schema. Baseline 3 applies.

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?

The description names a concrete resource (git commits for a thread) and the mechanism used to derive them (file-overlap with git log in the same time window), plus the return fields (short SHA, subject, overlap count). It is far more specific than a restatement of the name, though it does not explicitly contrast with the adjacent threads_for_file tool.

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?

The prerequisite 'Empty until the user runs `cal commits` in the repo' gives clear operational context for when this tool will return nothing, which is the key usage consideration. It stops short of naming an alternative to try when the result is empty.

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

Deploy Server

Other Tools