The TypeWhisper MCP server enables coding agents to programmatically control a TypeWhisper application for speech transcription and dictionary management.
Check Status (typewhisper_status): Verify if the TypeWhisper API is reachable and has a model ready.
List Models (typewhisper_list_models): Retrieve available transcription engines and models.
Transcribe Files (typewhisper_transcribe_file): Submit a local audio or video file for transcription or translation, with options to specify task, model, engine, source language or language hints, target language, and whether to apply dictionary corrections.
Search History (typewhisper_search_history): Query recent transcription history with text search and pagination (limit/offset).
Manage Dictionary Terms: List (typewhisper_list_dictionary_terms), upsert (typewhisper_upsert_dictionary_terms), or delete (typewhisper_delete_dictionary_term) recognition terms, with optional CTC minimum similarity scores.
Manage Dictionary Corrections: List (typewhisper_list_dictionary_corrections), upsert (typewhisper_upsert_dictionary_correction), or delete (typewhisper_delete_dictionary_correction) post-transcription correction rules (original → replacement), with optional case sensitivity.
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., "@TypeWhisper MCP transcribe the file /Users/me/report.wav"
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.
@typewhisper/mcp exposes the local TypeWhisper API as a Model Context Protocol server for coding agents and other MCP clients.
It connects to a TypeWhisper app running locally or on a remote host and lets agents transcribe files, inspect model status, search transcription history, and manage Dictionary terms and corrections.
Node.js 20 or newer on the machine running this MCP server
TypeWhisper on a reachable macOS or Windows host
TypeWhisper local API server enabled under Settings > Advanced
Related MCP server: @hyperwhisper/mcp
npm install -g @typewhisper/mcpFor local development from this repo:
npm install
npm run build
node dist/bin.js --helpMost MCP clients can run the server over stdio:
{
"mcpServers": {
"typewhisper": {
"command": "npx",
"args": ["-y", "@typewhisper/mcp"]
}
}
}For a local checkout:
{
"mcpServers": {
"typewhisper": {
"command": "node",
"args": ["/Users/marco/Projects/typewhisper-mcp/dist/bin.js"]
}
}
}By default, the server mirrors the TypeWhisper CLI discovery behavior:
TYPEWHISPER_API_BASE_URL, TYPEWHISPER_API_PORT, and TYPEWHISPER_API_TOKEN
TypeWhisper discovery files:
macOS: ~/Library/Application Support/TypeWhisper/api-discovery.json
Windows: %LOCALAPPDATA%\\TypeWhisper-UserData\\api-discovery.json
Windows legacy fallback: %LOCALAPPDATA%\\TypeWhisper\\api-discovery.json
The matching legacy api-port file
http://127.0.0.1:8978
Use --dev or TYPEWHISPER_DEV=1 to read development discovery files (TypeWhisper-Dev on macOS and TypeWhisper-DevUserData with a TypeWhisper-Dev fallback on Windows).
typewhisper-mcp --dev
typewhisper-mcp --base-url http://127.0.0.1:8978 --api-token "$TYPEWHISPER_API_TOKEN"The MCP server itself can run on any Node.js platform. TypeWhisper currently binds its API to the host's loopback interface, so connect remote clients through a private tunnel instead of exposing the API publicly.
For example, forward a local port from the agent machine to the TypeWhisper host:
ssh -N -L 18978:127.0.0.1:8978 user@typewhisper-hostThen start the MCP server with the forwarded URL and the bearer token from the TypeWhisper host's api-discovery.json:
TYPEWHISPER_API_BASE_URL=http://127.0.0.1:18978 \
TYPEWHISPER_API_TOKEN="your-token" \
typewhisper-mcpFor typewhisper_transcribe_file, the absolute path is resolved by the TypeWhisper host. Remote clients must therefore provide a path that exists on that host, for example through a shared or synchronized directory.
typewhisper_status
typewhisper_list_models
typewhisper_transcribe_file
typewhisper_search_history
typewhisper_list_dictionary_terms
typewhisper_upsert_dictionary_terms
typewhisper_delete_dictionary_term
typewhisper_list_dictionary_corrections
typewhisper_upsert_dictionary_correction
typewhisper_delete_dictionary_correction
typewhisper_transcribe_file requires an absolute path on the TypeWhisper host because TypeWhisper runs as a separate app process.
Recorder and live dictation controls are intentionally not part of the first release.
npm run typecheck
npm test
npm run build
npm pack --dry-runGPL-3.0-only
Delete one post-transcription correction from the TypeWhisper dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
| original | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate 'destructiveHint: true', so the description's mention of 'delete' is consistent. However, it adds no further behavioral details beyond what annotations provide, such as irreversibility 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 sentence, which is concise but lacks necessary details. It could be expanded slightly to cover the parameter without becoming verbose.
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 has one parameter and no output schema, the description should fully explain the input and behavior. It fails to do so, leaving the agent uncertain about what 'original' means.
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?
The sole parameter 'original' is not described at all in the description. With 0% schema coverage, the description fails to clarify what value should be provided (e.g., the original text or an ID). This is a significant omission.
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 deletes a post-transcription correction from the TypeWhisper dictionary. It distinguishes itself from the sibling 'typewhisper_delete_dictionary_term' by specifying 'correction' as the resource.
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?
There is no guidance on when to use this tool versus alternatives like 'typewhisper_upsert_dictionary_correction' or 'typewhisper_delete_dictionary_term'. No context on prerequisites or scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one recognition term from the TypeWhisper dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. Description adds minimal value (only 'delete'). Does not disclose behavior for missing terms (error vs no-op) or whether the operation is actually idempotent. No contradiction with 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?
Single sentence of 10 words, no filler. Could include more context without harming conciseness, but it is 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?
No output schema, single parameter. Description lacks details on return behavior, success/failure indicators, or prerequisites. For a deletion tool with destructiveHint=true, more safety context would be beneficial.
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 0%, so description must explain the 'term' parameter. It says 'recognition term' but adds no details on format, case sensitivity, or examples. The schema only specifies minLength:1.
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?
Description clearly states verb (delete), resource (recognition term), and location (TypeWhisper dictionary). It distinguishes from siblings like typewhisper_delete_dictionary_correction and typewhisper_upsert_dictionary_terms, which target different resources.
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 vs alternatives. Does not specify prerequisites, when not to use, or behavior on missing terms. Relies solely on the tool name to imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List post-transcription corrections configured in the TypeWhisper dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, making this a safe read-only tool. The description adds 'post-transcription corrections', clarifying the specific domain. It does not disclose any additional behavioral traits such as pagination, rate limits, or data freshness.
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 with no extraneous words. It front-loads the key information efficiently.
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, only one sentence needed, rich annotations, and no output schema, the description covers the essentials. It could be improved by hinting at the list content structure or typical use case, but lacks no critical information.
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?
The tool has no parameters, so the description does not need to add parameter details. The schema coverage is 100% with zero params, and the description is sufficiently clear without needing further elaboration.
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 post-transcription corrections configured in the TypeWhisper dictionary. It uses a specific verb 'list' and resource 'corrections', distinguishing it from listing terms. However, it does not explicitly differentiate from the sibling 'typewhisper_list_dictionary_terms', relying on the difference in resource type.
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 like 'typewhisper_delete_dictionary_correction' or 'typewhisper_upsert_dictionary_correction'. It does not mention any prerequisites or contextual cues for invoking the list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recognition terms configured in the TypeWhisper dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. However, it adds no further behavioral context (e.g., whether listing is instantaneous or paginated). No contradiction with 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?
Single sentence, no waste, front-loaded with the core action. Highly 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 no output schema, the description does not specify what information each term includes (e.g., name, metadata). For a simple list tool with good annotations, this is adequate but could be more 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?
No parameters exist, and schema coverage is 100% vacuously. The description adds no param info, but baseline for 0-param tools is 4, so this 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 recognition terms from the TypeWhisper dictionary, using a specific verb and resource. It implicitly differentiates from sibling 'list_dictionary_corrections' by focusing on 'terms', though not explicitly.
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 like searching history or listing corrections. The description provides no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available TypeWhisper transcription engines and models.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, ensuring the agent knows it is a safe read operation. The description adds minimal behavioral context beyond listing 'engines and models'; it does not specify return format or any 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?
Single sentence with 9 words, front-loaded with the action verb. Every word earns its place; no redundancy.
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 parameterless list tool with no output schema, the description is mostly complete. It could optionally mention what fields are returned per model, but the current level is adequate for an agent to infer the tool's use.
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?
The tool has zero parameters, so baseline is 4. The schema coverage is 100% (empty schema), and no further parameter information 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 verb 'List' and the resource 'TypeWhisper transcription engines and models', which is specific and distinct from sibling list tools like typewhisper_list_dictionary_corrections.
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, but the purpose is clear from the name and description. Implied usage: use when you need to see available models before transcription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search recent TypeWhisper transcription history.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of entries. Defaults to 10. | |
| query | No | Search query for transcription history. | |
| offset | No | Pagination offset. Defaults to 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds no further behavioral context (e.g., pagination, sorting, scope of 'recent'), so it fails to compensate for the lack of annotation detail beyond safety.
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 without fluff, but its brevity sacrifices useful context. It is concise but could be restructured to front-load key details.
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?
Despite low complexity, the description lacks essential details like return format, default sorting, and explicit scope of 'recent'. Given no output schema, the description should elaborate on what the agent can expect.
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 100% of parameters with descriptions. The tool description adds no additional meaning beyond what the schema provides, meeting the baseline for high schema coverage.
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 searches transcription history, distinguishing it from sibling tools like dictionary operations or transcription. However, the term 'recent' is ambiguous and could be clarified.
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. No mention of prerequisites, exclusions, or typical use cases, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the local TypeWhisper API is reachable and has a model ready.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds valuable context about checking reachability and model readiness, which goes beyond the 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?
Single sentence, front-loaded with the core purpose. No wasted words, highly concise and well-structured.
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 health-check tool with no output schema, the description is complete. It covers the essential purpose and behavior adequately.
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?
The tool has no parameters, and schema description coverage is 100%. The description does not need to add parameter details. Baseline for 0 parameters is 4, and the description meets expectations.
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 checks if the local TypeWhisper API is reachable and has a model ready. This is a specific verb ('Check') targeting a resource ('TypeWhisper API'), and it distinguishes from sibling tools which focus on dictionary operations and transcription.
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 instead of alternatives. However, the context of sibling tools implies this is a health check, so usage is inferred but not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe a local audio or video file through the running TypeWhisper app.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to an audio or video file on this Mac. | |
| task | No | TypeWhisper task. Defaults to transcribe. | |
| model | No | Optional model id override. | |
| engine | No | Optional TypeWhisper engine/provider id override. | |
| language | No | Exact ISO 639-1 source language, for example de or en. | |
| awaitDownload | No | Wait for model restore/download instead of failing fast. | |
| languageHints | No | Ordered language hints. Do not combine with language. | |
| targetLanguage | No | Target language for Apple Translate output. | |
| applyCorrections | No | Apply TypeWhisper Dictionary Corrections. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=false and destructiveHint=false, so description adds little beyond stating 'Transcribe'. No disclosure of time, file size limits, permissions, or output behavior.
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, no redundant words. Perfectly concise for the purpose.
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?
Lacks critical context: what happens on file not found, supported formats, how to retrieve transcription result (no output schema). For a 9-parameter tool, description is too minimal.
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% (all parameters have descriptions). Description does not add any parameter details beyond what 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?
Clear verb 'Transcribe' and resource 'local audio or video file through the running TypeWhisper app.' Distinguishes from sibling tools focused on dictionary corrections and model listing.
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?
Implied usage: transcribe files via TypeWhisper. No explicit guidance on when to use vs. alternatives like typewhisper_search_history 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.
Add or update one post-transcription correction in the TypeWhisper dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
| original | Yes | ||
| replacement | Yes | ||
| caseSensitive | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds no extra behavioral context beyond stating the upsert nature. It does not mention side effects, permissions, or response format.
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, clear sentence with no unnecessary words. It is concise, though could be slightly expanded to include parameter hints without losing brevity.
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 has 3 parameters, no output schema, and only basic annotations, the description is too minimal. It does not explain what a 'post-transcription correction' is, how the parameters work, or what the tool returns on success or failure.
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?
With 0% schema description coverage, the parameter names (original, replacement, caseSensitive) are somewhat self-explanatory but the description does not explain them. No additional context is provided to clarify meaning 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 action (Add or update) and the resource (one post-transcription correction in the TypeWhisper dictionary). It effectively distinguishes the tool from siblings like typewhisper_upsert_dictionary_terms (which handles multiple terms) and typewhisper_delete_dictionary_correction (deletion).
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 single corrections but does not explicitly state when to use this tool versus alternatives like typewhisper_upsert_dictionary_terms. There is no guidance on prerequisites 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.
Merge or replace TypeWhisper recognition terms.
| Name | Required | Description | Default |
|---|---|---|---|
| terms | No | ||
| replace | No | Replace the full term list instead of merging. Defaults to false. | |
| termEntries | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, idempotent, and non-destructive. The description adds no further behavioral context (e.g., error handling, prerequisites).
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 but lacks necessary detail for a multi-parameter tool. It is front-loaded but under-informative.
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?
With 3 parameters, no output schema, and sibling tools, the description is too brief. It fails to clarify the difference between terms and termEntries or the merge/replace semantics.
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?
Description does not explain any parameters. Schema covers only one parameter (replace) with a description; the other two (terms, termEntries) lack explanation, and the tool description provides no help.
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 ('merge or replace') and the resource ('TypeWhisper recognition terms'), distinguishing it from sibling tools like deletion or listing 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?
No guidance on when to use merge vs replace or how to choose between this and related tools like typewhisper_upsert_dictionary_correction. The agent is left to infer usage context.
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. Dates show when Glama detected each change.
v0.1.0typewhisper_delete_dictionary_correctiontypewhisper_delete_dictionary_termtypewhisper_list_dictionary_correctionstypewhisper_list_dictionary_termstypewhisper_list_modelstypewhisper_search_historytypewhisper_statustypewhisper_transcribe_filetypewhisper_upsert_dictionary_correctiontypewhisper_upsert_dictionary_termsEach tool targets a distinct resource and action: dictionary corrections vs terms, models, history, status, and transcription. No overlap in purpose.
All tools follow the 'typewhisper_verb_noun' pattern, but there are minor plural/singular inconsistencies (e.g., 'correction' vs 'corrections', 'term' vs 'terms') that reduce perfect consistency.
Ten tools cover the core functionality of transcription and dictionary management without being excessive or insufficient.
The set provides CRUD operations for dictionary items, plus transcription, model listing, status, and history search. Missing individual get operations for dictionary items, but this is a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
Search, read, and write your Apple Notes from ChatGPT/Claude via a local Mac agent + MCP relay.
Build and supervise fleets of agents from Claude Code, Codex or Cursor. Connects over OAuth.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TypeWhisper/typewhisper-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
