Loading ToolBench
A headless forge and Git replication layer that exposes Git plumbing commands and repository management as MCP tools. Agents can read files at revisions, search symbols, view history, and commit changes without cloning repositories.
Code exposes 21 well-structured tools with consistent naming (verb_noun pattern), complete input schemas with type definitions, and clear descriptions. All tools follow the verb-first convention (list_, describe_, create_, update_, delete_, get_, claim_, complete_). Schemas are properly typed JSON Schema objects with required fields and constraints (e.g., issue minimum:1, lease_duration_ms bounds). Descriptions are substantive (100-200 chars typical), explaining WHAT the tool does and WHEN to use it. However, parameter descriptions are sparse, most params lack individual descriptions explaining their purpose or constraints. Output schemas are not documented. Error handling guidance is absent. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in the metadata.
Add a comment recorded with the verified author.
Claim a work node for execution.
Record the completion of a work attempt.
Store a versioned account inference profile.
Store a versioned account binding to the deployment-managed Infisical secret backend. It never accepts an endpoint, workload token, or secret value.
Open an issue and record its verified author in durable repository history.
Parameter descriptions missing or minimal. Most parameters (repository, issue, body, graph, backend, profile, etc.) lack individual descriptions explaining their purpose, format, or constraints. LLMs cannot infer parameter semantics from names alone.
Output schemas not documented. Tool descriptions do not specify what fields are returned or their types. Agents cannot plan downstream tool calls or extract required data without knowing response structure.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Create an empty repository. Cheap by design: a repository is one object in storage until something is pushed to it, so creating one per task is a reasonable thing to do.
Create an immutable graph of repository work. Agent nodes may name a Condukt operation, but this call never supplies a model key or starts a model session.
Hide an issue from current views while retaining its immutable audit history.
Hide a comment from current views while retaining its immutable history.
Log state, default branch, size and replica placement for one repository. Useful for confirming a write landed and for diagnosing replica lag.
Read one current non-secret inference profile for a repository account.
Read an issue and its current comments.
Read one current comment from an issue.
Read one current non-secret backend binding for a repository account.
Read an issue's immutable event history.
List the current issues in a repository.
List the repositories the caller may read.
List the current non-secret backend bindings for a repository account.
Update an issue's title, description, or open and closed state.
Replace a comment's current body while retaining its immutable history.
No tool annotations despite clear risk classifications. Tools marked DESTRUCTIVE (delete_issue, delete_issue_comment) or WRITE lack destructiveHint/idempotentHint annotations. Agents cannot distinguish safe-to-retry operations from irreversible ones.
Error handling guidance absent. No tool descriptions explain what errors can occur, how to recover, or what the LLM should do next. Agents will not know whether to retry, ask the user, or abort.
Complex parameters lack format/constraint documentation. 'graph' parameter in create_work_run is typed as object but no description explains its structure. 'outcome' enum in complete_work_attempt is defined but not explained in the parameter description.