A
licenseA
qualityC
maintenanceA complete Model Context Protocol server for Subversion (SVN) integration, designed to allow AI agents to efficiently manage SVN repositories.
14
22 npm
21
MIT
svn-agent MCP
The svn-agent MCP is an agent-safe SVN server for Windows with bundled SlikSVN and dos2unix binaries, providing guarded SVN operations, diagnostics, and EOL management.
Diagnostics & Health
svn_self_check– Verify MCP release health, bundled binaries, and startup probesvn_diagnose– Read-only diagnostics: local status, remote status, HEAD info, and log reachability
Read-Only SVN Operations
svn_status– Structured changed paths and conflicts for a scoped working copysvn_info– SVN info with mixed-revision detectionsvn_diff– Scoped diff with optional EOL ignoring and per-file line limitssvn_log– Structured commit history with optional verbosity and path scopingsvn_propget– Read a specific SVN property from explicit paths
Precommit & EOL Checks
svn_precommit– Composite read-only check: status, EOL-ignored diff, EOL inspection, dry-run guard, and mixed-revision warningeol_check– Inspect EOL kind, BOM presence, andsvn:eol-stylefor explicit files
EOL & Property Management
eol_fix_verified– Convert file EOLs viaunix2dos/dos2unixinferred fromsvn:eol-style, then verify with an ignored-EOL diffsvn_propset_eol_style– Setsvn:eol-styleonly where missing or mismatchedsvn_propset– Guardedsvn propsetwith value length limit and risk acknowledgment
Guarded SVN Mutations
svn_add– Guarded add for explicit files/directories (optional recursive)svn_commit– Guarded commit via temp message file with explicit pathssvn_move/svn_rename– Guarded working-copy move/rename with parent directory creationsvn_copy– Guarded working-copy copy with parent directory creationsvn_update– Guarded update with--accept postponesvn_revert– Preview or perform guarded revert for explicit paths (supports dry-run)svn_resolved– Resolve conflicts with explicit accept mode (working,mine-full,theirs-full,base)svn_cleanup– Non-destructivesvn cleanup
Repository Import & Export
svn_export– Export from a repository URL with optional revisionsvn_import– Import a directory with a commit message via temp file
Provides tools for interacting with Subversion (SVN) version control repositories, including status, diff, commit, log, blame, update, revert, add, delete, copy, move, property management, EOL checks, and precommit validation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@svn-agent MCPCheck SVN status of the working copy"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
svn-agent MCP
Strict SVN Model Context Protocol server for agent-safe status, diff, EOL diagnosis, precommit checks, and guarded SVN mutations.
The implementation contract lives in docs/SPEC.md. The current source release is 1.9.1; each source clone can prepare a local runtime under releases/v1.9.1, while npm installations run directly from package-root dist/.
Requirements: Node.js 24.18.0 or newer, npm 11.16.0 or newer, Git, and access to the public npm registry. Windows uses the
bundled VisualSVN Apache Subversion command-line package and dos2unix payload. On macOS and Linux, svn, svnversion, svnadmin,
dos2unix, and unix2dos must be available on PATH.
Install From npm
npm install -g svn-agent-mcp@latest
npm list -g svn-agent-mcp --depth=0Register one MCP server named svn and let the client resolve the globally installed command from
PATH:
{
"mcpServers": {
"svn": {
"command": "svn-agent-mcp"
}
}
}Restart the MCP client after changing its configuration, then run svn_self_check once to verify
the installed version and runtime health.
Related MCP server: agent-services-mcp
Generic Agent Install Prompt
Give this prompt to any local coding agent:
Install or update the SVN MCP globally with: npm install -g svn-agent-mcp@latest
Verify the package with: npm list -g svn-agent-mcp --depth=0
Resolve the executable with the host shell's command lookup: Get-Command svn-agent-mcp in PowerShell, where.exe svn-agent-mcp in Windows Command Prompt, or command -v svn-agent-mcp on POSIX shells. Do not use a lookup command from another platform.
On macOS/Linux, verify that svn, svnversion, svnadmin, dos2unix, and unix2dos are available on PATH. If any are missing, install Subversion and dos2unix with the host package manager.
Ensure the MCP client entry is named "svn". Use command "svn-agent-mcp" when the client can launch it without a visible window; never use a source checkout, junction, or current pointer. Do not add --readonly.
On Windows, enable the client's hidden/no-window process option. If the npm command shim still opens a console, resolve the global module root with `npm root -g`, then use command "node" with args `["<global-module-root>\\svn-agent-mcp\\dist\\index.js"]`; the server cannot choose its parent process creation flags.
Preserve existing SVN_AGENT_* environment overrides without printing sensitive values, then restart the MCP client.
Query the registry version with: npm view svn-agent-mcp version
After restarting, run svn_self_check and compare its installed version with the registry version. Report the installed version, executable path, runtime layout, and MCP health instead of relying on a remembered version.Source Setup From GitHub
Use a source checkout for development and contribution work, not as the normal global MCP runtime. Generic source-setup prompt:
Clone https://github.com/shrishailrana-maker/svn-agent-mcp-v1 into a stable development directory. Run npm ci --strict-allow-scripts, npm run prepare:local, and npm test. Use the globally installed svn-agent-mcp command for normal MCP client registration; use node <absolute-clone-path>/current/dist/index.js only when explicitly testing that checkout.The setup commands are:
git clone https://github.com/shrishailrana-maker/svn-agent-mcp-v1.git
cd svn-agent-mcp-v1
npm ci --strict-allow-scripts
npm run prepare:local
npm testThen configure the MCP client to run:
node <absolute-clone-path>/current/dist/index.jsJSON Client Config Example
Add this under mcpServers:
{
"mcpServers": {
"svn": {
"command": "node",
"args": ["<absolute-clone-path>/current/dist/index.js"]
}
}
}TOML Client Config Example
[mcp_servers.svn]
command = "node"
args = ["<absolute-clone-path>/current/dist/index.js"]
startup_timeout_sec = 120Restart the MCP client after changing the config.
On Windows, process-window visibility is controlled by the MCP client that spawns the server.
Clients should use a hidden/no-window process option such as Node's windowsHide:true. The server
reserves stdout for newline-delimited MCP JSON-RPC and sends startup diagnostics only to stderr.
Start The MCP
For development from this working copy:
cd <path-to-svn-agent-mcp-v1>
npm install
npm run prepare:local
node ./current/dist/index.jsThe source tree includes bin/ with the Windows VisualSVN Apache Subversion and dos2unix payload. Releases copy that
folder to current/bin, so Windows clients do not need separate tool installations. On macOS and
Linux, the server ignores those .exe files and resolves the native tools from PATH. See
THIRD_PARTY_NOTICES.md, THIRD_PARTY_CHECKSUMS.txt, and third_party_licenses/ for bundled
binary notices, hashes, and complete license texts.
Plug-And-Play Client Config
After npm install -g svn-agent-mcp@latest, register the MCP once. Do not set cwd or add
environment variables unless an existing installation already needs an explicit override:
Generic client example:
{
"mcpServers": {
"svn": {
"command": "svn-agent-mcp"
}
}
}The MCP is not tied to one SVN checkout. If a tool call supplies absolute paths and omits cwd, the server finds the nearest SVN working copy for those paths. Relative paths require an explicit, absolute per-call cwd. Repository URL inputs must not embed usernames or passwords; use the native SVN credential cache.
Client registration is static: configure the MCP once, and working-copy discovery happens per tool call. The server does not rewrite client configuration at runtime.
Issues And Feature Requests
Use GitHub Issues for public bugs, feature requests, and planned work. Search existing issues before filing a new one and use the provided templates. Include the package version, operating system, Node.js version, installation method, and a minimal sanitized reproduction when relevant. Remove credentials, private repository URLs, usernames, and local absolute paths from public reports.
The completed historical project backlog was migrated as issues
#1 through
#31. Report security
vulnerabilities through the private process in SECURITY.md, not a public issue.
Environment variables are not required when the toolchain is bundled or available on PATH.
SVN_MCP_TOOL_PROFILE controls the advertised schema surface: full (default) exposes 30
canonical tools, docs exposes the 9-tool edit/commit workflow, and review adds bounded diff,
cat, and blame for 12 tools total. Focused profiles reduce tool-definition context without changing
any guard. A call to a hidden tool returns a typed TOOL_PROFILE refusal; use full when the
workflow needs another operation.
SVN_MCP_RESPONSE_MODE selects compact (default), receipt, structured-only, standard, or
full responses. structuredContent is authoritative. Every mode except structured-only returns
exactly one bounded text block by default; structured-only returns no text block. The text block is
a short summary and never replaces structured data. humanText remains accepted for compatibility,
but it does not change this bound. receipt is the smallest stable contract for status, snapshot,
precommit, update, and commit. Use responseMode:"full" only when bounded raw SVN diagnostics and
machine paths are needed.
If a call returns neither usable text nor a structured result, classify it as a harness or transport
drop. Disclose SVN MCP empty, preserve the same explicit path scope, and use bounded native svn
fallback steps for that operation. Retry the MCP later and prefer it again when it returns a usable
response; do not use the fallback to bypass a guard refusal.
Non-guard failures retain bounded path-sanitized stdout/stderr diagnostics outside full mode;
compact guard refusals return only a typed guard code, one-line reason, and affected-path count.
Other development/test escape hatches are SVN_AGENT_BIN_DIR, SVN_AGENT_SVN_PATH, SVN_AGENT_DOS2UNIX_DIR,
SVN_AGENT_TIMEOUT_MS, SVN_AGENT_MAX_DIFF_LINES, SVN_MCP_HASH_CONCURRENCY, and
SVN_MCP_MAX_HASH_BYTES. Hashing defaults to four concurrent files and a 1 GiB aggregate explicit
scope; narrow the path scope before raising either bound.
High-volume reads are bounded by default. Log messages and changed paths are capped and opt-in
where appropriate. Diff collection defaults to 200 lines, compact excerpts are capped at 3,000
characters, compact logs are capped at 24 KiB, and compact diff results retain transport headroom
below a 32 KiB JSON-RPC record.
maxChars and maxFiles are upper requests: the response may return less with independent
nextCursor and nextFileCursor values. Large file/property/status/EOL collections expose
explicit continuation cursors.
Buffered SVN commands fail with a scoped diagnostic above 20 MB. Streamed diff lines are capped at
1 MiB each, and per-file diff summaries are capped at 20,000 entries; either truncation is reported.
Public path arrays accept at most 500 entries, and individual filesystem paths are capped at 4,096
characters.
Compact mode changes response size only; path containment, mutation guards, EOL checks,
mixed-revision checks, and commit verification run unchanged.
Use svn_diff diffMode:"counts" for totals only or "hunk-headings" for one meaningful line per
file plus omitted-hunk counts. A returned operationId binds later cursor pages to the same bounded
process-local evidence, so continuation does not rerun SVN against a changing working copy. Evidence
expires after 10 minutes and is limited to 2 MiB per operation, 32 operations, and 16 MiB total.
svn_log messageContains performs a bounded server-side scan; changedPathsSummary:true returns
per-revision action counts and top-level directories without listing every path. Large updates can
use maxItems, taskPaths, and targetOverlapOnly to keep unrelated paths out of the receipt while
making complete conflict evidence available through bounded conflictCursor pages.
Runner-level line/output truncation is carried into the operation evidence, so a final retained page
cannot be mistaken for the complete source diff.
Normal responses use working-copy-relative paths. High-use tools accept a validated fields
array; the allowed names are published once under globalResponseControls.fieldProjections in
docs/MCP_API.json so the live MCP does not repeat those lists in every tool schema. Invalid
fields are rejected before any SVN process starts. Focused docs and review profiles advertise
only compact, receipt, and structured-only; known callers may still explicitly request
standard/full diagnostics, but switching to the full profile is clearer for diagnostic work.
High-volume controls are likewise published once under
globalResponseControls.advancedInputs in docs/MCP_API.json, rather than repeated in every live
tool schema. They include afterCursor for status/snapshot polling, diff file/operationId,
bounded log filtering and summaries, and update paging/overlap controls. Snapshot tokens are opaque,
working-copy and query bound, process-local, and expire after 15 minutes. Repeating the same status
or snapshot with afterCursor returns a minimal NO_CHANGE receipt; changed or safety-relevant
state returns the current bounded result and a replacement token.
For multi-client editing, svn_snapshot captureBaseline:true on explicit files returns a separate
pre-edit baseline token. Pass it to svn_update baselineToken to receive path-level local-edit,
remote-touch, conflict, and same-path-collision evidence. Directory baselines are refused because
directory metadata cannot prove which descendant changed.
Conflict lists use independent pages of at most 100 paths; conflictCount, conflictsTruncated, and
nextConflictCursor make omitted pages explicit without inflating every status or update response.
svn_commit refuses existing directory targets by default because its deliberate --depth empty
behavior commits only the directory node and excludes changed descendants. Prefer explicit file
paths. Set expandDescendants:true to expand a named directory to its currently changed descendants,
guard every result, and return the exact expanded scope. Set allowDirectoryTargets:true only when
intentionally committing a directory property or another directory-node-only change.
svn_precommit accepts the same scope controls so its readiness verdict matches the later commit.
A READY precommit also returns a short-lived precommitToken bound to exact path status, base
revisions, content hashes, repository policy, diff identity, and observed remote revision. Passing
that token to svn_commit makes the commit refuse if the verified state changed in between.
Commit messages for svn_commit and svn_import require a subject, a blank second line, and at
least one - verification bullet. A svn_commit scope with more than 8 paths requires
riskAck:true; exactly 8 paths does not trigger this path-count signal. Other risk signals keep
their existing G6 behavior.
Release workflows can pin svn_update with an exact revision; it still requires explicit paths
or updateAll:true and always postpones conflicts. Add expectedRemoteHead with a numeric revision
to refuse if repository HEAD moved since the caller's probe. Use
svn_precommit requireUniformRevision:true when a release handoff must not proceed from a
mixed-revision working copy. Ordinary precommit work does not warn about mixed revisions.
Parallel agents can create a valid mixed-revision working copy. A commit receipt may report
working_copy_mixed:true in full mode while the commit remains valid. baseRevision:null means no single base
revision describes every committed path; use baseRevisionRange for the useful range. Treat mixed
state as evidence, not failure by itself. Check the separate out-of-date and conflict diagnostics
before deciding whether to stop.
Compact OUT_OF_DATE refusals identify bounded outOfDatePaths, outOfDatePathCount, and
outOfDatePathsTruncated fields. They retain workingCopyMixed and revisionRange when both
conditions are present.
An exact-file svn_update reports scopeKind:"exact-file" and scopeComplete:false because it
does not prove that sibling repository additions were fetched. omittedRepositoryAdditions lists
bounded missing siblings, and recommendedAction:"update-containing-directory" points to the
directory-complete follow-up. Directory and working-copy updates report their own scopeKind and
can report scopeComplete:true when the selected scope is complete.
If bounded SVN metadata cannot classify every target, the result uses scopeKind:"unknown" and
scopeComplete:false. scopeCheckUnavailableReason explains the failure, and
recommendedAction:"inspect-target-metadata" directs the next check. Omitted-addition counts are
not authoritative for an unknown scope.
svn_commit keeps postStatusClean for compatibility, but it applies only to the committed path
scope. Read postStatusScope:"committed-paths" and postStatusPaths to identify that scope.
trackedClean reports whether tracked changes remain, while untrackedCount reports unknown
scratch paths separately. The legacy workingCopyClean field remains the strict whole-working-copy
check. Do not infer whole-working-copy cleanliness from postStatusClean.
svn_commit operation:"prepare" performs a pinned update of explicit intended paths with conflicts
postponed, checks an optional expected remote HEAD, refuses any path touched outside that scope, and
then runs the normal guarded precommit checks. It never commits. Its compact receipt reports the
resulting revision, conflicts, updated paths, and exact final commit scope. Keeping preparation as
a mode of the existing commit workflow avoids loading another tool schema.
svn_commit operation:"safe" performs the guarded sequence in one durable call: pinned scoped
update, baseline collision refusal, automatic verified EOL repair when precommit requests it,
precommit binding, commit, pinned update to the committed revision, and a final clean scoped
snapshot. It requires an explicit numeric revision, expectedRemoteHead, pre-edit
baselineToken when an earlier edit-session baseline is available, valid commit message, explicit
paths, and UUID operationId. Without a token it captures the current explicit-file state before
update, keeping the common workflow to one call. Its normal response is a compact receipt. Use
operation:"detail" with the returned detailOperationId and cursor to
page bounded stage evidence only when an audit needs it. This adds no advertised tool schema; the
full profile advertises 30 canonical tools. The focused docs and review profiles include
svn_help so agents can load one tool's extended rules on demand.
Scheduled-added files are not valid svn update operands, so safe mode omits only those files from
the pinned update while still verifying the expected repository HEAD. They remain in the exact
precommit and commit scope.
Mutation retries can include a UUID operationId on svn_update, svn_commit (including prepare
and safe mode),
eol_fix_verified, svn_resolve, svn_lock, svn_unlock, and svn_needs_lock. The server binds that ID to normalized inputs and stores a
bounded receipt outside the working copy. An identical retry replays the prior result after a client
timeout or MCP restart; a concurrent or changed request with the same ID is refused. The receipt is
local to one machine, not a distributed lock between machines. SVN_MCP_OPERATION_DIR can relocate
the store when an operator needs a different profile-data location.
The resolved store path is refused when it sits inside any SVN working copy. Terminal receipts and
orphan lock/temp files are pruned within fixed count, byte, age, and record-size limits; retained
unfinished or unreadable records are never deleted to make room, so new operations fail closed when
those records exhaust capacity.
Repository locks
Use svn_lock and svn_unlock for repository locks shared by working copies on different
machines. svn_lock requires a non-empty comment. When no label is supplied, the server derives
one from SVN_MCP_WORKSTATION_LABEL or the local machine hostname, normalized to
[A-Za-z0-9._-] and limited to 64 characters. The server stores the bounded comment as
[svn-agent-mcp workstation=<label>] <comment>.
svn_lock_status compares local and repository svn info --xml state and returns only a boolean
for local token possession. It never returns a lock token. Normal unlock refuses a mismatched
working-copy token; stealing a lock requires force:true, forceAck:true, and a UUID
operationId. svn_needs_lock sets svn:needs-lock=* or removes it from regular versioned files;
removal requires riskAck:true.
Lock status reports held-elsewhere, orphaned-token, and stale-candidate diagnostics. A stale
candidate is a lock older than seven days. All lock and property mutations keep the normal
working-copy containment, never-commit, durable-receipt, and --readonly guards.
svn_snapshot remains the no-friction daily entry point. Its compact response includes the
working-copy root, repository URL/root, changed and conflict counts, and remote HEAD. Pass
includeLockState:true when the agent needs a bounded lock summary; the extra repository probe
is opt-in.
The server also publishes MCP workflow prompts for inspection, safe update, safe commit, EOL repair, lock/edit/unlock, and failed-commit diagnosis. They reduce repeated agent instructions without adding another tool call.
Host approval settings
The package does not edit Codex configuration. Set host policy outside the repository when the server must run without approval prompts:
approval_policy = "never"
[mcp_servers.svn]
default_tools_approval_mode = "approve"Every registered SVN tool advertises annotations.destructiveHint = false. The host settings above
are persistent server-scoped configuration; keep them in the host Codex config, not in npm package
code or a working copy.
Repositories can make EOL handling automatic for new files:
{
"normalizeEol": "crlf",
"eolExclude": ["**/*.patch", "**/*.diff"]
}With this in .svn-mcp-policy.json, svn_add normalizes and verifies new text files in the same
call, skips binaries and excluded byte-exact fixtures, and refuses before scheduling if verification
fails. eol_fix_verified also accepts a bounded explicit paths batch for tracked-file repairs.
svn_diff and svn_blame ignore EOL-only churn by default; use showEolChanges:true only for EOL
diagnostics.
Verified EOL recovery
For a standalone repair or diagnostic, use this sequence for a tracked file with LF, mixed line endings, or BOM damage:
Call
eol_checkon the explicit path and recordkind,has_bom, andmismatch.Call
eol_fix_verifiedon each failing path when you need an explicit repair receipt. It applies the repository target, removes the BOM by default, hashes canonical LF/no-BOM content, and preserves concurrent edits or guarded paths.Call
svn_diffwithignoreEol:true. An empty content diff oreolOnly:trueproves that the repair changed line endings only. Remaining additions, removals, or property changes need review.
For example, an LF file with a BOM reports kind:"lf", has_bom:true in eol_check; after
eol_fix_verified, after.has_bom:false and pure_eol_churn:true provide repair evidence. The
final svn_diff({"paths":["src/example.cs"],"ignoreEol":true}) call proves byte/content intent
without dumping an unbounded diff.
svn_precommit, svn_commit, svn_prepare_commit, and svn_commit operation:"safe"
default to autoFixEol:"safe". For each explicit failing text file, the server snapshots the current
working bytes, normalizes a temporary copy, and proves the two are identical after canonicalizing
line endings only. Intended content and property changes remain visible in the normal SVN diff and
do not block EOL repair. The current encoding, BOM, and final-newline presence must be preserved.
Set autoFixEol:"off" only for a diagnostic-only check.
Mixed profiles containing lone CR bytes fail with EOL_LONE_CR_CHANGED, preventing raw CR inside
strings or embedded content from being rewritten. Genuine CR-only classic-Mac files use
mac2unix before conversion to the declared target.
Newly added text files use the same working-snapshot proof without requiring BASE. Safe mode uses
an explicit svn:eol-style or .svn-mcp-policy.json normalizeEol target, verifies valid UTF-8 and
normalized-content identity, preserves any current BOM, applies only that explicit file, and issues
the precommit token in the same call. An explicit file property takes precedence over repository policy;
the implementation never infers EOL policy from neighboring files. Added files can be normalized
alongside ordinary modifications in the same explicit scope, including calls from a subdirectory.
Compact commit receipts omit per-file hashes; request fields:["contentHashes"] or
responseMode:"full" when needed. Token-bound commits include diffStat from the validated
precommit diff: total added/removed lines and up to 25 paths / 4 KiB of file entries. Larger
scopes report filesTruncated:true; full output includes all available entries. Statistics
describe the checked content diff, ignoring EOL, and complete:false means counts are partial.
Precommit returns a copy-ready svn_diff nextAction when captured diff evidence has another
page. Permanently capped evidence reports diffEvidenceCapped:true without a retry loop. NUL keeps
the historical binary refusal. Other C0/DEL controls remain text and are reported as advisories
with hexadecimal value, byte offset, line, and 1-based byte column.
Compact repair evidence includes autoEolRepairs with target and content/BOM/final-newline checks,
plus autoEolRemainingFailures when any explicit path still needs attention.
Agents do not need to discover these workflows in this README first. The advertised tool
descriptions state the normal defaults, and exceptional results provide a copy-ready nextAction.
Advanced fields remain out of focused schemas where possible so discovery does not increase the
token cost of every session. See
ADR-015.
The full profile advertises every runtime-supported advanced input. Focused profiles keep those
fields out of their always-loaded schemas, while svn_help lists the exact names from the same
capability registry. EOL help also identifies the real dos2unix/unix2dos converters and the
SVN_AGENT_DOS2UNIX_DIR, bundled-runtime, then PATH lookup order.
Commands
Command | Description |
| Run the TypeScript entry point during development |
| Verify the minimum Node.js and npm versions |
| Check TypeScript without emitting build output |
| Compile |
| Generate |
| Fail when the generated MCP API contract is stale |
| Run the Jest test suite |
| Pack, install, and self-check the real npm artifact in isolation |
| Compare compact MCP, full MCP, and equivalent raw SVN output sizes |
| Fail when representative compact responses or schemas exceed token budgets |
| Build and prepare the local |
| Copy |
| Remove root |
Operator Diagnostics
Use svn_self_check to verify the MCP package, runtime layout, resolved native or bundled tools, and release scripts. Use svn_diagnose on a working-copy path when SVN itself is acting strange; it checks local status, remote status, HEAD info, latest log reachability, and returns actionable notes for authentication, network, lock, and working-copy database failures.
Use svn_snapshot for a one-call status and revision summary. Exact ignored descendants are reported with their covering ignored ancestor instead of disappearing behind SVN's W155010 warning. svn_log and svn_diff accept exact or ranged revision selectors; multi-entry log envelopes report an explicit revision range and entry count. Bounded svn_cat and svn_blame calls support historical file inspection without raw SVN output. Mutations include dry-run-first svn_delete, canonical svn_resolve, and svn_path_change with an explicit move, rename, or copy action. Legacy direct calls to svn_resolved, svn_move, svn_rename, and svn_copy remain callable in the full profile for compatibility but are no longer advertised.
For SVN property work, use svn_propget and guarded svn_propset instead of raw svn propget/svn propset. svn_propset_eol_style remains the safer shortcut for svn:eol-style normalization.
Changelog
Release history is maintained in CHANGELOG.md.
Layout
Path | Purpose |
| MCP server implementation |
| SVN XML/text parsers |
| MCP tool families |
| Unit and temp-repository integration tests |
| Repo-local guard exceptions for this MCP's intentional runtime payloads |
| Versioned Windows SVN and EOL converter runtime binaries |
| License and notice texts shipped with the bundled runtime |
| Notices for bundled binary payloads |
| Spec, generated MCP API contract, local rules, and decisions |
| Generated versioned runtime release payloads, ignored by Git |
Usage Model
Register one global MCP server and use explicit paths or per-call cwd values when working across SVN checkouts. The server does not assume a product name, project name, or fixed working copy.
Available Tools
23 toolseol_checkA
Inspect EOL kind, BOM, and svn:eol-style for explicit files.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| paths | Yes | Explicit paths relative to cwd or absolute paths inside one SVN working copy. |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must carry the burden. The verb 'Inspect' implies a read-only operation, but the description does not explicitly state that no modifications are made, nor does it disclose any side effects, error behavior, or performance characteristics. This is minimally adequate for a simple inspection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 10 words. Every word conveys essential information with no redundancy or fluff. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, so the description should ideally hint at the return format or behavior. It does not mention what the inspection yields (e.g., a list of files with properties). Given the simplicity and the existence of sibling tools, this is acceptable but not complete. Scores 3 as adequate but could be better.
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 100%, so both parameters (cwd and paths) are already documented. The description adds no additional semantics beyond the schema, which is the baseline expectation. No improvement or degradation.
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?
The description clearly states the action ('Inspect') and the specific items (EOL kind, BOM, svn:eol-style) for explicit files. This distinguishes it from sibling tools like eol_fix_verified (fixes EOL) and svn_propset_eol_style (sets property), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like eol_fix_verified or svn_propset_eol_style. There is no mention of prerequisites, context, or scenarios where inspection is appropriate. The agent must rely solely on the tool name and purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eol_fix_verifiedC
Convert one file's EOL with unix2dos/dos2unix inferred from svn:eol-style, then verify the ignored-EOL diff.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| path | Yes | ||
| dryRun | No | ||
| target | No | ||
| removeBom | No | ||
| allowLarge | No |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It mentions conversion and verification but does not explain that the tool modifies the file (destructive action), how inference from svn:eol-style works, what happens on failure, or the implications of the 'ignored-EOL diff' verification step. This leaves significant gaps in understanding tool behavior.
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?
The description is a single sentence, which is concise, but it omits critical details about parameters and behavior. It is not inefficiently verbose, but it sacrifices completeness for brevity, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involves SVN, EOL conversion, verification), no output schema, and minimal annotation support, the description is far from complete. It does not explain return values, error handling, verification semantics, or constraints like file size (allowLarge), making it insufficient for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only 'cwd' described). The tool description adds no parameter-level details; it does not mention path, dryRun, target, removeBom, or allowLarge. For a tool with 6 parameters and low schema coverage, the description fails to compensate, leaving parameter meanings entirely undocumented.
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?
The description states a specific action: convert a file's EOL style using unix2dos/dos2unix, inferred from svn:eol-style, then verify the diff. This clearly distinguishes it from siblings like eol_check (check only) and svn_propset_eol_style (set property, not convert file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks context about prerequisites (e.g., svn:eol-style must be set), when verification is needed, or when other tools like eol_check or svn_propset_eol_style are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_addC
Guarded svn add for explicit files, adding needed parent directories, or explicitly recursive directories.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| paths | Yes | Explicit paths relative to cwd or absolute paths inside one SVN working copy. | |
| allowRecursive | No |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'guarded' and automatic parent directory addition, but does not explain what 'guarded' entails, error handling, or side effects like conflict detection. Insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no redundant words. Maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of svn add (side effects, error scenarios) and lack of output schema, the description is too brief. It does not cover return values, error conditions, or prerequisites, leaving the agent underinformed.
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 67% (2 of 3 parameters described). The description adds context to paths (auto-adds parent directories) and allowRecursive (explicit recursion), but does not fully compensate for the undocumented allowRecursive parameter. Baseline 3 is appropriate.
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 clearly identifies the tool as an 'svn add' operation with specific behaviors (adding parent directories, explicitly recursive). It distinguishes it from other svn tools, though not explicitly from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., svn_commit, svn_revert). The term 'guarded' hints at caution but does not specify conditions or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_cleanupC
Run svn cleanup without destructive cleanup flags.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| path | No |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the tool is non-destructive ('without destructive cleanup flags'), but fails to describe what the tool actually does, such as removing locks or cleaning up unfinished operations, whether it modifies files, or requires network access.
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?
The description is concise at one sentence, but it sacrifices necessary detail for brevity. While it is structured and front-loaded, it could be slightly expanded to include more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, side effects, prerequisites (like being inside an SVN working copy), or how the tool interacts with the working copy. The context is incomplete for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 50% description coverage (only 'cwd' is described). The description adds no information about parameters, so it does not compensate for the missing schema description of 'path'. An agent would not understand what 'path' signifies without relying on SVN knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it runs 'svn cleanup' without destructive flags, which is clear but vague. It doesn't elaborate on what the svn cleanup command does (e.g., removing working copy locks), and while it hints at being non-destructive, it doesn't fully distinguish from sibling tools like svn_revert or svn_resolved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools like svn_revert, svn_update, and svn_resolved exist, but the description gives no context about appropriate scenarios (e.g., after an interrupted SVN operation) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_commitC
Guarded svn commit using a temp -F message file and explicit paths.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| paths | Yes | Explicit paths relative to cwd or absolute paths inside one SVN working copy. | |
| message | Yes | ||
| riskAck | No |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. 'Guarded' is vague—does not explain the guard mechanism, failure behavior, or whether it is safe. The riskAck parameter is mentioned in schema but not in description, leaving the guard undefined.
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?
A single, front-loaded sentence. No wasted words, but may be too brief. The structure efficiently conveys the core action and method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, 50% schema coverage, no output schema, and 22 siblings, the description is insufficient. It does not explain return values, error handling, or the guard's conditions. The riskAck parameter is critical for safe use but unaddressed.
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 50% (cwd, paths have descriptions; message, riskAck do not). The description adds 'explicit paths' and 'temp -F message file', providing context for paths and message usage. However, riskAck's purpose is not explained, limiting added value.
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 states it is a 'svn commit' operation, which is specific. The term 'guarded' hints at safety but is ambiguous. It distinguishes from siblings by mentioning the temp file method, but could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives. Among 22 SVN siblings, it does not differentiate when to use this vs svn_precommit or svn_revert. The agent must infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_copyC
Guarded working-copy svn copy with parent directory creation.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| src | Yes | ||
| dest | Yes |
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions parent directory creation, which is a key behavior, but does not disclose other important traits like whether existing files are overwritten, error handling, or required permissions. Since no annotations exist, the description carries full burden and falls short.
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?
The description is extremely concise, capturing the core purpose in a single phrase. However, it is so brief that it sacrifices clarity on important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an svn copy operation and no output schema, the description is incomplete. It lacks details on return values, error cases, and the meaning of 'guarded'. More context is needed for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only cwd has a description). The description adds no information about src or dest parameters, leaving their semantics ambiguous. It does not compensate for the low coverage.
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 states it's an 'svn copy' operation on the working copy with parent directory creation. The verb and resource are clear (copy within working copy), but it does not explicitly distinguish from sibling tools like svn_move or svn_export, though the mention of 'working-copy' helps narrow scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as svn_move or svn_add. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_diagnoseA
Read-only working-copy diagnostics for local status, remote status, HEAD info, and latest log reachability.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| paths | No | Optional paths relative to cwd or absolute paths inside one SVN working copy. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explicitly states 'Read-only', indicating no destructive actions. It lists the diagnostic categories, giving a clear expectation of behavior. It does not mention potential performance impacts or limitations, but the read-only nature and scope are well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It is front-loaded with the key information ('Read-only working-copy diagnostics') and then elaborates on scope. No unnecessary words.
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?
Given that there is no output schema, the description adequately summarizes the expected output by listing the diagnostic areas. The tool is moderately complex (multiple diagnostics), but the description covers the main aspects. It could benefit from mentioning the output format or ordering, but it is sufficient for an agent to understand the tool's capability.
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 not add additional meaning beyond what the schema provides for the 'cwd' and 'paths' parameters. Both parameters are already described in the schema, so no extra value is added.
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?
The description clearly states the tool is for 'Read-only working-copy diagnostics' and lists specific diagnostic areas: local status, remote status, HEAD info, and latest log reachability. It uses specific verbs and resources, and distinguishes from siblings by being a combined diagnostic tool covering multiple aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for diagnostics and notes it is read-only, which suggests when not to use it (modifications). However, it does not explicitly differentiate from sibling tools like svn_status, svn_info, or svn_log, nor does it provide clear guidance on when to prefer this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_diffB
Run scoped svn diff; ignore-EOL is enabled by default with internal diff and returns per-file counts.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| paths | Yes | Explicit paths relative to cwd or absolute paths inside one SVN working copy. | |
| ignoreEol | No | ||
| lineLimit | No |
TDQS
B3.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that ignore-EOL is enabled by default for internal diff and that the output returns per-file counts. This adds value beyond the schema, which has no annotations. However, it does not cover all behavioral aspects like output format or authorization.
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?
The description is a single sentence with no wasted words. It front-loads the purpose and adds key behavioral details. Slightly more structure could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of SVN diff, the description omits important context such as what 'per-file counts' entails, output format (unified?), and handling of errors. With no output schema and no annotations, the description should provide more guidance.
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 50% (2 of 4 parameters have descriptions). The description adds a default for ignoreEol, but does not explain lineLimit or paths beyond what the schema provides. It partially compensates for the low coverage.
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 states 'Run scoped svn diff', which clearly identifies the verb (diff) and resource (SVN). 'Scoped' is somewhat vague, but it distinguishes from other svn tools like svn_log or svn_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like svn_log or svn_status. There is no mention of prerequisites or context-specific usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_exportC
Run explicit svn export.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| src | Yes | ||
| dest | Yes | ||
| revision | No |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It fails to mention that svn_export creates a clean copy without .svn directories, or that it can operate on URLs or working copies. The only statement is a reiteration of the command name.
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?
The description is maximally concise at five words, but it sacrifices necessary detail. It is front-loaded in the sense of being short, but it fails to earn its place by providing value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4-parameter input with low schema coverage, no output schema, and a large sibling set, the description is far from complete. It does not help an agent understand how to invoke the tool correctly or what to expect from the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only cwd has a description). The description does not explain src, dest, or revision parameters. Critical information about what these parameters represent (e.g., source path/URL, destination path) is missing.
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 'Run explicit svn export' clearly identifies the verb (export) and resource (svn). It distinguishes from siblings like svn_checkout or svn_add due to the specific SVN command naming. However, it assumes familiarity with 'svn export' and does not elaborate on the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list includes many svn_* commands, but the description gives no context for choosing svn_export over, e.g., svn_checkout or svn_import.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_importC
Run svn import with a temp -F message file.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| src | Yes | ||
| url | Yes | ||
| message | Yes |
TDQS
C2.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description has the full burden of disclosing behavior. It mentions using a temporary file for the message, which is a minor behavioral hint. However, it does not state that the command modifies the repository, requires network access, or whether it is destructive. The return value or side effects are not described.
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?
The description is very concise, at only one sentence. While there is no wasted text, it lacks essential details, making it under-described. It is not verbose, but conciseness should not come at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters (three required without schema descriptions) and no output schema, the description is critically incomplete. It does not explain what the tool does, what the parameters represent, or what outcome to expect. This is a significant gap for an AI agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 25% description coverage (only 'cwd' has a description). The description adds minimal value: it implies 'message' is used via a temp file, but it does not explain the meaning of 'src' or 'url'. For a required parameter that is undocumented in the schema, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Run svn import', which identifies the operation as the SVN import command. However, it does not explain what import does (e.g., importing a local directory into a repository). For users unfamiliar with SVN, the purpose is vague. Among siblings, it is distinguishable by name, but the description lacks a clear, self-contained purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use svn_import versus alternative tools like svn_add or svn_commit. It does not mention prerequisites (e.g., source directory, remote URL) or typical usage scenarios. This leaves the AI agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_infoA
Run svn info and detect mixed-revision working-copy state.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| paths | No | Optional paths relative to cwd or absolute paths inside one SVN working copy. |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It adds value by mentioning mixed-revision detection beyond standard 'svn info'. However, it omits details about side effects, permissions, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 10 words, no waste. Front-loaded with action and key feature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with well-documented schema parameters, but lacks return value description, error conditions, and when mixed-revision detection triggers.
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% (both parameters have descriptions). The tool description does not add extra meaning beyond the schema, so baseline score of 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?
The description clearly states it runs 'svn info' and additionally detects mixed-revision state, using a specific verb and resource. It distinguishes from sibling tools like svn_status or svn_diff by highlighting the mixed-revision detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., svn_status, svn_log). The description does not specify prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_logC
Run svn log and return structured log entries.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| limit | No | ||
| paths | No | Optional paths relative to cwd or absolute paths inside one SVN working copy. | |
| verbose | No |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not state whether the operation is read-only, destructive, or requires authentication. The phrase 'return structured log entries' implies a read operation, but this is not explicit.
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?
The description is a single sentence, which is concise, but it lacks critical details about usage, parameters, and effects. It is too minimal to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is far from complete. It does not explain return values, error cases, or prerequisites (e.g., working copy requirement).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with cwd and paths documented but limit and verbose lacking descriptions. The tool description adds no parameter details beyond what the schema provides, failing to compensate for the low coverage.
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 clearly states it runs 'svn log' and returns structured log entries, which is specific to the svn_log command. It distinguishes from sibling tools like svn_add, svn_commit, etc., all of which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use svn_log versus other svn tools like svn_info or svn_status. The description does not mention circumstances or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_moveC
Guarded working-copy svn move with parent directory creation.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| src | Yes | ||
| dest | Yes |
TDQS
C2.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The term 'guarded' is vague – does it mean validation, rollback, or something else? There is no disclosure about handling conflicts, whether the source is deleted, or what constitutes a 'guard'. The parent directory creation is mentioned but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified. It omits critical details like parameter behavior, error states, and examples. The brevity comes at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, low schema coverage, and missing usage guidelines, the description fails to provide enough context for an agent to use the tool correctly. The tool has 3 parameters with 2 required, but the description only hints at the move behavior without covering the parameters or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, with only 'cwd' having a description. 'src' and 'dest' lack descriptions. The description adds that parent directories are created for the destination, which provides some meaning, but the missing descriptions for src and dest make it difficult to understand required formats (e.g., should they be absolute or relative? Are they file paths or URLs?).
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 'Guarded working-copy svn move with parent directory creation' clearly indicates it performs an SVN move with extra safety and parent directory creation. However, it does not differentiate from sibling tools like svn_rename or svn_copy, which could be similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like svn_rename, svn_copy, or svn_revert. The description implies a guarded move but lacks context on prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_precommitC
Composite read-only precommit check: status, ignore-EOL diff, EOL check, guard dry-run, and mixed-revision warning.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| paths | Yes | Explicit paths relative to cwd or absolute paths inside one SVN working copy. | |
| lineLimit | No |
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'read-only' but does not disclose what happens if checks fail, how results are aggregated, or any side effects (e.g., no destructive actions). The list of components is vague.
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?
The description is a single sentence that is concise and front-loaded with the key concept 'composite read-only precommit check'. It efficiently lists components, though could benefit from more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a composite tool and no output schema, the description is too brief. It lists components but does not explain what each check does, how results are returned, or what warnings look like. Incomplete for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. Schema coverage is 67% (cwd and paths have descriptions, lineLimit has constraints but no description). The description adds no value beyond the schema for understanding parameter usage.
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 clearly states it's a composite read-only precommit check and lists the components (status, diff, EOL check, etc.), which distinguishes it from sibling tools that only perform one of these tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this composite tool versus running individual sibling tools (e.g., svn_status, eol_check, svn_diff). The description lacks explicit usage context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_propgetB
Read one working-copy property from explicit paths.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| name | Yes | ||
| paths | Yes | Explicit paths relative to cwd or absolute paths inside one SVN working copy. |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It only states the basic action, omitting details such as behavior when a property does not exist (error vs. empty), whether the operation is recursive, or how multiple paths are handled. This leaves significant behavioral ambiguity.
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?
The description is a single, efficient sentence with no wasted words. It front-loads the core purpose but could benefit from additional context without becoming verbose. Given its brevity, it scores high but loses a point for slight under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description is insufficiently complete. It does not explain return values, edge cases (e.g., missing property), or operational constraints. A more complete description would address these aspects briefly.
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 67% (two of three parameters have descriptions). The description adds minimal value beyond the schema, simply reiterating that it reads a property. The schema already defines parameter names and constraints (e.g., pattern for 'name', path descriptions). Thus, the description does not significantly enhance parameter understanding.
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?
The description clearly states the verb ('Read'), the resource ('working-copy property'), and the scope ('from explicit paths'). It effectively distinguishes this tool from its siblings, such as 'svn_propset' which is for writing properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks prerequisites, exclusion criteria, or comparisons to related tools like svn_propset or svn_info. This omission leaves the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_propsetC
Guarded working-copy svn propset for explicit paths.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| name | Yes | ||
| paths | Yes | Explicit paths relative to cwd or absolute paths inside one SVN working copy. | |
| value | Yes | ||
| riskAck | No |
TDQS
C2.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The term 'Guarded' hints at a safety feature, but it is not explained. The presence of the 'riskAck' parameter is not mentioned, and the description does not clarify what happens if it is false or other constraints. The description fails to provide sufficient transparency about the tool's behavior.
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?
The description is very concise at 7 words, but it sacrifices essential details. While it is front-loaded with the key action 'propset', the brevity leads to ambiguity. Every sentence should add value, and here the single sentence is too minimal to be fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (3 required), no annotations, and no output schema, the description is severely lacking. It does not explain the 'guarded' concept, the required 'riskAck' field, or what the tool returns. The description is inadequate for an AI agent to understand the tool's full context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters with only 40% description coverage (cwd and paths have descriptions). The tool description adds no information about any parameters, failing to compensate for the low coverage. Parameters like 'riskAck' remain completely unexplained, making it difficult for an AI agent to use the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it's an svn propset for a working copy, which clearly identifies the verb and resource. However, the term 'Guarded' is vague and does not fully distinguish from sibling tools like svn_propset_eol_style. The description lacks specificity about what makes this tool different from other propset-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions 'explicit paths' as a constraint, but provides no guidance on when to use this tool versus alternatives like svn_propset_eol_style. There is no mention of prerequisites, exclusions, or context where other tools would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_propset_eol_styleA
Set svn:eol-style only for explicit files whose property is missing or mismatched.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| paths | Yes | Explicit paths relative to cwd or absolute paths inside one SVN working copy. | |
| style | No |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses conditional behavior (only for missing/mismatched) but doesn't mention permissions, reversibility, or side effects. Adequate for a simple set operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, precise and front-loaded. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; return value not described. For a set operation, basic info on success/error is missing, but given low complexity, it's partially adequate.
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 covers 67% of parameters with descriptions (cwd, paths). Description adds meaning that paths must be explicit files and operation is conditional, compensating for missing style description.
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?
Description clearly states it sets svn:eol-style for files that are missing or mismatched. It distinguishes from sibling tools like svn_propset (general) and eol_fix_verified.
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?
Indicates when to use (files with missing/mismatched eol-style) but no explicit comparison with siblings or when-not to use. Context is clear enough for an agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_renameC
Alias for guarded working-copy svn move/rename with parent directory creation.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| src | Yes | ||
| dest | Yes |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must carry burden. Discloses 'guarded' and parent directory creation, but 'guarded' is vague. Does not mention destructive nature, permissions, or error behavior.
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?
Description is very short (12 words), which aids quick reading, but at the expense of necessary detail. Could be restructured to include more information without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and no annotations, the description is incomplete. Missing return values, prerequisites, error handling, and elaboration on the 'guarded' behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only cwd described). Description adds minimal info: implies src and dest are source/destination paths, but no format or constraints. Fails to compensate for low schema coverage.
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?
States it's an alias for svn move/rename with parent directory creation, clearly indicating action and resource. Distinguishes from svn_move by noting it's 'guarded', but could be more explicit about differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like svn_move. No when-not-to-use or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_resolvedC
Resolve one conflicted path with an explicit accept mode.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| path | Yes | ||
| accept | Yes |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether it is destructive, what happens to conflict markers, or any side effects. It only states the basic action.
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?
The description is a single, clear sentence with no redundancy. It is appropriately concise for a simple tool, though it could benefit from slightly more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description is too minimal. It fails to explain the accept modes, prerequisites (e.g., a conflict must exist), or the outcome of resolution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage, the description adds little beyond the schema. It mentions 'explicit accept mode' but does not explain the meaning of each accept value or the path and cwd parameters.
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?
The description clearly states the verb 'resolve', the resource 'conflicted path', and the key aspect 'explicit accept mode'. It distinguishes from sibling tools like svn_revert which handles different scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like svn_revert or other conflict handling methods. It lacks any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_revertB
Preview or perform guarded svn revert for explicit paths.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| paths | Yes | Explicit paths relative to cwd or absolute paths inside one SVN working copy. | |
| dryRun | No | ||
| allowRecursive | No |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It mentions 'guarded' but does not explain what guards exist (e.g., safety checks, irreversible changes). No info on side effects, permissions, or error states.
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?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. It is concise but could incorporate more details without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is too sparse. It does not explain return values, error scenarios, or prerequisites like having a clean working copy. The term 'guarded' is ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (cwd and paths have descriptions; dryRun and allowRecursive have none). The tool description adds no further detail about these parameters, failing to compensate for the schema gap.
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?
The description clearly states the tool performs 'svn revert for explicit paths', specifies 'preview or perform', and uses the term 'guarded' to hint at safety checks. It effectively distinguishes from other svn tools by focusing on explicit paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Preview or perform' implies a dry-run option, but no explicit when-to-use or when-not-to-use guidance is provided. Alternatives among siblings (e.g., svn_cleanup, svn_diagnose) are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_self_checkB
Report MCP release pointer, bundled runtime payload counts, startup probe, and packaging script health.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what is reported but does not state whether the tool modifies state, requires special permissions, or any other behavioral traits. As a 'check', it likely is read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently lists the reported items. No unnecessary words, front-loaded with verb 'Report'. Every part adds value.
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 self-check diagnostic tool with no output schema, the description lists the key items reported. It lacks detail on the return format (e.g., boolean, text, structured data), but given the tool's nature, it is mostly sufficient. Could mention if the tool also returns actionable status.
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% (the cwd parameter is well-documented in the schema), so the description does not need to add parameter details. The tool description itself does not elaborate on parameters, which is acceptable given the schema coverage. Baseline 3.
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?
The description clearly states the tool reports specific items (MCP release pointer, runtime payload counts, startup probe, packaging script health), giving a specific verb and resource. It distinguishes itself from sibling tools which are all standard SVN operations, so an agent can see this is a diagnostic/self-check tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Since siblings include other check tools like eol_check, but the description doesn't explain the context or when to prefer svn_self_check over them. The agent is left to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_statusB
Run scoped svn status and return structured changed paths and conflicts.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| paths | No | Optional paths relative to cwd or absolute paths inside one SVN working copy. | |
| hideNoise | No | ||
| includeIgnored | No |
TDQS
B3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the output (structured changed paths and conflicts) but does not disclose if the command modifies anything, authentication requirements, or performance implications. It implies a read-only operation but does not confirm safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no extraneous words. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and low schema coverage, the description is too brief. It does not explain key parameters like hideNoise and includeIgnored, nor does it describe the return format in sufficient detail. The tool's behavior in edge cases (e.g., no changes) is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; two parameters (hideNoise, includeIgnored) lack schema descriptions and the tool description adds no further explanation. The description does not augment the schema beyond stating the tool is 'scoped'. Parameter meaning remains unclear.
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 clearly states the tool runs 'svn status' and returns structured changed paths and conflicts. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like svn_diff or svn_revert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, and no mention of context where it should be avoided. The description is too brief to provide usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
svn_updateC
Guarded svn update with --accept postpone.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute working directory. If omitted, absolute paths identify their SVN working copy; relative paths require explicit cwd. | |
| paths | No | Optional paths relative to cwd or absolute paths inside one SVN working copy. | |
| updateAll | No |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description uses 'Guarded' but does not explain what protection it provides or behavioral traits like conflict resolution or permissions needed. Does not disclose if destructive or read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short with one sentence, but it is under-specified for a tool with 3 parameters and no annotations. Not front-loaded with useful info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 sibling tools and no output schema, the description lacks sufficient context for an agent to understand when to use it and what results to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not explain any parameters. Schema has 67% coverage; updateAll has no description. Description fails to add meaning, especially for updateAll.
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?
Description clearly states verb 'svn update' and resource (working copy), with specific flag '--accept postpone'. Differentiates from siblings like svn_add, svn_commit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like svn_cleanup or svn_resolved. Implies use for updates with conflict handling, but no explicit directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
23 tool updates
v1.0.0- First observed
eol_check - First observed
eol_fix_verified - First observed
svn_add - First observed
svn_cleanup - First observed
svn_commit - First observed
svn_copy - First observed
svn_diagnose - First observed
svn_diff - First observed
svn_export - First observed
svn_import - First observed
svn_info - First observed
svn_log - First observed
svn_move - First observed
svn_precommit - First observed
svn_propget - First observed
svn_propset - First observed
svn_propset_eol_style - First observed
svn_rename - First observed
svn_resolved - First observed
svn_revert - First observed
svn_self_check - First observed
svn_status - First observed
svn_update
TDQS
B3/5.0
Scored across 23 tools
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., svn_add vs svn_commit). However, svn_move and svn_rename are aliases for the same operation, causing redundancy. Additionally, eol_check and eol_fix_verified overlap in scope, but descriptions clarify their difference.
Naming Consistency3/5
The majority of tools follow a consistent svn_{verb} pattern. However, two EOL-related tools use an eol_ prefix instead of svn_eol_, and svn_self_check does not follow the verb pattern. This inconsistency may confuse an agent.
Tool Count5/5
23 tools is an appropriate number for a Subversion client agent. It covers a wide range of operations without being overwhelming or too sparse. Each tool seems necessary for distinct SVN tasks.
Completeness3/5
The tool set covers many core SVN operations, but notable gaps exist: svn_delete, svn_merge, svn_switch, and svn_blame are missing. For a comprehensive SVN workflow, these operations are important. The precommit check and EOL handling are nice additions, but the gaps reduce completeness.
Maintenance
ActivityActive
ResponsivenessResponsive
Related MCP Connectors
A MCP server built for developers enabling Git based project management with project and personal…
ZEN SecDB MCP server for CVE intelligence, CVSS/EPSS scoring, advisories, SSVC, and package audits.
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
Remote MCP for tool license checks, vendor policy review, alternatives, and license receipts.
Related MCP Servers
- AlicenseBqualityDmaintenanceMCP Server for Git operations, agent templates, and project utilities.969 npmMIT
- AlicenseAqualityBmaintenanceA local MCP server that provides a safe, explicit set of Git operations for version control tasks like status, diff, branching, staging, committing, fetching, merging, and pushing.1318 npmMIT
- FlicenseBqualityCmaintenanceEnables secure, policy-controlled operations on local git repositories through MCP, including bounded reads, context-checked patches, allowlisted tasks, and guarded git operations.10-