A specialized Model Context Protocol (MCP) Server that bridges Claude Desktop, Claude Code, and Cursor IDE to persistent NAS/Server task scheduling, deep recursive web documentation crawlers, offline document RAG knowledge bases, and smartphone push alerts with human-in-the-loop approvals.
State-of-the-art coding assistants like Claude Desktop and Cursor excel at writing and editing code within your local repository. However, they lack:
Persistent Execution: They cannot run long jobs in the background on your home server or NAS while your workstation is asleep.
Deep Documentation Crawling: Web crawlers in desktop LLMs are constrained; they cannot recursively crawl an entire documentation site (e.g. 50+ pages of Flutter or Kubernetes docs) and index it into a persistent local vector/FTS database for instant retrieval.
Mobile Human-in-the-Loop: When Claude finishes a 30-minute build, benchmark, or deployment script, it cannot notify your phone or ask you to tap [Approve] / [Reject] while you are away from your desk.
TealKit MCP solves all three problems by exposing 10 targeted tools across 3 core pillars.
Related MCP server: Hoard
Offload long-running tasks and cron schedules to your TealKit Server or NAS.
tealkit_schedule_job: Schedules recurring background cron tasks (e.g. daily backups, nightly benchmark runs, continuous health checks).
tealkit_run_background: Dispatches asynchronous long-running jobs (fire-and-forget) to your server worker pool. Supports exact task IDs or human-readable names (e.g. "tcloud disk space").
tealkit_get_job_status: Checks logs, exit status, and progress of any queued or running job.
tealkit_list_jobs: Lists all active, scheduled, and configured jobs on your server.
Turn any documentation website or directory into an offline SQLite knowledge base with citations.
tealkit_crawl_and_index: Recursively crawls a website documentation tree (up to max_pages) and ingests chunks into your local offline knowledge base.
tealkit_index_local_docs: Indexes local directories containing PDFs, Word (.docx), Markdown (.md), and text files.
tealkit_search_knowledge: Performs hybrid Reciprocal Rank Fusion (BM25 FTS5 + vector similarity) searching with exact citations, file paths, and line ranges.
tealkit_get_source_doc: Retrieves the complete stored content and metadata of any indexed document or web page.
Keep the developer informed and in control from anywhere.
tealkit_send_mobile_alert: Sends instant push notifications with configurable priority to the user's smartphone.
tealkit_request_mobile_approval: Presents an interactive confirmation card on the user's smartphone with Approve / Reject buttons and waits for human authorization before high-risk actions (e.g. database migrations, cloud deployments).
Dart SDK 3.0 or later installed on your system.
Clone the repository:
git clone https://github.com/lschaffer/tealkit-mcp.git
cd tealkit-mcp
dart pub getCompile a standalone native binary (optional, for maximum speed):
dart compile exe bin/tealkit_mcp.dart -o tealkit-mcp.execlaude_desktop_config.json)On Windows (%APPDATA%\Claude\claude_desktop_config.json) or macOS (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"tealkit": {
"command": "dart",
"args": [
"run",
"C:/projects/ls/tealkit-mcp/bin/tealkit_mcp.dart"
],
"env": {
"TEALKIT_SERVER_URL": "https://tealkit.dev/tealkitserver",
"TEALKIT_SERVER_KEY": "YOUR_SERVER_API_KEY",
"TEALKIT_PUSH_URL": "https://ntfy.sh/your-private-alert-topic"
}
}
}
}Or if using the compiled executable:
{
"mcpServers": {
"tealkit": {
"command": "C:/projects/ls/tealkit-mcp/tealkit-mcp.exe",
"args": []
}
}
}.cursor/mcp.json)Add to your Cursor project or global settings:
{
"mcpServers": {
"tealkit": {
"command": "dart",
"args": [
"run",
"C:/projects/ls/tealkit-mcp/bin/tealkit_mcp.dart"
]
}
}
}TealKit MCP supports three flexible methods to deliver push notifications and human-in-the-loop approvals to your phone:
ntfy.sh is a free, privacy-friendly, open-source HTTP push notification service:
Install the free ntfy app on your phone:
Open the ntfy app and tap + to subscribe to your own private topic name (e.g. tealkit-dev-alert-9823).
Set the endpoint in your config:
push:
endpoint: "https://ntfy.sh/tealkit-dev-alert-9823"or via environment variable TEALKIT_PUSH_URL=https://ntfy.sh/tealkit-dev-alert-9823.
Claude can now send alerts and approval prompts directly to your lock screen with zero infrastructure setup.
If you have the TealKit Flutter mobile app running:
The app connects to the event stream at https://tealkit.dev/tealkitserver/api/v1/events.
When tealkit_send_mobile_alert is executed, the server broadcasts an alert event to the mobile client.
The mobile app displays a system notification using flutter_local_notifications (task_success, task_error channels).
For enterprise or production deployments where notifications must wake up a fully closed mobile app:
Register your device token in the TealKit Server device registry (/api/v1/devices).
Configure TEALKIT_PUSH_KEY with your server's Firebase service credentials.
High-priority pushes are routed directly through Google/Apple APNs gateways.
TealKit MCP can be configured via environment variables or a local config.yaml file located in ~/.tealkit_mcp/config.yaml or ./config.yaml:
server:
url: "https://tealkit.dev/tealkitserver" # Or local NAS: http://192.168.1.50:8080
api_key: "your_api_key"
rag:
database_path: "~/.tealkit_mcp/knowledge.db"
push:
endpoint: "https://ntfy.sh/your-topic"
auth_token: ""Variable | Description | Default |
| Base URL of TealKit Server / NAS instance |
|
| Bearer API token for server authentication |
|
| Push gateway endpoint for mobile alerts |
|
| Push gateway authorization secret |
|
TealKit MCP is built with 100% pure Dart, ensuring instant startup (<100ms), zero native C++ driver dependencies, and cross-platform compatibility across Windows, Linux, and macOS.
┌────────────────────────────────────────────────────────┐
│ Claude Desktop / Cursor IDE │
└──────────────────────────┬─────────────────────────────┘
│ JSON-RPC 2.0 (stdio)
┌──────────────────────────▼─────────────────────────────┐
│ TealKit MCP Server │
├───────────────────┬──────────────────┬─────────────────┤
│ Task Scheduler │ RAG Pipeline │ Mobile Bridge │
│ (Server Bridge) │ (Crawler & FTS5) │ (Push Gateway) │
└─────────┬─────────┴────────┬─────────┴────────┬────────┘
│ │ │
TealKit Server/NAS Local SQLite DB Smartphone App (ntfy / TealKit)This project is licensed under the MIT License - see the LICENSE file for details.
Recursively crawls a website documentation tree (up to max_pages) and indexes it into the local offline RAG knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Root URL to start recursive crawling (e.g. https://docs.flutter.dev) | |
| max_pages | No | Maximum number of pages to crawl (default: 30, max: 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not say whether the crawl is synchronous or returns a job id (a live question given tealkit_get_job_status / tealkit_run_background siblings), how long it may take, whether it overwrites or appends to the existing index, or whether it respects robots.txt/rate limits.
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?
A single front-loaded sentence that names the action, the scope constraint, and the destination. No filler or redundant restatement of the tool name.
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 long-running crawl-and-index mutation with no annotations and no output schema, the description omits the two things an agent most needs: whether the call blocks or returns a job handle, and what happens to previously indexed content. The surrounding job-management siblings make that omission material.
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 both url and max_pages are already documented in the schema with examples, defaults and bounds. The description only restates max_pages as a scoping limit and adds no format or constraint detail beyond what the schema provides, so the baseline of 3 applies.
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?
States a specific verb+resource ('recursively crawls a website documentation tree') and the outcome ('indexes it into the local offline RAG knowledge base'), with scope limited by max_pages. It implicitly distinguishes itself from the sibling tealkit_index_local_docs by specifying a website rather than local files, though it never names that sibling 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?
The phrase 'offline RAG knowledge base' hints at the purpose, but there is no explicit when-to-use guidance, no mention of the alternative tealkit_index_local_docs for local files, and no note on when to use this versus the job-management siblings (schedule_job, run_background).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspects the execution logs, exit status, and progress of a background or scheduled job.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Unique execution Job ID returned by tealkit_run_background | |
| tail_lines | No | Number of trailing log lines to retrieve (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the categories of information returned (logs, exit status, progress), which usefully implies a read-only inspection. However, it never states that the operation is non-destructive or read-only, nor whether it blocks/polls on a running job or what happens for an unknown job_id.
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?
A single tight sentence with the resource and the returned information front-loaded. Every word earns its place and there is no filler.
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 no output schema, the description must convey return content and it does so by naming logs, exit status, and progress. For a 2-parameter read tool this is nearly complete; only the not-found/error behavior and the overlap with tealkit_list_jobs remain unaddressed.
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 job_id tied to tealkit_run_background and tail_lines documented with its default of 50, so the schema does the heavy lifting. The description adds nothing about either parameter, so the baseline of 3 applies.
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?
States a specific verb ('Inspects') and names the concrete outputs (execution logs, exit status, progress) for a background or scheduled job. It is clear what the tool returns, but it never distinguishes itself from the sibling tealkit_list_jobs, so an agent must guess which one to call for job state.
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 when-to-use, when-not-to-use, or prerequisite guidance is given. The sibling tealkit_list_jobs clearly overlaps (both surface job state), yet the description offers no routing rule, and it doesn't say that tealkit_run_background must be called first to obtain a job_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the full stored content of a document or web page from the knowledge base by URL or filepath.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | File path or URL returned in search citations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Retrieves' and 'full stored content' convey a read-only fetch of previously indexed material, which is useful behavioral context, but it says nothing about failure modes (e.g. source not indexed), permissions, or whether retrieval is cached/live.
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?
One tight sentence with no filler, and the resource and input type are front-loaded so an agent can act immediately.
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 read tool with no output schema and no annotations, this covers what the tool does and what it accepts. It would be fully complete if it noted the prerequisite that the source must already be indexed.
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% for the single 'source' parameter, so the schema already documents the accepted file path or URL. The description's 'by URL or filepath' merely restates that, adding no format or syntax detail beyond the structured field. Baseline 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?
States a specific verb (Retrieves) and resource (full stored content of a document or web page) with the scoping qualifier 'from the knowledge base by URL or filepath'. It implicitly distinguishes itself from tealkit_search_knowledge by emphasizing 'full stored content', but never names that sibling 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?
Usage is only implied: the phrase 'returned in search citations' in the schema plus 'full stored content' suggests this is the follow-up step to a search. There is no explicit when-to-use, when-not-to-use, or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Indexes a local directory containing PDFs, Word (.docx), Markdown (.md), or text files into the knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
| folder_path | Yes | Absolute path to the directory containing documents |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses supported file types and the destination (knowledge base), but omits key traits such as whether indexing runs asynchronously as a background job (siblings include run_background, get_job_status, list_jobs), whether existing content is replaced or merged, and what permissions are required.
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 states the action, input type, and destination with no filler. Every clause 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 an indexing tool with no annotations and no output schema, the description should explain the likely asynchronous/job behavior and the effect on the knowledge base. It does not clarify whether a job is queued, what is returned, or how existing indexed content is affected, leaving material gaps for correct invocation and follow-up.
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 schema description coverage is 100% and the single parameter folder_path is fully documented as an absolute directory path. The description reinforces the 'local directory' scope but adds no syntax, formatting, or constraint details beyond what the schema already provides.
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 states a specific verb and resource: indexing a local directory of documents into the knowledge base, and it enumerates supported formats (PDF, .docx, .md, text). It is clearly distinct from a generic search or job tool, but it does not explicitly distinguish itself from the sibling tealkit_crawl_and_index, which likely handles remote content.
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 when the tool is used (local documents need indexing) but gives no explicit guidance on when to choose it over alternatives such as tealkit_crawl_and_index. There are no prerequisites, exclusions, or alternative-routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all configured, scheduled, and currently running background jobs on the TealKit server.
| 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. 'Lists' implies a non-destructive read, and it usefully discloses that all three job states are returned, but there is nothing about result volume, pagination, ordering, or permissions. Modest value beyond what the name already conveys.
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?
A single front-loaded sentence with no filler, hedging, or redundancy. Every clause (resource, server scope, the three job states) contributes 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 zero-argument, read-only listing tool with no output schema, the description covers the essential distinction (which job categories are returned). It would be stronger if it sketched the fields in a job entry or its ordering, but nothing critical to invocation is missing.
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 takes zero parameters, so there is no parameter semantics for the description to expand on; the 4 baseline applies. Schema coverage of 100% is trivially satisfied by an empty object.
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?
Names a specific verb (Lists) and resource (background jobs on the TealKit server), and enumerates the three job states covered (configured, scheduled, running). That is enough for an agent to identify the tool, though it never contrasts itself with the sibling tealkit_get_job_status, which is the natural source of confusion.
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?
Usage is only implied: the tool is obviously the enumeration counterpart to get_job_status, but the description never states when to reach for this versus that sibling, nor any preconditions or exclusions. It is adequate for a zero-parameter list but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends an interactive approval prompt to the user smartphone and waits until the user taps Approve or Reject.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the action requiring confirmation (e.g. Deploy to Production?) | |
| details | No | Optional diff snippet or detailed command line | |
| summary | Yes | Summary of proposed changes or commands about to be run | |
| timeout_seconds | No | How long to wait for user mobile response before timing out (default: 180s) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the single most important trait — that the call blocks and waits for a human response — which is genuinely valuable. It does not state what happens on rejection (error vs returned rejection value), what happens on timeout, or whether the call requires prior authentication/session setup.
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?
A single front-loaded sentence that states the action, the interaction medium, and the blocking behavior with no filler. Nothing could be removed without losing meaning.
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 four-parameter tool with no output schema, the description plus schema covers the essentials: what is sent, what is waited on, and the timeout bound. The remaining gaps are the timeout/rejection outcome and sibling differentiation, both of which an agent would need for correct tool selection.
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%: all four parameters, including the 180s default for timeout_seconds and the 'diff snippet or detailed command line' meaning of details, are documented in the schema itself. The description adds no parameter-level information beyond that, so the baseline of 3 applies.
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 names a specific verb and resource ('Sends an interactive approval prompt to the user smartphone') and states the interaction model, so the core purpose is unambiguous. However, it never distinguishes itself from the closest sibling, tealkit_send_mobile_alert, which is the exact distinction an agent needs (blocking approval vs one-way notification).
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?
Usage is implied: 'waits until the user taps Approve or Reject' signals that this is a blocking call suited for gating a risky action. There is no explicit when-to-use statement, no when-not-to-use, and no mention of the alternative tealkit_send_mobile_alert for non-blocking notification, leaving the selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dispatches an asynchronous, long-running task to the TealKit server/NAS (fire-and-forget).
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Task ID, registered workflow name, or shell command to execute | |
| arguments | No | Optional parameters or payload JSON for the background execution | |
| timeout_minutes | No | Maximum execution timeout in minutes (default: 60) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that execution is asynchronous and fire-and-forget (i.e., no inline result), which is real behavioral value, but it omits what an agent most needs: that the call returns a job handle and results must be retrieved via tealkit_get_job_status/tealkit_list_jobs, plus any auth or concurrency constraints.
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?
A single front-loaded sentence with zero filler; the dispatch model is stated immediately. It is arguably too terse for a task-dispatch tool, but nothing is wasted.
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 3-parameter mutation/dispatch tool with no annotations and no output schema, the description covers what it does but not the surrounding workflow — notably how to observe the dispatched job or that the call is non-blocking with respect to results. Sibling tools like tealkit_get_job_status exist but are not referenced.
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 'task', 'arguments', and 'timeout_minutes' are already fully documented in the schema. The description adds no format, syntax, or payload detail beyond that, so the baseline 3 applies.
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?
States a specific verb ('Dispatches') and resource ('asynchronous, long-running task to the TealKit server/NAS'), with the parenthetical 'fire-and-forget' clarifying the dispatch model. It does not explicitly distinguish itself from the closest sibling, tealkit_schedule_job, so an agent must infer the difference.
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 says nothing about when to choose this tool over tealkit_schedule_job (deferred) or tealkit_crawl_and_index (specific workloads). There is no exclusion, prerequisite, or alternative guidance — only an implied async-execution context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedules a persistent, recurring background task (cron job) on the TealKit Server or NAS.
| Name | Required | Description | Default |
|---|---|---|---|
| cron | Yes | Standard 5-field cron expression (e.g. 0 3 * * * for daily at 3 AM) | |
| profile | No | Optional execution profile or environment (default: default) | default |
| task_name | Yes | Human-readable name for the scheduled task | |
| command_or_prompt | Yes | The prompt, shell command, or AgentSkill to execute periodically |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that the task is 'persistent' and 'recurring' and can target a Server or NAS, which is real behavioral context beyond the name. However, it says nothing about side effects, permissions, whether scheduling the same task_name replaces an existing job, or failure 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?
A single tightly written sentence with the key facts front-loaded: action, persistence/recurrence, and target. No filler, though it is arguably too terse given the tool's complexity.
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?
All three required parameters are documented in the schema and no output schema is needed for a creation call. But with no annotations and no output schema, the description should disclose more about persistence semantics and conflict/duplicate handling; it stops at a one-line summary.
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 all four parameters (cron, profile, task_name, command_or_prompt) are already documented in the schema. The description adds no format, syntax, or constraint detail beyond what the schema provides, so baseline 3 applies.
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?
States a specific verb (schedules), resource (persistent, recurring background task / cron job), and execution target (TealKit Server or NAS). It does not name the sibling tealkit_run_background it should be contrasted with, so differentiation is left implicit.
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 when-to-use or when-not-to-use guidance. With a sibling like tealkit_run_background (one-shot execution) present, the description never tells the agent to choose this tool only for recurring/persistent jobs rather than immediate runs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the offline local knowledge base (crawled web documentation and local files) with exact citations, file paths, and line numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query or question | |
| max_results | No | Maximum number of chunks to return (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose useful behavior: the corpus searched is local/offline and results include exact citations, file paths, and line numbers. It omits the prerequisite that content must first be indexed (tealkit_index_local_docs / tealkit_crawl_and_index), says nothing about read-only semantics or result limits beyond the schema default, and gives no guidance on empty results.
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?
A single front-loaded sentence: verb and resource first, corpus and return contents after. No redundancy with the title or filler, and every clause adds information an agent can act on.
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 low-complexity two-parameter search tool with no output schema, the description compensates well by stating the corpus and the shape of results (citations, file paths, line numbers). The main gap is the indexing prerequisite and any hint about how to use results versus tealkit_get_source_doc.
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 both 'query' and 'max_results' are already documented, and the description adds no syntax, format, or query-construction guidance. Per the rubric, full schema coverage sets the baseline at 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?
States a specific verb (searches) and resource (offline local knowledge base) and names the corpus (crawled web documentation and local files), which clearly separates it from indexing siblings like tealkit_crawl_and_index and tealkit_index_local_docs. It stops short of naming a sibling to route to, e.g. tealkit_get_source_doc for fetching a full document, so it is clear but not fully differentiated.
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 'offline local knowledge base' implies the context in which this tool applies (querying already-indexed local content rather than live sources), but there is no explicit when-to-use or when-not-to-use statement and no alternative is named. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends an instant push notification to the user TealKit mobile app (Android / iOS).
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Brief notification headline (e.g. Build Finished, Action Required) | |
| message | Yes | Notification body text with details or summary | |
| priority | No | Priority level: low, normal, high, urgent (default: normal) | normal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it only says the notification is 'instant' and reaches Android/iOS. It is silent on delivery guarantees, whether the user must have the app registered, rate limits, and whether the call is fire-and-forget or blocking.
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?
A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity is partly why other dimensions are thin.
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 3-parameter notification tool with full schema coverage and no output schema, the description covers the core action adequately. It is incomplete regarding delivery behavior and failure modes, which an agent invoking a push-notification tool would benefit from knowing.
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 title, message, and priority are already fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.
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?
States a specific verb (sends) and resource (instant push notification) plus the target channel (TealKit mobile app on Android/iOS), which is enough to distinguish it from most siblings. It does not, however, explicitly contrast itself with the closest sibling, tealkit_request_mobile_approval.
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 offers no when-to-use or when-not-to-use guidance and names no alternative. An agent must infer from the phrase 'instant push notification' that this is for one-way notifications rather than approval requests, which is left entirely to the reader.
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.0tealkit_crawl_and_indextealkit_get_job_statustealkit_get_source_doctealkit_index_local_docstealkit_list_jobstealkit_request_mobile_approvaltealkit_run_backgroundtealkit_schedule_jobtealkit_search_knowledgetealkit_send_mobile_alertScored across 10 tools
Most tools target distinct operations, but tealkit_schedule_job and tealkit_run_background both create background tasks, and tealkit_crawl_and_index / tealkit_index_local_docs both feed the same knowledge base. Descriptions do clarify the distinction (recurring/cron vs fire-and-forget; web vs local source), so confusion is limited.
All tools use the tealkit_ prefix with snake_case verb_noun phrasing (list_jobs, schedule_job, get_job_status, search_knowledge). Minor deviations like run_background and crawl_and_index use compound verbs but remain readable and consistent enough.
Ten tools is well-scoped and each earns its place, spanning job management, knowledge-base indexing/search, and mobile notifications without redundancy.
Job lifecycle covers list/schedule/run/status but lacks a cancel or delete operation, and the KB surface has no re-index or removal capability. These are minor gaps an agent can work around for the core workflows.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
DocBase MCP server for AI agents
