Click on "Install 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., "@Silicon Transfer MCP Server Connect to SFTP example.com and upload app.js with hash proof."
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.
FTP / FTPS / SFTP for Claude and other MCP clients - with built-in transfer proofs.
Every upload and download returns a verdict: PROVEN only when the SHA-256 of the
remote file matches your local file. No more "transfer complete" on blind trust.
Philosophy: prove it, then claim it. Built from scratch by Silicon Networks - the makers of AEGIS Shield.
Typical FTP tools | Silicon Transfer | |
Upload result | "done" | verdict + SHA-256 of both sides |
Directory sync check | manual | per-file proof walk with mismatch list |
Remote file fingerprint | download first | streamed SHA-256, no disk contact |
Protocols | often FTP only | FTP, FTPS, SFTP (password or SSH key) |
Related MCP server: @bitatlas/mcp-server
Connection: silicon_connect, silicon_disconnect, silicon_status, silicon_server_info
Files: silicon_upload_file, silicon_download_file, silicon_delete_file, silicon_file_info
Directories: silicon_list_dir, silicon_make_dir, silicon_upload_dir, silicon_download_dir, silicon_rename
Transfers accept proof: "hash" | "size" | "none" - hash is the default for single
files, size for directory trees (switch to hash when it matters).
npm install -g silicon-transfer-mcp-serverThat's it - live on npm. Or run it without installing via npx (see config below).
git clone https://github.com/SiliconAINetworks/silicon-transfer-mcp-server.git
cd silicon-transfer-mcp-server
npm install
npm run buildAdd to your claude_desktop_config.json (no credentials in the config - you pass
them at runtime through silicon_connect, for your own server):
{
"mcpServers": {
"silicon-transfer": {
"command": "npx",
"args": ["-y", "silicon-transfer-mcp-server"]
}
}
}{
"mcpServers": {
"silicon-transfer": {
"command": "node",
"args": ["C:/path/to/silicon-transfer-mcp-server/dist/index.js"]
}
}
}Ask your AI assistant:
"Connect to my server via SFTP (host example.com, user deploy, key at ~/.ssh/id_ed25519) and upload dist/app.js to /var/www/app.js - with hash proof."
The assistant calls silicon_connect, then silicon_upload_file and answers with the
verdict:
{
"proof": {
"verdict": "PROVEN",
"detail": "SHA-256 identisch - Transfer bewiesen.",
"local_sha256": "9f2a...",
"remote_sha256": "9f2a..."
}
}If the hashes ever differ you get MISMATCH with both fingerprints - retry instead
of trusting a broken deploy.
Built with the OWASP Top 10 for Agentic Applications (2026) in mind - specifically ASI02 (Tool Misuse) and ASI04 (Agentic Supply Chain).
What this server does not do
No stored credentials. They are runtime-only tool parameters for your own server - no defaults, no config files with secrets, no server addresses shipped.
No dynamic tool definitions. Every tool is fixed in the source you can read; nothing is fetched from a remote registry at runtime, so no third party can rewrite what your assistant thinks a tool does.
No telemetry, no phone-home, no analytics.
Sharp edges - operate accordingly
silicon_delete_file, silicon_delete_directory and silicon_sync_deploy
(with deleteExtras) can destroy remote data. An assistant reading untrusted
content - a web page, a PDF, an email - can be steered by instructions hidden
inside it (indirect prompt injection). Treat these tools like rm -rf:
Connect with an account scoped to the directory you intend to touch, never root.
Prefer SSH keys over passwords; give the key its own restricted account.
Run silicon_list_dir before any delete, and read the plan before approving.
Keep deleteExtras off unless you are deliberately mirroring.
Verifying what you installed
Package name is exactly silicon-transfer-mcp-server, published by
aegisshield888. Similar names on npm are placeholders we registered to prevent
typosquatting - they contain no code. Source: the GitHub repository linked above.
Reporting
Found a hole? Open an issue on GitHub, or write to security@siliconnetworks.ch.
MIT (c) 2026 Silicon Networks. Built from scratch - single-author codebase.
Verbindet zu einem FTP-, FTPS- oder SFTP-Server. SFTP unterstuetzt Passwort oder SSH-Key (privateKeyPath).
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname oder IP | |
| port | No | Port (Standard: 21 fuer ftp/ftps, 22 fuer sftp) | |
| password | No | Passwort (bei SSH-Key optional) | |
| protocol | Yes | Uebertragungsprotokoll | |
| username | Yes | Benutzername | |
| passphrase | No | Passphrase des SSH-Keys, falls verschluesselt | |
| privateKeyPath | No | Pfad zu einem privaten SSH-Key (nur sftp) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutability (readOnlyHint=false), external interaction (openWorldHint=true), idempotency (idempotentHint=true), and non-destructiveness (destructiveHint=false). The description adds detail about SFTP authentication options, aligning with annotations and providing useful extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loading the key action and resource, with no unnecessary words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description could hint at what the tool returns or side effects (e.g., establishing a session). However, it covers protocols and auth, and the sibling tools suggest a connection lifecycle. It is mostly complete but lacks explicit output info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter information beyond the schema, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Verbindet' (connects) and the specific resource types (FTP-, FTPS- or SFTP-Server). It effectively distinguishes from sibling tools, which focus on file/directory operations or disconnection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies supported protocols (ftp, ftps, sftp) and auth methods for sftp, giving clear context for when to use the tool. While it does not explicitly mention alternatives or prerequisites, the sibling tools imply a workflow, and the protocol enum bounds usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Loescht eine Datei auf dem Server. Endgueltig - vorher mit silicon_list_dir pruefen.
| Name | Required | Description | Default |
|---|---|---|---|
| remotePath | Yes | Remote-Pfad der zu loeschenden Datei |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds critical behavioral context: deletion is permanent ('endgueltig'). This goes beyond annotations by emphasizing irreversibility, though it could mention error handling for missing files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—only two short sentences—with no filler. Every word serves a purpose: the main action, permanence warning, and usage tip. Front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with no output schema, the description covers the core action, permanence, and a safety recommendation. It is practically complete, though could mention expected behavior on nonexistent files for full clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes 'remotePath' as the path to delete. The description does not add new parameter-level details (e.g., format constraints or examples), so it meets the baseline without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (file) with the explicit verb 'loescht' and object 'Datei'. It also distinguishes from sibling tools like 'silicon_rename' and 'silicon_make_dir' by focusing on file deletion, providing clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using 'silicon_list_dir' before deletion ('vorher mit silicon_list_dir pruefen'), indicating a precondition. It implies not to use it without verification, offering clear guidance, though it does not explicitly list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trennt die aktive Verbindung sauber.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds the word 'sauber' indicating clean shutdown, which is additional context. However, no details about side effects or required permissions are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded. Every word is meaningful. Could be expanded slightly with context, but it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and annotations covering safety (idempotent, not destructive), the description is nearly complete. It could mention what happens if no connection is active, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. Per guidelines, baseline is 4. The description adds no param information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (disconnect) and the target (active connection). The term 'sauber' adds nuance of a proper shutdown. It distinguishes well from sibling tools like silicon_connect and silicon_status by specifying the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool. It does not mention prerequisites (e.g., must have an active connection) or alternatives. The implied use case is after a connection, but this is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Laedt ein Remote-Verzeichnis rekursiv herunter. Danach wird jede lokale Datei gegen die Remote-Quelle verglichen (hash/size/none, Standard size).
| Name | Required | Description | Default |
|---|---|---|---|
| proof | No | Beweisstufe pro Datei (Standard: size) | size |
| localDir | Yes | Lokales Zielverzeichnis | |
| remoteDir | Yes | Remote-Quellverzeichnis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations claim readOnlyHint=true, but the tool downloads files, modifying the local filesystem, which is a write operation. This contradiction undermines trust. The description itself partially discloses behavior (downloads and verifies) but omits overwrite behavior and permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no wasted text. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the basic operation and verification, but lacks details on overwrite behavior, error handling, and prerequisites. Given no output schema, more context on side effects would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and provides descriptions. The description adds value by explaining the verification step and mapping proof parameter to hash/size/none, enhancing understanding beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a remote directory recursively. The verb 'herunterladen' and resource 'Remote-Verzeichnis' are specific. It distinguishes from sibling tools like silicon_download_file (single file) and silicon_upload_dir.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. No explicit when-not-to-use or differentiation from similar tools like silicon_download_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Laedt eine Remote-Datei herunter und liefert das Transfer-Urteil mit: PROVEN nur bei identischem SHA-256 zwischen Remote-Quelle und lokaler Kopie.
| Name | Required | Description | Default |
|---|---|---|---|
| proof | No | Beweisstufe: hash = SHA-256-Rueckvergleich (Standard), size = nur Groesse, none = ohne Urteil | hash |
| localPath | Yes | Lokaler Zielpfad inkl. Dateiname | |
| remotePath | Yes | Remote-Quellpfad |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds the SHA-256 verification behavior, which is useful but does not disclose potential side effects like overwriting existing local files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the main action and key feature without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core outcome (transfer verdict), but does not cover error handling, overwrite behavior, or network failure scenarios. It is fairly complete for a simple download tool with annotations filling some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-described. The description only marginally adds context about the hash verification default, not significantly beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a remote file and provides a transfer verdict based on SHA-256 match. It distinguishes from the sibling tool 'silicon_download_dir' which handles directories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for single file download with integrity verification, but does not explicitly mention when not to use or name alternatives like 'silicon_download_dir'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Groesse und SHA-256 einer Remote-Datei - der Fingerabdruck ohne Download auf Platte.
| Name | Required | Description | Default |
|---|---|---|---|
| remotePath | Yes | Remote-Pfad der Datei |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds that it provides size and SHA-256 without downloading. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key actions and information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description explains what is returned (size and SHA-256). Could mention units or format, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter 'remotePath' described. The description does not add significant meaning beyond what the schema provides (e.g., format or constraints).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get info' (implied by 'Groesse und SHA-256') and the resource 'remote file'. It distinguishes from sibling tools like upload/download by focusing on fingerprint without download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking file fingerprint without downloading, but does not explicitly state when to use this tool versus alternatives like listing directory. Lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listet ein Remote-Verzeichnis mit Typ, Groesse und Aenderungsdatum.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Remote-Pfad, z.B. /home/user/www |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's contribution is limited to listing returned fields. It adds no extra behavioral context like authentication or rate limits, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no unnecessary words. It front-loads the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description compensates by listing the returned information (type, size, date). This is sufficient for a simple tool with one parameter, though minor details like ordering or recursion are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the path parameter. The tool description adds no further parameter information beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists a remote directory and specifies the information provided (type, size, modification date). This distinguishes it from siblings like silicon_file_info (single file) and silicon_upload_dir (file transfer).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing directory contents but does not explicitly state when to use this tool versus alternatives. No exclusions or when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legt ein Verzeichnis auf dem Server an (rekursiv moeglich).
| Name | Required | Description | Default |
|---|---|---|---|
| recursive | No | Elternverzeichnisse mit anlegen | |
| remotePath | Yes | Anzulegender Remote-Pfad |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is known. The description adds only the recursive capability, which is partially covered by the schema parameter. No additional behavioral traits beyond annotations are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. However, it could be slightly more structured (e.g., separating the recursive note), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple directory creation tool with a clear schema and annotations, the description covers the essential action and the recursive option. No output schema exists, but return values are implicit. Adequate for the tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions (remotePath and recursive). The description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create a directory') and the resource ('on the server'), and mentions recursive creation, which distinguishes it from sibling tools like upload_dir or file_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., upload_dir). No explicit when-not or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Benennt eine Remote-Datei oder ein Verzeichnis um bzw. verschiebt es.
| Name | Required | Description | Default |
|---|---|---|---|
| toPath | Yes | Neuer Remote-Pfad | |
| fromPath | Yes | Aktueller Remote-Pfad |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only and not explicitly destructive. The description simply restates that it renames/moves, without adding behavioral details such as whether it overwrites, what happens if the source doesn't exist, or if it can move across file systems. The description adds limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core functionality without any unnecessary words. It is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of param descriptions, the description covers the basic action. However, it omits important edge case details (e.g., overwrite behavior, cross-directory moves) that a complete description should include. No output schema exists, so the description bears more responsibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear param descriptions ('Current remote path', 'New remote path'). The tool description adds context that the paths are remote, but does not provide additional meaning or constraints beyond what the schema already offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renames or moves a remote file or directory. The title 'Umbenennen / Verschieben' reinforces this, and there are no sibling tools that perform a similar function, making it highly distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions like source existence or overwrite behavior. The context of sibling tools implies it is the only rename/move option, but explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Name, Version und Philosophie dieses MCP-Servers. Lebenszeichen-Check.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds context about return fields (name, version, philosophy) and health check purpose, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences efficiently convey the tool's content and purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple info tool with no parameters, no output schema, and safe annotations, the description fully covers what a user needs: what it returns and its role as a health check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% (empty). With zero params, baseline is 4; description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns server name, version, and philosophy, and serves as a health check ('Lebenszeichen-Check'), clearly distinguishing it from file operation and connection sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only implied by 'Lebenszeichen-Check' as a health check, but no explicit guidance on when to use vs. alternatives like silicon_status. Lacks when-to-use 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.
Zeigt, ob und wohin aktuell eine Verbindung besteht.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context by specifying that it shows current connection status (both existence and destination), which is not fully captured by annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys all necessary information without any waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and simple functionality, the description is nearly complete. However, it does not describe the output format, which could be inferred but is not explicit. For a status check, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to explain parameter semantics. The baseline for 0 parameters is 4, and the description provides sufficient context for a parameter-less tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Zeigt, ob und wohin aktuell eine Verbindung besteht' clearly states the tool's purpose: showing whether and where a connection exists. It uses a specific verb ('shows') and resource ('connection'), and distinguishes from sibling tools like 'silicon_connect' and 'silicon_disconnect'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests usage for checking connection status, but lacks explicit guidance on when to use it versus alternatives, such as when a connection is expected or not. There is no mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Laedt ein lokales Verzeichnis rekursiv hoch. Danach wird jede Datei einzeln verglichen: proof=hash prueft SHA-256 pro Datei (gruendlich, langsamer), proof=size vergleicht Groessen (schnell), none ueberspringt.
| Name | Required | Description | Default |
|---|---|---|---|
| proof | No | Beweisstufe pro Datei (Standard: size) | size |
| localDir | Yes | Lokales Quellverzeichnis | |
| remoteDir | Yes | Remote-Zielverzeichnis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly discloses that after upload, files are compared using SHA-256, size, or skipped. Annotations indicate idempotentHint=true, consistent with verification. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the action, second explains the proof parameter. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not mention what is returned (e.g., success/failure, comparison results). For a complex operation, this information is missing, reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). Description adds meaningful detail for the proof parameter, explaining each enum value (hash=sha256, size, none). localDir and remoteDir are straightforward.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it uploads a local directory recursively and verifies files based on the proof parameter. Differentiates from siblings like upload_file (single file) and download_dir (download direction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes the core function well, implying use for directory uploads with verification. Does not explicitly contrast with alternative tools (e.g., upload_file for single files), but the context of sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Laedt eine lokale Datei hoch und liefert das Transfer-Urteil mit: PROVEN nur, wenn der SHA-256 der Remote-Datei nach dem Upload dem lokalen entspricht.
| Name | Required | Description | Default |
|---|---|---|---|
| proof | No | Beweisstufe: hash = SHA-256-Rueckvergleich (Standard), size = nur Groesse, none = ohne Urteil | hash |
| localPath | Yes | Lokaler Quellpfad | |
| remotePath | Yes | Remote-Zielpfad inkl. Dateiname |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true, destructiveHint=false. The description adds significant context: the transfer verdict mechanism and the condition for PROVEN status. It does not contradict annotations and clarifies behavioral expectations beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 primary action. It could be slightly more structured but is efficient and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no output schema, the description covers the core functionality but lacks details on return values, error conditions, and behavior for non-hash proof levels. It is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions SHA-256 proof, which relates to the proof parameter but does not add explicit meaning beyond the enum values. No additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (upload), the resource (local file), and a unique behavioral trait (verdict based on SHA-256 match). It distinguishes from sibling tools like silicon_upload_dir and silicon_download_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives or provide usage scenarios. It implies file upload with integrity check but offers no comparison with other uploading tools or guidance on when to choose different proof levels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: connection management, file/directory operations, uploads/downloads, and server info. No overlapping functions.
All tools follow the 'silver_verb_noun' pattern with snake_case, providing a clear and predictable naming convention.
13 tools is within the ideal range, covering core file transfer operations without being excessive or insufficient.
Covers essential operations for file transfer (connect, disconnect, list, upload, download), but lacks a dedicated directory deletion tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Protect and verify digital content with cryptographic signing and proof of ownership.
Stamp content with permanent, verifiable provenance. Hash locally, verify free forever.
Privacy-preserving file proofs on Solana. Files are hashed locally. Currently free, no API key.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SiliconAINetworks/silicon-transfer-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server