Loading ToolBench

Reading the current corpus…

mcpg-plugin-backend-sftp MCP server · D · ToolBench

mcpg-plugin-backend-sftp

github.com/mcpg-dev/mcpg-plugin-backend-sftp

SFTP (SSH file transfer) backend binding plugin for mcpg. Lists a directory, gets a file, or puts a file over SSH (russh + russh-sftp) as MCP tools/resources — with path-traversal defense and a size cap. FTP (suppaftp) and SMB (pavao) are deferred follow-ons.

2026-07-28+3 tools

52/100

Definition Quality61

Protocol Readiness40

Supportability45

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · evidence: stateless requests

Current-spec patterns detected

Summary

Three tools with clear naming (fs.list, fs.get, fs.put) and basic descriptions. All tools have input schemas with parameter descriptions. However, descriptions are minimal (10-50 chars), lacking context on WHEN to use each tool, prerequisites, or return value structure. No output schemas documented. Parameter descriptions exist but are terse. Missing error handling guidance and recovery paths. No tool annotations (readOnlyHint/destructiveHint). Schemas are present but sparse, no examples, no constraints on path format beyond traversal defense mention.

Tools (3)

fs.getread onlyauth50/100

Read a file's contents over SFTP (capped at max_bytes)

fs.listread onlyauthsource verified60/100

List a directory's entries over SFTP

fs.putwriteauthsource verified62/100

Write a file over SFTP (truncate/create)

Issues (5)

HIGHtool-description ↗

Descriptions are under 50 characters and lack actionable context. 'List a directory's entries over SFTP' does not explain when to call this vs other discovery tools, what structure is returned, or prerequisites (e.g., must have SFTP credentials configured). LLMs cannot infer selection criteria from minimal text.

fs.listfs.getfs.put

HIGHresponse-shaper ↗

No output schema documented. Callers cannot see what fields fs.list returns (entries structure?), what fs.get returns (text vs base64 encoding?), or what fs.put returns (bytes written?). LLMs must guess, risking misuse.

fs.listfs.getfs.put

MEDIUMtool-annotations ↗

No tool annotations (readOnlyHint, destructiveHint, idempotentHint). fs.put is destructive (truncates/overwrites) but LLMs have no signal that this is irreversible. fs.list and fs.get are read-only but lack explicit marking.

fs.listfs.getfs.put

Recommendations

Expand tool descriptions to 100-200 characters. For fs.list: 'List files and directories in a remote SFTP directory. Returns entry names, types, and sizes. Call this first to discover available files before reading with fs.get.' For fs.get: 'Read a file from SFTP. Returns content as UTF-8 text or base64 (for binary). Capped at max_bytes to prevent memory exhaustion.' For fs.put: 'Write or overwrite a file over SFTP. Provide content as UTF-8 text OR base64-encoded bytes (mutually exclusive). Returns bytes written.'
Document output schemas in code comments or a separate schema definition. E.g., fs.list returns {entries: [{name: string, type: 'file'|'dir', size: number}]}; fs.get returns {text?: string, base64?: string, size: number}; fs.put returns {written: number}.
Add tool annotations: mark fs.list and fs.get with readOnlyHint=true; mark fs.put with destructiveHint=true and idempotentHint=false (overwrites are not idempotent if content differs).
Clarify fs.put parameter relationship: 'Provide EITHER text (UTF-8 string) OR content (base64-encoded bytes), not both. If both are provided, content takes precedence.' Add enum or oneOf constraint in schema.
Add error handling guidance in descriptions. E.g., 'If path is not found, returns error with available alternatives. If SFTP connection fails, error is retryable, check SSH credentials and network connectivity.'

Score history

Overall score trend

First recorded score · v2 rubric

52/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	52	2026-07-28+	v2