Damper

by com.usedamper

Overview Discussions Admin

Add Commit

add_commit

Log a commit for a task (secondary detail — the linked pull request is the primary deliverable, see link_pr).

When to use:

After a notable commit: log hash and message
When completing work: optionally pass commits to complete_task instead

Example: After git commit, call this with the commit hash and message.

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": {
      "projectId": "<projectId>",
      "taskId": "<taskId>",
      "hash": "<hash>",
      "message": "<message>"
    },
    "name": "add_commit"
  }
}

Input Schema

Name	Required	Description
`hash`	Yes	Commit hash (short or full)
`taskId`	Yes
`message`	Yes	Commit message in conventional commits format: type(scope): description. E.g., "feat(auth): add OAuth login"
`projectId`	Yes	Project ID. Use list_projects to find available project IDs.

Output Schema

Name	Required	Description
`hash`	Yes
`taskId`	Yes
`success`	Yes
`dashboardUrl`	No	Full dashboard URL of the affected resource

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare non-read-only, non-idempotent, non-destructive, closed-world. The description adds the useful contextual fact that this is a secondary artifact and that duplicate/alternative paths exist (complete_task), which shapes when an agent should bother. It doesn't say what happens on a repeated hash given idempotentHint=false, which would be the highest-value addition.

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?

Front-loaded with the scoping caveat in parentheses, then compact bullets. The trailing example sentence largely repeats the first bullet, so it costs a little without earning much.

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?

Output schema exists and annotations cover the safety profile, so the description need only carry usage/routing — which it does. Remaining gap is behavioral edge cases (duplicate commit, whether it must precede complete_task), minor but not fully covered.

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 coverage is 75% — hash, message and projectId are documented (including conventional-commits format and the list_projects pointer), while taskId is bare. The description only restates "hash and message," adding no meaning beyond the schema, so the baseline 3 applies.

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 ("Log a commit for a task") and immediately positions it relative to siblings — secondary to `link_pr` and an alternative to passing commits into `complete_task`. An agent can distinguish it from all other add_* tools without reading any schema.

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

Usage Guidelines5/5

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

Explicit when-to-use bullets: after a notable commit, or instead pass commits to `complete_task`. The named alternative plus the condition that selects it is exactly what routing guidance should look like.

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

All Damper tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?