Allows using Apple Intelligence as an AI provider to analyze file content and generate descriptive filenames via the Distill app.
Allows using Google Gemini as an AI provider to analyze file content and generate descriptive filenames via the Distill app.
Allows using Ollama as a local AI provider to analyze file content and generate descriptive filenames without data leaving the machine.
Allows using OpenAI (e.g., GPT-4o) as an AI provider to analyze file content and generate descriptive filenames via the Distill app.
Let Claude, Cursor, or any MCP client rename files for you — automatically, based on content.
This is the official Model Context Protocol bridge for Distill — a native macOS app that uses AI (Distill Cloud, or your own Claude, OpenAI or Gemini access, or a local Ollama model) to read your files and rename them with descriptive, consistent names. No more IMG_4521.jpg or Scan_003.pdf — get 250401 Invoice Telekom.pdf instead.
You need the Distill app installed and running. This MCP server is a stdio→HTTP bridge — the actual file analysis happens in the app. Get Distill at store.juergenkoller.software/apps/distill.
The Distill version from the website already contains this bridge as
distill-mcp-server, together with its offline manual. Build from this repository only if you want to audit or modify the bridge. The Mac App Store version has neither the REST API nor the MCP server.
"Claude, look at the 47 PDFs in ~/Downloads, rename them based on content, but show me the suggestions first."
The MCP server exposes 13 tools:
Tool | What it does |
| Analyze file content with AI and rename with descriptive names |
| Suggest new names without renaming (preview mode) |
| Undo a previous rename |
| Show the rename history (timestamps, before/after, AI provider used) |
| Add a folder to auto-monitoring (new files get renamed in the background) |
| Process the files already lying in a watched folder |
| Progress of automatic processing: detected, done, open, renamed, failed |
| Current state, AI provider, credits left, watched folders |
| Switch AI provider — Distill Cloud (default, uses credits), or in the website version your own Claude, OpenAI or Gemini access, or Ollama (local) |
| Show naming rules (date format, casing, categories, custom templates) |
| Update naming rules |
| Search the Distill user manual (works offline, even without the app running) |
| Read one chapter of the manual as Markdown |
Distill reads PDFs, images (via OCR), Office documents, emails, HTML, RTF, and media files. It extracts date, category, description, sender, and amounts — then builds filenames using your configurable rules.
Related MCP server: Readedit
macOS 15 (Sequoia) or later — Distill's own requirement
Distill app installed and running — get it here (website version; free, 100 starter credits, then pay-per-use from €1.99 per 100 name suggestions)
Terms of Use and Privacy Policy accepted once in the Distill window — until then the API answers only status requests
Swift 5.9+ (Xcode 15+) only if building from source
/Applications/Distill.app/Contents/MacOS/distill-mcp-serverIt always matches the installed app version and finds the offline manual on its own.
git clone https://github.com/juergenkoller-software/distill-mcp.git
cd distill-mcp
swift build -c release
# Binary: .build/release/DistillMCPNot needed on a Mac: the website version of Distill ships the bridge (see above). The binary attached to Releases is a static Linux x86_64 build for container-based MCP registries such as Glama; it does not run on macOS.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"distill": {
"command": "/Applications/Distill.app/Contents/MacOS/distill-mcp-server",
"env": {
"DISTILL_API_PORT": "43821",
"DISTILL_API_TOKEN": "only-if-set-in-distill"
}
}
}
}DISTILL_API_TOKEN is needed only if you set a token in Distill → Settings → API. Without a token, Distill accepts connections from your own Mac only.
claude mcp add distill /Applications/Distill.app/Contents/MacOS/distill-mcp-server \
--env DISTILL_API_PORT=43821Same pattern — DistillMCP is a stdio MCP server, configured via the two env vars above.
┌────────────────┐ JSON-RPC stdio ┌────────────────┐ HTTP+Bearer ┌────────────────┐
│ Claude/Cursor │ ───────────────► │ DistillMCP │ ─────────────► │ Distill.app │
│ (MCP client) │ ◄─────────────── │ (this repo) │ ◄───────────── │ (port 43821) │
└────────────────┘ └────────────────┘ └────────────────┘The bridge reads JSON-RPC 2.0 requests from stdin, translates each tool call into a request to Distill's local REST API (http://localhost:43821/v1/…), and writes responses back to stdout. All AI calls (Distill Cloud, Claude, OpenAI, Gemini, Ollama), file reading (OCR, PDF extraction, Office parsing), credit tracking, and naming logic happen inside the Distill app.
This split lets the wire format stay open-source (audit it, sandbox it, run it through any MCP runtime) while the heavy lifting stays in the app.
Variable | Default | Description |
|
| Port of Distill's local HTTP server (Distill → Settings → API) |
| (none) | Bearer token — only if set in Distill → Settings → API |
| (next to the binary) | Path to |
Errors and trace logs go to stderr so they don't pollute the JSON-RPC stdout channel.
Every refusal comes back as an MCP error (isError: true) with a sentence the agent can act on:
Situation | What the bridge reports |
Distill not running, API off, or Mac App Store version | Distill is not reachable at |
Token wrong or missing (HTTP 401) | Set |
Legal texts not accepted (HTTP 403 | The user opens the Distill window and accepts in the “Legal Notice” sheet; an agent cannot do this |
Any other HTTP error | Status code and Distill's error text, e.g. |
Before version 0.2.0 the bridge ignored the HTTP status, so these refusals looked like successful calls.
Distill is an AI file manager for macOS that automatically renames files based on content analysis. Highlights:
No subscription — free app, pay-per-use credits (100 free / 100 for €1.99 / 400 for €4.99 / 1,000 for €8.99)
Distill Cloud by default — credits, no sign-up; in the website version also your own Claude, OpenAI or Google Gemini access (no credits used) or Ollama (local, no API key)
Reads everything — PDFs, images (OCR), Office docs, emails, HTML, RTF, media files
Local-only mode with Ollama — nothing leaves your Mac
Configurable NameBuilder — date formats, casing, categories, custom templates
Folder monitoring — drop files in, get them renamed automatically
REST API + Swagger UI — for non-MCP automation
MCP server (this repo) — for Claude/AI agents, in the website version
24 languages
Available on the Mac App Store and as a direct download — the REST API and MCP server ship with the direct download
→ Get Distill at store.juergenkoller.software
MIT — see LICENSE. Bridge is open source; the Distill app is commercial (free-to-try with pay-per-use credits).
Bridge bugs: open an issue
App support: support@juergenkoller.software
Built by Juergen Koller Software GmbH.
Gibt den aktuellen App-Status und Einstellungen zurück
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It discloses basic function but omits side effects, authentication needs, or whether it is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence in German, front-loaded and efficient. 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?
While simple, the description does not detail the exact contents of 'status and settings'. However, given zero parameters and no output schema, it is largely complete for a status tool.
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%. Description adds no parameter details, but none are needed 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 returns current app status and settings. It distinguishes from siblings which focus on specific features like rename history, rules, or provider settings.
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 explicit usage guidance provided, but as a parameterless status check, its use case is implied. Lacks differentiation from siblings or cautionary notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Zeigt die Umbenennungs-Historie
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximale Anzahl Einträge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only mentions displaying history. It fails to disclose behavioral traits like read-only nature, authorization needs, or side effects.
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 with no wasted words. However, it is in German, which may reduce clarity for non-German-speaking AI agents.
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 lack of output schema, the description should explain the return format or content. It only states 'shows history' without details, leaving the agent uninformed.
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% for the single parameter 'limit', with a description in the schema. The tool description adds no additional meaning beyond that.
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 shows rename history, using a specific verb and resource. However, it does not differentiate from sibling tools, though none seem directly similar.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Zeigt die aktuellen Umbenennungsregeln (Format, Datum, Casing, Kategorien)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'shows' implies read-only, but it does not explicitly state that the tool is safe or has no side effects. For a getter, this is adequate but not thorough.
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, front-loaded with the primary action, and contains no fluff. Every word is relevant.
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 output schema, the description lists categories of rules (format, date, casing, categories), which gives a general idea of the response content. It could be more specific about the return structure, but for a simple getter, it is reasonably 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?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter information. The baseline for no parameters is 4, and the description does not detract from this.
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 it shows current renaming rules and lists specific aspects (format, date, casing, categories). This is a specific verb+resource, and it effectively distinguishes from sibling tools like set_rules and get_rename_history.
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, but the purpose is clear: use to view rules before setting or to check configuration. No exclusion or negative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Benennt Dateien um: Analysiert den Inhalt mit KI und benennt die Dateien mit beschreibenden Namen um
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | Absolute Dateipfade | |
| template | No | Optionales Namenstemplate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions AI analysis and renaming but does not disclose potential destructiveness, permission requirements, or whether changes are reversible. The existence of revert_rename suggests history is kept, but this is not mentioned.
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, concise and front-loaded with the main action. However, it could benefit from structuring with more detail without sacrificing conciseness.
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 is present, so the description should explain return values or side effects. It does not mention what happens after renaming, nor does it leverage sibling tool context (e.g., history tracking). More completeness is needed for a mutation tool.
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 baseline is 3. The description adds minimal value beyond the schema, only implying that renaming is content-based. No additional semantic details are provided for either parameter.
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 files by analyzing content with AI to generate descriptive names. It uses a specific verb ('renames') and resource ('files'), and the method (AI analysis) is distinctive from sibling tools like suggest_names.
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 is provided on when to use this tool versus alternatives, nor any prerequisites, exclusions, or conditions. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Macht eine Umbenennung rückgängig
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Pfad der umbenannten Datei |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'Undoes a rename' but does not disclose the mechanism (e.g., reverts to previous name using history), whether it is destructive, or what happens if the rename cannot be undone.
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 superfluous words. However, it sacrifices completeness for brevity, so it does not fully earn a 5.
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 single-parameter tool, the description is minimal. It lacks details on input format, how the revert is resolved, and any limitations. With no output schema, more context would help.
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% (one parameter with description). The tool description adds no extra meaning beyond the schema's 'path of the renamed file'. Baseline is 3, and no additional value 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 'Macht eine Umbenennung rückgängig' (Undoes a rename) clearly states the action and resource. It distinguishes from sibling tools like rename_files (which performs renames) and get_rename_history (which shows history).
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, such as when to revert vs. manually renaming via rename_files. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wechselt den KI-Provider (Claude, OpenAI, Gemini, Ollama, Apple)
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optionales Modell (z.B. llama3.1, gpt-4o) | |
| apiKey | No | API Key für den Provider | |
| endpoint | No | Optionaler Endpoint | |
| provider | Yes | Provider-Name: Claude, OpenAI, Gemini, Ollama oder Apple |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states that the tool switches the provider but does not mention side effects, persistence, permissions, or impact on other operations.
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 communicates the core action. 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?
For a simple configuration tool, the description is somewhat adequate, but it does not mention the optional parameters (model, apiKey, endpoint) that can be set during the switch. With no output schema, more context on what happens after switching would help.
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 each parameter is already explained well. The description adds minimal value beyond listing the provider names, which are already in the schema. 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's purpose: switching the AI provider. It lists the specific providers (Claude, OpenAI, Gemini, Ollama, Apple) which distinguishes it from sibling tools that deal with file renaming, rules, or app status.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ändert die Umbenennungsregeln
| Name | Required | Description | Default |
|---|---|---|---|
| casing | No | kleinbuchstaben, Title Case, GROSSBUCHSTABEN, Wie von KI | |
| format | No | Namensformat z.B. {datum}{sep}{kategorie}{sep}{beschreibung} | |
| prefix | No | Prefix vor dem Namen | |
| suffix | No | Suffix nach dem Namen | |
| separator | No | - oder _ oder . | |
| categories | No | Liste der Kategorien | |
| dateFormat | No | YYYY-MM-DD, DD.MM.YYYY, MM-DD-YYYY, YYYYMMDD, Kein Datum |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description carries the full burden. It merely states 'changes the renaming rules' without disclosing persistence, side effects, authorization needs, or any other behavioral traits.
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, efficient sentence with no wasted words. However, it could be slightly more structured to highlight key aspects.
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 complexity of 7 parameters and no output schema or behavioral guidance, the description is severely lacking. It provides no context on what happens after successful invocation, validation, or potential errors.
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 each parameter is already explained in the input schema. The description adds no extra semantic information, but the schema provides sufficient meaning for an agent.
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 'Ändert' (changes) and the resource 'Umbenennungsregeln' (renaming rules), making the purpose unambiguous. It distinguishes from siblings like get_rules (read-only) and rename_files (apply rules).
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 explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or when not to use it, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schlägt neue Dateinamen vor ohne umzubenennen
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | Absolute Dateipfade | |
| template | No | Optionales Namenstemplate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It only states it suggests names without renaming, but gives no information about output format, whether it modifies anything, or any side effects. The agent cannot infer return structure.
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, very concise and to the point. However, it is in German which may reduce clarity for English-speaking agents.
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 output schema and no annotations, the description is insufficient. It does not explain what the tool returns (e.g., list of suggestions), how many, or any constraints. The tool likely needs more context for an agent to use it correctly.
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 descriptions for both parameters. The tool description adds no additional parameter information beyond what is already in the schema, 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 suggests new file names and explicitly says it does not rename, distinguishing it from rename_files. However, it does not explicitly specify the resource (files) and the scope is slightly vague.
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 phrase 'without renaming' implies it is for getting suggestions before a rename, but there is no explicit guidance on when to use this tool versus alternatives like rename_files or get_rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fügt einen Ordner zur Überwachung hinzu
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absoluter Ordnerpfad | |
| autoRename | No | Automatisch umbenennen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects, required permissions, whether the monitoring is persistent, or how to stop it. This is a significant gap for a tool that likely has ongoing effects.
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 lacks structure and is too brief to be useful. It under-specifies the tool rather than being efficiently concise.
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 lack of annotations, output schema, and the tool's likely operational complexity (adding a folder for monitoring), the description is insufficient. It does not explain return values, how to verify success, or how the monitoring works.
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 clear descriptions for both parameters. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.
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 uses a clear verb+resource structure ('Adds a folder to monitoring'), making the tool's purpose understandable. It distinguishes itself from siblings like rename_files or set_rules, which perform different actions.
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 guidance on when to use this tool versus alternatives, or any prerequisites or conditions for usage. The agent receives no context about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0app_statusget_rename_historyget_rulesrename_filesrevert_renameset_providerset_rulessuggest_nameswatch_folderScored across 9 tools
Each tool has a distinct purpose: status, history, rules (get/set), rename, revert, provider switch, suggestions, and folder watching. No overlapping functions.
All tool names use consistent snake_case with clear verbs (get_, set_, rename_, revert_, suggest_, watch_) and follow a predictable pattern.
9 tools cover the core functionality of an AI-powered file renaming application without being excessive or insufficient.
The tool set includes all essential operations: renaming, reverting, rule management, provider switching, suggestions, history, and folder watching. No obvious gaps.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
An agent-first office suite Claude & ChatGPT read and write over one MCP URL.
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
