windy-word-mcp

lookup_translation_memory

Retrieve a cached translation from the local translation memory by querying with source text, source language, and target language codes.

Instructions

Look up a (text, sourceLang, targetLang) tuple in the local translation-memory cache. Returns {ok, match: {translation, hits} | null}. No external API call — pure local SQLite query.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>",
      "sourceLang": "<sourceLang>",
      "targetLang": "<targetLang>"
    },
    "name": "lookup_translation_memory"
  }
}

Input Schema

Name	Required	Description
`text`	Yes	Source text to look up.
`sourceLang`	Yes	Source language code.
`targetLang`	Yes	Target language code.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.11.0Jul 29, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Describes return format, local nature, and no side effects. Could mention exact match requirement, but overall discloses key behaviors.

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?

Two sentences, no fluff, front-loaded with purpose. Every sentence 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?

Simple lookup tool with 3 required params, no output schema but return format described. Description covers inputs, nature of operation, and side effects. Slightly improved with sibling context, but still adequate.

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% with descriptions for each parameter. Description adds minimal value beyond restating the tuple; does not compensate further. Baseline 3 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?

Specific verb 'look up' with clear resource 'local translation-memory cache' and tuple of inputs. Distinguishes from siblings like 'translate_text' by noting it's a local query without external API call.

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?

States it's a pure local SQLite query with no external API call, implying it's for fast cache lookups. Could explicitly mention to use before calling translate_text, but context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server