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., "@Task Context MCP Server search for best practices on analyzing Python developer CVs"
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.
An MCP (Model Context Protocol) server for managing task contexts and artifacts to enable AI agents to autonomously manage and improve execution processes for repetitive task types.
Important Distinction: This system manages task contexts (reusable task types/categories), NOT individual task instances.
For example:
Task Context: "Analyze applicant CV for Python developer of specific stack"
NOT stored: Individual applicant details or specific CV analyses
Stored: Reusable artifacts (practices, rules, prompts, learnings) applicable to ANY CV analysis of this type
This MCP server provides a SQLite-based storage system that enables AI agents to:
Store and retrieve task contexts with associated artifacts (practices, rules, prompts, learnings)
Perform full-text search across historical learnings and best practices using SQLite FTS5
Manage artifact lifecycles with active/archived status tracking
Enable autonomous process improvement with minimal user intervention
Store multiple artifacts of each type per task context
Related MCP server: OrgX MCP
Task Context Management: Create, update, archive, and retrieve task contexts (reusable task types)
Artifact Storage: Store multiple practices, rules, prompts, and learnings for each task context
Full-Text Search: Efficient search across all artifacts using SQLite FTS5
Lifecycle Management: Track active vs archived artifacts with reasons
Transaction Safety: ACID compliance for all database operations
get_active_task_contexts - Get all currently active task contexts
create_task_context - Create a new task context with summary and description
get_artifacts_for_task_context - Retrieve all artifacts for a specific task context
create_artifact - Create a new artifact (multiple per type allowed)
update_artifact - Update an existing artifact's summary and/or content
archive_artifact - Archive artifacts with optional reason
search_artifacts - Full-text search across all artifacts
reflect_and_update_artifacts - Reflect on learnings and get prompted to update artifacts
Python 3.12+
uv package manager
# Clone the repository
git clone https://github.com/l0kifs/task-context-mcp.git
cd task-context-mcp
# Install dependencies
uv sync
# Run tests
uv run pytest# Run directly
uv run python src/task_context_mcp/main.py
# Or with uv run script
uv run task-context-mcpAdd to your .cursor/mcp.json:
{
"mcpServers": {
"task-context": {
"command": "uvx",
"args": ["task-context-mcp@latest"]
}
}
}The server provides the following tools via MCP:
get_active_task_contextsGet all active task contexts in the system with their metadata.
Returns: List of active task contexts with id, summary, description, creation/update dates
create_task_contextCreate a new task context (reusable task type) with summary and description.
Parameters:
summary (string): Brief task context description (e.g., "CV Analysis for Python Developer")
description (string): Detailed task context description
Returns: Created task context information
get_artifacts_for_task_contextRetrieve all active artifacts for a specific task context.
Parameters:
task_context_id (string): ID of the task context
artifact_types (optional list): Types to retrieve ('practice', 'rule', 'prompt', 'result')
include_archived (boolean): Whether to include archived artifacts
Returns: All matching artifacts with content
create_artifactCreate a new artifact for a task context. Multiple artifacts of the same type are allowed.
Parameters:
task_context_id (string): Associated task context ID
artifact_type (string): Type ('practice', 'rule', 'prompt', 'result')
summary (string): Brief description
content (string): Full artifact content
Returns: Created artifact information
Artifact Types:
practice: Best practices and guidelines for executing the task type
rule: Specific rules and constraints to follow
prompt: Template prompts useful for the task type
result: General patterns and learnings from past work (NOT individual execution results)
update_artifactUpdate an existing artifact's summary and/or content.
Parameters:
artifact_id (string): ID of the artifact to update
summary (optional string): New summary
content (optional string): New content
Returns: Updated artifact information
archive_artifactArchive an artifact, marking it as no longer active.
Parameters:
artifact_id (string): ID of artifact to archive
reason (optional string): Reason for archiving
Returns: Archived artifact information
search_artifactsPerform full-text search across all artifacts.
Parameters:
query (string): Search query
limit (integer): Maximum results (default: 10)
Returns: Matching artifacts ranked by relevance
reflect_and_update_artifactsReflect on task execution learnings and get prompted to update artifacts autonomously.
Parameters:
task_context_id (string): ID of the task context used for this work
learnings (string): What was learned during task execution (mistakes, corrections, patterns, etc.)
Returns: Reflection summary with current artifacts and required actions
Purpose: Ensures agents autonomously manage artifacts by explicitly prompting them to create/update/archive based on their learnings
task_contexts: Task context definitions with metadata and status tracking
artifacts: Artifact storage with lifecycle management (multiple per type per context)
artifacts_fts: FTS5 virtual table for full-text search indexing
Database Migrations: The project uses Alembic for automatic schema migrations. When you modify the database models, Alembic automatically detects changes and updates the database. See docs/MIGRATIONS.md for details.
src/task_context_mcp/main.py: MCP server implementation with FastMCP
src/task_context_mcp/database/models.py: SQLAlchemy ORM models
src/task_context_mcp/database/database.py: Database operations and FTS5 management
src/task_context_mcp/database/migrations.py: Alembic migration utilities
src/task_context_mcp/config/: Configuration management with Pydantic settings
alembic/: Database migration scripts and configuration
Database: SQLite 3.35+ with FTS5 extension
ORM: SQLAlchemy 2.0+ for type-safe database operations
Migrations: Alembic 1.17+ for automatic schema migrations
MCP Framework: FastMCP for Model Context Protocol implementation
Configuration: Pydantic Settings for environment-based config
Logging: Loguru for structured, multi-level logging
Development: UV for Python package and dependency management
This implementation fulfills all requirements from docs/BRD.md:
✅ Task Context Catalog: UUID-based task context identification with metadata
✅ Artifact Storage: Lifecycle management with active/archived status, multiple per type
✅ Full-Text Search: FTS5-based search with BM25 ranking
✅ Context Loading: Automatic retrieval based on task context matching
✅ Autonomous Updates: Agent-driven improvements with feedback loops
✅ ACID Compliance: Transaction-based operations with SQLite
✅ Minimal Query Processing: Support for natural language task context matching
User Request: "Help me analyze this CV for a Python developer position"
Agent Analysis: Agent analyzes the request and identifies it as a CV analysis task type
Task Context Discovery: Agent calls get_active_task_contexts to check for existing similar contexts
Task Context Creation: No matching context found, so agent calls create_task_context with:
Summary: "CV Analysis for Python Developer"
Description: "Analyze applicant CVs for Python developer positions with specific tech stack requirements"
Context Loading: Agent calls get_artifacts_for_task_context to load any existing artifacts
Task Execution: Agent uses loaded artifacts (practices, rules, prompts) to analyze the CV
Artifact Creation: Based on learnings, agent calls create_artifact to store successful approaches
User Request: "Analyze another CV for a Python developer"
Task Context Matching: Agent calls get_active_task_contexts and finds matching context by summary/description
Context Retrieval: Agent calls get_artifacts_for_task_context with the context ID to load all relevant artifacts
Task Execution: Agent uses the loaded context (practices, rules, prompts, learnings) to analyze the new CV
Process Improvement: Agent refines artifacts based on current execution and user feedback
User Request: "Help me optimize this database query"
Search for Inspiration: Agent calls search_artifacts with keywords like "database optimization" or "query performance"
Review Results: Agent examines returned artifacts for similar past approaches
Adapt Patterns: Agent adapts successful patterns from historical artifacts to current task
Store New Artifacts: Agent creates new artifacts documenting the current successful approach
Task Completion: Agent completes a task and receives user feedback
Success Analysis: Agent analyzes whether the execution was successful
Artifact Updates:
Successful approaches: create_artifact to add new practices/rules/learnings
Refinements needed: update_artifact to improve existing artifacts
Outdated methods: archive_artifact with reason for archival
Future Benefit: Subsequent tasks of the same type automatically benefit from the improved artifacts
The server uses the following configuration (via environment variables or .env file):
TASK_CONTEXT_MCP__DATA_DIR: Data directory path (default: ./data)
TASK_CONTEXT_MCP__DATABASE_URL: Database URL (default: sqlite:///./data/task_context.db)
TASK_CONTEXT_MCP__LOGGING_LEVEL: Logging level (default: INFO)
id: Unique UUID identifier
summary: Brief task context description for matching
description: Detailed task context description
creation_date: When task context was created
updated_date: When task context was last modified
status: 'active' or 'archived'
id: Unique UUID identifier
task_context_id: Reference to associated task context
artifact_type: 'practice', 'rule', 'prompt', or 'result'
summary: Brief artifact description
content: Full artifact content
status: 'active' or 'archived'
archived_at: Timestamp when archived (if applicable)
archivation_reason: Reason for archiving
created_at: When artifact was created
Note: Multiple artifacts of the same type can exist per task context. For example, a CV analysis context might have 5 different rules, 3 practices, 2 prompts, and several learnings.
uv run pytest# Lint and format
uv run ruff check
uv run ruff format
# Type checking
uv run tyMIT License - see LICENSE file for details.
Archive an artifact that is incorrect, misleading, or outdated.
Prefer creating a replacement first, then archive the old artifact. Provide a reason when possible.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Reason for archiving the artifact (recommended) | |
| artifact_id | Yes | ID of the artifact to archive |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It mentions archiving and providing a reason but does not disclose reversibility, side effects (e.g., artifact hidden or deleted), permission requirements, or output schema 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?
Three sentences, front-loaded with the core action, followed by a best-practice guideline and a reminder. No redundant or unnecessary text.
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?
Has output schema, so return value is covered. The description effectively explains the purpose and best practice, but lacks details on the state transition (e.g., whether artifact becomes inactive). Context of sibling tools is clear.
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 has 100% coverage with descriptions for both parameters. Description adds 'Provide a reason when possible' which reinforces the schema's 'recommended' note, but does not add substantial new meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('archive') and the resource ('artifact'), and specifies it is for incorrect, misleading, or outdated artifacts. This distinguishes it from siblings like update_artifact or create_artifact.
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?
Provides actionable guidance: prefer creating a replacement before archiving. Lacks explicit when-not-to-use or comparison with alternatives like update_artifact, but the suggestion implies prioritization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new artifact to capture reusable guidance.
Create immediately when you discover a pattern, constraint, mistake, or useful template. If similar guidance might already exist, call search_artifacts() first; prefer update_artifact() over near-duplicates.
Constraints:
English only
summary <= 200 chars
content <= 4000 chars
No PII, no task-instance specifics; focus on WHAT/WHY
Types: practice (guidelines), rule (constraints), prompt (templates), result (generalizable learnings).
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Full content of the artifact - max 4000 chars, English only | |
| summary | Yes | Summary of the artifact - max 200 chars, English only | |
| artifact_type | Yes | Type of artifact: 'practice', 'rule', 'prompt', 'result' | |
| task_context_id | Yes | ID of the task context this artifact belongs to |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses constraints (English only, max lengths, no PII) and artifact types. Lacks mention of side effects or response behavior, but is generally transparent.
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?
Well-structured and front-loaded: purpose, usage guidelines, constraints, types. Every sentence is informative; 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?
Given the tool's complexity and presence of output schema, description covers all essential aspects: when to use, constraints, types. No gaps.
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%, so baseline 3. Description adds value by organizing constraints and types, though most param info is already in schema. Extra context on artifact types and usage elevates to 4.
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?
Clearly states 'Create a new artifact to capture reusable guidance.' Differentiates from siblings like search_artifacts and update_artifact by emphasizing immediate creation and preferring updates over duplicates.
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?
Explicitly advises when to create instantly and when to search first: 'If similar guidance might already exist, call search_artifacts() first; prefer update_artifact() over near-duplicates.' This is exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task context (task type) when no match exists.
Use for categories (e.g., "CV analysis for Python dev"), not specific instances.
Constraints:
English only
summary <= 200 chars
description <= 1000 chars
Next step: create initial guidance with create_artifact() before doing task work.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | Summary of the task context (task type) - max 200 chars, English only | |
| description | Yes | Detailed description of the task context - max 1000 chars, English only |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses constraints and next step but does not discuss idempotency, side effects, or error handling. Basic transparency but lacks depth for a creation tool.
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?
Description is concise: five well-structured lines covering purpose, usage, constraints, and next step. Every sentence adds value with 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?
Tool has output schema so return values need not be explained. Description covers constraints and suggested next step. However, it lacks mention of error cases or failure handling. Given low complexity (2 params), completeness is good but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds value by stating max char limits (200 for summary, 1000 for description) and 'English only' constraint, which are not in the schema. Effectively enhances parameter understanding.
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 'Create a new task context (task type) when no match exists' and explicitly differentiates from specific instances with example 'CV analysis for Python dev'. Distinguishes from sibling tools like get_active_task_contexts.
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?
Explicitly says 'when no match exists' and 'Use for categories, not specific instances'. Provides constraints (English only, char limits) and a next step to create guidance with create_artifact(). Clearly guides when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here for every task.
Lists active task contexts (reusable task TYPES, not task instances).
Next steps:
If a context matches: call get_artifacts_for_task_context(task_context_id)
If no context matches: call create_task_context(summary, description)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it lists 'active' contexts and clarifies it returns task TYPES not instances, implying a read-only operation. However, without annotations, it doesn't explicitly state it's read-only or disclose other behaviors like ordering or filtering, leaving minor gaps.
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 concise with three sentences: a starter command, the tool's function, and actionable next steps. No wasted words, each sentence adds value.
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 zero parameters and an output schema, the description covers the tool's purpose, output distinction, and usage workflow completely, enabling an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, so the schema provides full coverage. The description adds no parameter information (none needed), but it adds value by clarifying the output semantics (types vs instances), earning the baseline score of 4.
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 active task contexts (reusable task TYPES, not task instances), with a specific verb and resource, and distinguishes it from task instances and sibling tools by providing next steps.
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?
Explicitly says 'Start here for every task' and provides clear decision points: if context matches, use get_artifacts_for_task_context; if not, use create_task_context, guiding the agent on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load artifacts for a task context.
Call this after you select or create a task context and before doing work. Re-call when you start a new phase or need to confirm guidance.
Notes:
Defaults to practice/rule/prompt (excludes result)
Set include_archived=True only when you need historical context
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_types | No | Types of artifacts to retrieve (optional, defaults to all except 'result') | |
| task_context_id | Yes | ID of the task context | |
| include_archived | No | Whether to include archived artifacts |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses default artifact types and behavior of include_archived. Does not state read-only nature or error handling, but the operation is intuitively read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus bullet notes, no fluff. Information is front-loaded: purpose first, then usage sequence, then param notes. Every sentence is necessary.
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 3 parameters, no output schema explanation needed (has output schema), the description covers when to call, defaults, and key parameter behavior. Missing error scenarios, but overall sufficient for a load tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. Description adds value by clarifying default artifact_types (practice/rule/prompt, excludes result) and providing guidance on include_archived ('only when you need historical context').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Load') and resource ('artifacts for a task context'), and distinguishes the tool from siblings by focusing on loading context-specific artifacts. It further clarifies defaults and parameter usage.
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?
Explicitly states when to call (after selecting/creating task context, before work, re-call for new phases). Lacks explicit when-not-to-call or comparison with sibling tools like search_artifacts, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reflection checkpoint.
Call before declaring a task complete, and after corrections or user feedback. This returns the current artifacts and prompts you to create/update/archive as needed.
| Name | Required | Description | Default |
|---|---|---|---|
| learnings | Yes | What you learned during task execution (mistakes found, corrections made, patterns discovered, etc.) | |
| task_context_id | Yes | ID of the task context used for this work |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions returning artifacts and prompting actions, but it's ambiguous whether the tool itself modifies artifacts or only returns information. Side effects are not clearly stated.
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 clear sentences, front-loaded with the tool's purpose and usage. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return value explanation is not needed. However, the description is vague about what 'prompts' means—whether the tool initiates sub-actions or just returns suggestions. More detail on the expected behavior would improve completeness.
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%, so parameters are well documented there. The description adds context ('learnings' for what you learned) but does not significantly enhance meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a reflection checkpoint for before task completion or after feedback, and it returns artifacts and prompts actions. This distinguishes it from siblings like create_artifact or update_artifact by combining reflection with artifact management.
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?
Explicitly states when to call: 'before declaring a task complete, and after corrections or user feedback.' This provides clear usage context, though it does not list alternatives 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.
Full-text search across artifacts.
Use this before creating new artifacts to avoid duplicates. Returns results ranked by relevance.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| query | Yes | Search query |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states 'Returns results ranked by relevance' but lacks details on search scope (e.g., active artifacts only) or pagination. Adequate but not comprehensive.
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?
Three sentences with front-loaded purpose, usage guideline, and return behavior. No wasted words; every sentence serves a clear 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?
Given the presence of an output schema and sibling tools covering CRUD operations, the description is sufficiently complete. It could mention the scope of artifacts searched, but overall it provides necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes both parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline.
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 'Full-text search across artifacts' with a specific verb and resource. It distinguishes from sibling tools like create_artifact by advising use before creation to avoid duplicates.
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?
Explicitly says 'Use this before creating new artifacts to avoid duplicates,' providing a clear when-to-use scenario. While it doesn't mention when not to use, it effectively differentiates from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an artifact when existing guidance is incomplete, wrong, or needs refinement.
Use immediately when you learn something better or user feedback indicates a correction. Prefer updating over creating duplicates.
Constraints:
English only
summary <= 200 chars
content <= 4000 chars
No PII, no task-instance specifics; focus on WHAT/WHY
Provide summary and/or content.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | New content for the artifact - max 4000 chars, English only | |
| summary | No | New summary for the artifact - max 200 chars, English only | |
| artifact_id | Yes | ID of the artifact to update |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses constraints (English only, char limits, no PII), and that only summary/content can be updated. While it does not detail success response or idempotency, the output schema likely covers return values, making this adequate.
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 concise (~80 words), front-loaded with purpose, and each sentence is necessary. It uses clear structure: purpose/usage, then constraints. No redundant 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?
Given the low complexity (3 params, two optional) and presence of an output schema, the description covers purpose, usage, constraints, and parameter behavior. It lacks mention of error conditions or success confirmation, but the output schema likely fills that gap.
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%, baseline is 3. The description adds value by restating constraints and clarifying that at least one of summary or content should be provided ('Provide summary and/or content'), which is not evident from the schema alone.
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 updates an artifact when guidance is incomplete, wrong, or needs refinement. It uses a specific verb (update) and resource (artifact), and distinguishes from siblings like create_artifact by emphasizing preference for updating over creating duplicates.
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?
Provides explicit guidance: use immediately upon learning better information or user correction, and prefer updating over creating duplicates. Includes constraints and the context to focus on what/why, making it easy for the agent to decide when to invoke this tool.
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.
v1.0.0archive_artifactcreate_artifactcreate_task_contextget_active_task_contextsget_artifacts_for_task_contextreflect_and_update_artifactssearch_artifactsupdate_artifactEach tool has a clearly distinct purpose: create, update, archive, search artifacts; manage task contexts; and reflection. No overlap in functionality.
All tools follow a consistent verb_noun snake_case pattern (e.g., create_artifact, get_active_task_contexts). No mixing of conventions.
With 8 tools covering artifact lifecycle and task context management, the count is well-scoped for the server's purpose. Each tool earns its place without excess or deficiency.
The tool surface covers creation, retrieval, update, archive, search, and reflection for artifacts, plus task context creation and retrieval. Minor gaps exist, such as no explicit update or delete for task contexts, but the workflow is mostly complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared, permission-aware company context for AI agents, with provenance, approvals and audit.
Shared project context for AI agents and teams: docs, tasks, and messages that stay current.
Intelligent context infrastructure for AI teams: knowledge graph, sessions, tasks, documents.
Your team's shared, verified knowledge for AI agents: ask what's true, record what you learn.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/l0kifs/task-context-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
