Provides tools and resources for interacting with local SQLite databases: managing personal tasks with persistence, version checks, audit history, and querying allowlisted tables via bounded read-only SQL queries.
Click on "Deploy 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., "@Personal Workspace MCP Server create a high-priority task to review my assignment due on 2026-10-10"
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.
A Python MCP server that gives an AI assistant three practical capabilities: manage personal tasks, answer questions from a local SQLite database, and retrieve weather forecasts.
The server uses the official Model Context Protocol Python SDK. Natural-language interpretation happens in your MCP client: the assistant reads the schema, selects a tool and supplies validated arguments. This project does not contain a hidden chatbot or require an LLM API key.
Tasks: create, search, filter, update, complete, archive and restore tasks. SQLite persists data between sessions. Version checks prevent stale updates, and every change records an audit event.
Database questions: expose a configured SQLite database through schema resources and bounded read-only queries. Only explicitly allowed tables are visible.
Weather: search locations and retrieve current modeled weather plus up to seven forecast days from Open-Meteo. Results retain units, source and retrieval time.
Example requests in an MCP-capable assistant:
Create a high-priority task to review my assignment, due on 2026-10-10.
Show unfinished tasks due before 2026-10-12.
How many tasks do I have in each status?
Find Harare in Zimbabwe and show the next three days of weather.
Which sample courses have more than 12 credits?
Related MCP server: mcp-server-sqlite
Requires Python 3.11 or newer.
git clone https://github.com/Jemade/MCP-SERVER.git
cd MCP-SERVER
python -m venv .venv
source .venv/bin/activate
# Windows PowerShell: .venv\Scripts\Activate.ps1
python -m pip install -e ".[dev]"
python examples/smoke_client.pyStart the server:
personal-mcp --task-db ./data/tasks.dbThe server communicates over stdio. Waiting silently for client messages is normal; it is not a browser application. Connect it to an MCP client to interact.
For clients supporting the common mcpServers configuration, use absolute paths. Replace the example paths with your actual checkout and Python executable.
{
"mcpServers": {
"personal-workspace": {
"command": "/absolute/path/MCP-SERVER/.venv/bin/python",
"args": ["-m", "personal_mcp.server"],
"env": {
"TASK_DB_PATH": "/absolute/path/MCP-SERVER/data/tasks.db"
}
}
}
}On Windows, use the absolute .venv\\Scripts\\python.exe path and escaped backslashes in JSON. Restart the client after editing its configuration. Exact configuration locations vary by client.
You can also inspect the server without an LLM:
npx -y @modelcontextprotocol/inspector .venv/bin/python -m personal_mcp.server --task-db ./data/tasks.dbApprove task mutations in your client. Tool annotations and prompts guide the client, but approval enforcement belongs to the host application.
Create the demonstration database:
python examples/create_sample_database.py
personal-mcp --task-db ./data/tasks.db --query-db ./data/sample_courses.db --tables coursesThe catalog is fictional sample data, not an official University of Zimbabwe catalog. You can substitute an existing database and a comma-separated allowlist such as --tables courses,departments.
For a configured client, add:
{
"QUERY_DB_PATH": "/absolute/path/MCP-SERVER/data/sample_courses.db",
"QUERY_ALLOWED_TABLES": "courses"
}Read database://schema first, then query with placeholders:
SELECT code, title, credits FROM courses WHERE credits > ? ORDER BY codePass parameters: [12]. The returned columns correspond positionally to each array in rows. If truncated is true, narrow the query or aggregate results before answering.
Tool | Purpose |
| Create a task with optional deadline and priority |
| Filter and paginate tasks |
| Read one task and its current version |
| Change supplied fields with an expected version |
| Hide a task without deleting it |
| Restore an archived task |
| Read the latest 100 audit events |
| Describe allowlisted tables |
| Execute one bounded read-only query |
| Return up to five candidate locations |
| Fetch weather for selected coordinates |
Resources: database://schema, tasks://overview.
Prompts: plan_day(day), analyze_database(question).
Task statuses: todo, in_progress, done. Priorities: low, medium, high. Deadlines use YYYY-MM-DD; audit timestamps use UTC. To remove a deadline, call update_task with clear_due_date: true.
flowchart TD
A["MCP client and AI assistant"] --> B["Python MCP server over stdio"]
B --> C["Task tools"]
B --> D["Read-only SQL tools"]
B --> E["Weather tools"]
C --> F["Task SQLite file and audit events"]
D --> G["Allowlisted SQLite tables"]
E --> H["Open-Meteo APIs"]The task database and query database can be the same file or separate files. Weather is the only outbound integration. No frontend, remote account system or public HTTP endpoint is included.
Task SQL uses bound parameters. Task updates use optimistic concurrency.
Query connections open in read-only mode. A SQLite authorizer rejects writes, PRAGMAs, attachments, access to other tables and unapproved functions. Arbitrary views and recursive queries are not supported.
Queries are limited to 10,000 SQL characters, 200 rows, roughly 100 KB of serialized row data and a one-second execution budget. SQLite value size is capped at 1 MB.
Weather requests use fixed HTTPS endpoints, a ten-second timeout, bounded response bodies, up to three attempts for temporary failures and a five-minute cache.
The cache is per process, holds at most 128 entries and is not a distributed quota system.
This is a single-user local server. It inherits the permissions of the user running it. It is not a sandbox for executing code and should not be published as an unauthenticated remote service.
Allowlisting tables exposes all readable columns in those tables. Use a sanitized database when some columns contain information you do not want to share with your assistant.
Treat database text and API results as untrusted data. The prompts advise this, but they cannot guarantee an AI client will resist prompt injection.
Back up task data with SQLite's backup API or stop the process before copying the database and associated WAL files.
Open-Meteo's public API does not require a key for its free noncommercial service. Review its current terms and subscription requirements before commercial use. Display attribution when presenting forecasts. The server returns modeled weather, not a guarantee of observed conditions.
Sources:
ruff check .
pytest -q
python examples/smoke_client.pyTests cover task persistence, stale and concurrent updates, input validation, table authorization, blocked SQL operations, output limits, HTTP errors, retries, caching and MCP discovery. The smoke client starts a real stdio subprocess and exercises tool calls, resources, prompts and write rejection.
CI runs on Python 3.11, 3.12 and 3.13. Network calls in unit tests use an HTTP mock transport; live provider availability is separate.
The dependency range intentionally targets the SDK v1 maintenance line (mcp<2) and is tested against 1.30.0. Upgrading to v2 requires adapting and rerunning the protocol tests. See the official SDK documentation.
No terminal output: stdio servers wait for an MCP client. Run the smoke client or Inspector.
Database does not exist: the task database is created automatically; an external query database must already exist.
Query rejected: inspect the schema and use one SELECT over allowlisted tables and approved functions.
Version conflict: call get_task, review the newer values and retry with its current version.
Weather unavailable: check network connectivity and retry later. Local task tools continue working independently.
Client cannot import the package: use the exact virtual-environment Python where you installed this project.
MIT. See LICENSE.
Archive a task without deleting its data or history.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| expected_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the non-destructive framing in the description is partly redundant. It does add useful context that history is retained, but says nothing about permission requirements or whether archiving is reversible.
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 sentence, front-loaded with the action, with no filler. 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 mutation tool with a non-obvious expected_version parameter and no output schema, the description omits the concurrency semantics, reversibility, and any alternative (restore_task). It is not adequate for an agent to invoke confidently.
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 0%, so neither parameter is documented in the schema. task_id is self-evident, but expected_version clearly implies optimistic-concurrency semantics that the description never explains—a genuine gap the description should fill.
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 (archive) and resource (task), and adds scope clarification that the data and history are preserved. It implicitly distinguishes itself from a delete-style operation, though it never names a sibling tool to sharpen the contrast.
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 archive versus update_task, or how to undo it via restore_task, which is a listed sibling. The agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a task. due_date is an optional YYYY-MM-DD calendar date.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| due_date | No | ||
| priority | No | medium | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond that: nothing about required permissions, duplicate-title handling, whether priority/description defaults are applied, or what side effects creation has.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler, and the core action is front-loaded. It is efficient but arguably too terse for a four-parameter mutation tool.
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 mutation tool with no output schema and only safety annotations, the description leaves significant gaps: no return-value expectations, no error conditions (e.g. title length bounds of 1–500), and no explanation of the three undocumented parameters. An agent can call it, but not confidently.
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 0%, so the description carries the full burden, yet it only annotates one of four parameters (due_date as an optional YYYY-MM-DD calendar date — genuinely useful since the schema types it as an unformatted string). title, priority, and description get no semantic detail; priority's enum is self-documenting but the interaction of defaults remains unstated.
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 and resource ('Create a task'), which is enough for an agent to distinguish it from get_task, update_task, archive_task, and restore_task by verb alone. However it does not explicitly differentiate from any sibling or scope what kind of task it produces.
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 when-to-use guidance, no mention of prerequisites such as a parent project or workspace, and no routing to alternatives like update_task for existing tasks. The agent must infer everything from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the configured allowlisted SQLite tables before composing SQL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful scoping fact that only allowlisted tables are described, but says nothing about output shape, caching, or 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?
A single front-loaded sentence with no waste; the purpose and the when-to-use cue are both packed into one clause.
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-parameter, read-only introspection tool with no output schema, the description covers purpose, scope (allowlisted tables), and timing. Only the absence of any hint about the returned structure keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics to convey and the baseline of 4 applies. The description correctly implies the tool is parameterless by framing it as a whole-schema introspection.
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 (Describe) and resource (configured allowlisted SQLite tables), making the tool's output clear. It doesn't name the sibling it complements (query_database), but the resource is specific enough to distinguish it from the task tools and from query_database.
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 'before composing SQL' gives explicit timing guidance, implying it should be called prior to query_database. It stops short of naming query_database as the alternative, so the routing is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one task, including its version for optimistic updates.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral detail — that the response includes a version for optimistic concurrency — but says nothing about error behavior for missing tasks.
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 short sentence with the core action front-loaded and 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 a simple single-record read with annotations covering safety and no output schema, the description is nearly sufficient, and the version note is a valuable addition. Only the parameter meaning is left 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 0% and the description does not mention task_id at all, so it fails to compensate for the undocumented parameter. The only reason this is not a 1 is that the parameter name is self-describing.
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 (Read) and resource (one task) with the scope narrowed to a single record, which implicitly separates it from list_tasks. It does not explicitly name siblings, so it stops short of a 5.
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 'for optimistic updates' hints at the intended workflow (read before writing), but there is no explicit when-to-use/when-not guidance or named alternative. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter tasks with pagination. Search matches title or description.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| search | No | ||
| status | No | ||
| priority | No | ||
| due_before | No | ||
| include_archived | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds that results are paginated and that search matches title or description, which is genuinely useful context beyond the annotations, but it omits ordering, default scoping, and archived-record 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?
Two short sentences with zero filler, and the functional statement is front-loaded. It is efficient, though arguably too terse given the documentation gaps elsewhere.
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 7-parameter tool with 0% schema description coverage and no output schema, the description is far too thin: four filter parameters and their accepted values are never explained, and default scoping/archived behavior is unstated.
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 0% across 7 parameters, so the description must carry the burden. It only loosely implies limit/offset (pagination) and explains search, leaving status, priority, due_before, and include_archived entirely undocumented in both schema and description.
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 clear verb and resource ('Filter tasks') plus two behavioral facts (pagination, search target). However it does not distinguish itself from sibling list/read tools like get_task or task_history, so sibling differentiation is absent.
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 when-to-use guidance, no prerequisites, and no mention of alternatives such as get_task for a single task. Usage is only implicitly inferable from the verb 'filter'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute one read-only SELECT query. Use ? placeholders and parameters for values.
| Name | Required | Description | Default |
|---|---|---|---|
| max_rows | No | ||
| sql_query | Yes | ||
| parameters | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the query must be a single read-only SELECT and values must be bound via ? placeholders rather than inlined. It does not mention row capping behavior or error/failure semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler, and the core constraint (read-only SELECT) plus the binding convention are front-loaded. 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 a database query tool with no output schema, the description covers the statement type and parameter binding but omits the result-size cap (max_rows default 100, max 200) and any note on error behavior, leaving an agent to discover truncation at runtime.
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 0%, so the description carries the burden. It does explain the relationship between sql_query and parameters (the ? placeholder convention), which is valuable, but it never mentions max_rows or its default of 100 / cap of 200.
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 — 'Execute one read-only SELECT query' — which is unambiguous and clearly distinguished from the write-oriented task siblings. It does not explicitly differentiate itself from the related 'database_schema' sibling, which an agent must infer from the name alone.
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 'one read-only SELECT query' implies when this tool applies (single read statements only, no writes/DDL) and 'Use ? placeholders and parameters for values' gives a calling convention. However, there is no explicit statement of when to prefer this over database_schema or what to do for non-SELECT needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore an archived task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| expected_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-readOnly, non-destructive, closed-world mutation, so the safety profile is covered. The description adds nothing beyond that — no mention of permission requirements, whether restoration is reversible, or what happens to concurrent modification attempts.
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 short sentence with the action front-loaded and no wasted words. Its terseness is a content problem, not a structural one, so it scores well here despite being thin overall.
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 mutation tool with no output schema, 0% parameter description coverage, and an opaque required expected_version argument, the definition is not complete enough for reliable invocation. It should at minimum explain the version parameter and the precondition that the task be archived.
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 0% and there are 2 required parameters, so the description must carry the meaning. It says nothing about task_id, and critically leaves expected_version (clearly an optimistic-concurrency token) completely unexplained, which is the single most important parameter an agent could mis-supply.
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 ('Restore') and resource ('task') and narrows scope to archived tasks, which distinguishes it from the generic create/update siblings. It does not explicitly contrast with archive_task (its inverse) or explain what restore does to task state, so it stops short of a 5.
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 such as archive_task or update_task, nor any stated prerequisites (e.g., the task must currently be archived). The only hint of context is the word 'archived', which is implied rather than stated as a condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find weather locations. Return candidates; clarify ambiguous place names.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| country_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and non-destructive behavior. The description adds that it returns candidates and helps clarify ambiguity, but provides no further behavioral detail such as result format, pagination, or external lookup 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?
Two short, front-loaded sentences with no wasted words. It is appropriately brief, though slightly under-specified rather than maximally 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?
There is no output schema, so the description should explain what candidate results look like, but it says only 'Return candidates.' Combined with zero parameter documentation, the definition leaves important return and input details 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 0% and neither the 'name' nor 'country_code' parameter is mentioned in the description. With two undocumented parameters, the description fails to compensate for the schema gap.
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 and resource: 'Find weather locations.' This clearly distinguishes it from the forecast sibling, though it does not explicitly name alternatives or scope limitations.
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 'clarify ambiguous place names' implies when the tool is useful, but gives no explicit when-not guidance, prerequisites, or alternative tools to consider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read up to 100 recent audit events for a task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral trait beyond that: results are capped at 100 and are 'recent', implying a truncation and ordering behavior the agent must account for. It stops short of stating ordering explicitly or what happens for an unknown task_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?
One short sentence with the scope limit front-loaded and no filler. 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?
An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description is nearly complete for a single-parameter read tool, with only ordering/truncation nuance and task-existence behavior left implicit.
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 0% and the single task_id parameter has no description in the schema. The phrase 'for a task' partially compensates by implying task_id scopes the query, but it adds no type, format, or validity constraints beyond what the schema declares.
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 ('Read') and resource ('audit events for a task') with a concrete scope ('up to 100 recent'). It is distinguishable from get_task, which returns task details rather than audit history, though it never names the 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 purpose implies the use case (inspecting a task's audit trail), but there is no explicit when-to-use guidance and no mention of when to prefer get_task or list_tasks instead. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update supplied fields using the current version. clear_due_date removes a deadline.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| status | No | ||
| task_id | Yes | ||
| due_date | No | ||
| priority | No | ||
| description | No | ||
| clear_due_date | No | ||
| expected_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only and not destructive, which is consistent with an update operation. The description adds the important behavioral note that 'clear_due_date removes a deadline', which is beyond the annotations. However, it does not disclose other behavioral traits like required permissions, error handling, or side effects, leaving gaps for a mutation tool with no annotations covering those aspects.
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 two short sentences that are front-loaded with the core action and then add a key parameter detail. It is concise and structured, earning a 4, though a bit more context could be added without sacrificing 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 complexity of an update tool with 8 parameters, no output schema, and 0% schema coverage, the description is incomplete. It omits explanations for most parameters, error conditions, return values, and concurrency handling despite mentioning versioning. This leaves the agent with insufficient context to invoke the tool reliably.
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 description must compensate but only explains 'clear_due_date' and hints at versioning; the other six parameters (task_id, expected_version, title, status, due_date, priority, description) receive no semantic explanation. This is insufficient for an 8-parameter tool, so a 2 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update supplied fields') and references the versioning mechanism ('using the current version'). It distinguishes update from siblings like create_task and archive_task, though it does not explicitly name alternatives, so it earns a 4 rather than a 5.
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 such as create_task or archive_task, and no prerequisites or usage context are stated. The description only implies usage for updating existing tasks, which is a significant gap for a mutation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve current modeled weather and daily forecasts from Open-Meteo.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| latitude | Yes | ||
| longitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that data is 'modeled' and sourced from Open-Meteo, which is useful context, but says nothing about rate limits, auth, units, or timezone handling.
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. Appropriately sized, though the brevity comes at the cost of the missing parameter and usage detail noted above.
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 three parameters, no output schema, and annotations covering the safety profile, the description should at minimum hint at the return shape (current conditions plus a daily series) and the coordinate format. It gestures at the return content but leaves the agent guessing on units, location resolution, and response structure.
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 0%, so the description carries the full burden, yet it says nothing about latitude/longitude units or accepted ranges, and 'daily forecasts' only obliquely implies the 'days' parameter (default 3, max 7) without stating it. The agent must read the bare schema to call this correctly.
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 ('Retrieve') and resource ('current modeled weather and daily forecasts') plus the data source (Open-Meteo). It is clear enough to distinguish from the task/database siblings, though it never explicitly contrasts with anything.
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 indication of when to call this versus anything else, no prerequisites, no note that a location must be resolved first (e.g. via search_locations). The agent gets context only by inference from the sibling list.
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.0archive_taskcreate_taskdatabase_schemaget_tasklist_tasksquery_databaserestore_tasksearch_locationstask_historyupdate_taskweather_forecastScored across 11 tools
Every tool targets a distinct resource and action: task CRUD is well-separated from history, database schema is distinct from query execution, and location search is distinct from weather forecast. No two tools could be easily confused.
Most tools follow a clear verb_noun snake_case pattern (get_task, create_task, list_tasks, update_task, archive_task, restore_task, query_database, search_locations). A few tools use noun_noun instead (task_history, database_schema, weather_forecast), which is a minor deviation.
11 tools across three sub-domains (tasks, database, weather) is well-scoped; each tool has a clear, non-redundant role and the count is appropriate for the server's purpose.
Task lifecycle is fully covered (create, read, update, archive, restore, history), database access is complete for read-only queries (schema + SELECT), and weather covers both location search and forecasting.
Your life dashboard for AI: tasks, habits, goals, budgets, workouts, nutrition, journal, notes.
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
AI-native task management: list, create, update and archive tasks with rich context for AI agents
AI life manager: tasks, home, health, wealth, childcare, pets & more — on your own data.
