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., "@OSS 120B Autonomous Project Manager MCP analyze repo CryptoJym/oss-120b-pm-mcp"
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 that provides autonomous project management capabilities powered by the OSS 120B model. This server enables intelligent synchronization between GitHub, Notion, and Motion, with pattern recognition, self-optimization, and automated field population.
🤖 Autonomous Project Analysis - Deep analysis of GitHub repositories with health scoring
🔄 Smart Synchronization - Intelligent sync between GitHub, Notion, and Motion platforms
🧠 Pattern Recognition - Detect workflow patterns and suggest optimizations
📊 Auto Field Population - Automatically populate Notion fields from GitHub data
📈 Self-Optimization - Weekly analysis and improvement recommendations
💾 Memory Integration - Persistent learning through Mem0 integration
🎯 Prime Directive - Built-in operational guidelines for safe autonomy
Related MCP server: GitHub Project Manager MCP
# Clone the repository
git clone https://github.com/CryptoJym/oss-120b-pm-mcp.git
cd oss-120b-pm-mcp
# Run the setup script (configures both Claude Code and Cursor)
./setup-oss120b-mcp.sh# Clone and build
git clone https://github.com/CryptoJym/oss-120b-pm-mcp.git
cd oss-120b-pm-mcp
npm install
npm run build
# Configure your MCP client manually (see Configuration section)Create a .env file with your API keys:
# Required
OLLAMA_BASE_URL=http://localhost:11434
OSS_MODEL=gpt-oss:120b
MEM0_API_KEY=your_mem0_api_key
# Optional (for full functionality)
MOTION_API_KEY=your_motion_api_key
NOTION_API_KEY=your_notion_api_key
GITHUB_TOKEN=your_github_token
# Optional settings
AUTO_SYNC_ON_START=false
LOG_LEVEL=infoAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"oss-120b-pm": {
"command": "node",
"args": ["/path/to/oss-120b-pm-mcp/dist/index.js"],
"env": {
"OLLAMA_BASE_URL": "http://localhost:11434",
"OSS_MODEL": "gpt-oss:120b",
"MEM0_API_KEY": "your_mem0_api_key",
"GITHUB_TOKEN": "your_github_token",
"NOTION_API_KEY": "your_notion_api_key",
"MOTION_API_KEY": "your_motion_api_key"
}
}
}
}Add to ~/Library/Application Support/Cursor/User/mcp/config.json:
{
"mcpServers": {
"oss-120b-pm": {
"command": "node",
"args": ["/path/to/oss-120b-pm-mcp/dist/index.js"],
"env": {
"OLLAMA_BASE_URL": "http://localhost:11434",
"OSS_MODEL": "gpt-oss:120b",
"MEM0_API_KEY": "your_mem0_api_key",
"GITHUB_TOKEN": "your_github_token",
"NOTION_API_KEY": "your_notion_api_key",
"MOTION_API_KEY": "your_motion_api_key"
}
}
}
}analyze_projectAnalyze a GitHub repository and extract project information autonomously.
{
repo_owner: string, // Repository owner (username or org)
repo_name: string, // Repository name
deep_analysis?: boolean // Include README, issues, PRs analysis
}sync_projectsRun autonomous synchronization between GitHub, Notion, and Motion.
{
mode?: 'full' | 'quick' | 'changes_only', // Sync mode
dry_run?: boolean // Preview without applying
}detect_patternsDetect patterns in project management activities and suggest optimizations.
{
days_back?: number, // Number of days to analyze (default: 7)
min_confidence?: number // Minimum confidence threshold (0-1)
}populate_fieldsAutonomously populate missing Notion fields based on GitHub data.
{
project_id: string, // Notion project ID or GitHub repo full name
auto_approve?: boolean // Auto-approve high confidence suggestions
}generate_summaryGenerate daily/weekly summary report of PM activities.
{
period?: 'daily' | 'weekly' | 'custom',
start_date?: string, // ISO format for custom period
end_date?: string // ISO format for custom period
}self_optimizeRun self-optimization analysis and get improvement recommendations.
{
include_metrics?: boolean, // Include detailed performance metrics
apply_recommendations?: boolean // Automatically apply safe recommendations
}query_pmQuery the PM agent with natural language for any project management task.
{
query: string, // Natural language query
context?: object // Additional context
}get_prime_directiveRetrieve the current prime directive and operational parameters.
{
section?: 'identity' | 'capabilities' | 'boundaries' | 'patterns' | 'mcp_integration' | 'all'
}set_automation_rulesConfigure automation rules and thresholds.
{
stale_threshold_days?: number,
auto_populate_confidence?: number,
pattern_detection_frequency?: 'hourly' | 'daily' | 'weekly'
}// Analyze a repository
await mcp.call('analyze_project', {
repo_owner: 'utlyze',
repo_name: 'fcra-compliance-system',
deep_analysis: true
});// Quick sync of active projects
await mcp.call('sync_projects', {
mode: 'quick',
dry_run: false
});// Find patterns in last 2 weeks
await mcp.call('detect_patterns', {
days_back: 14,
min_confidence: 0.8
});// Get today's summary
await mcp.call('generate_summary', {
period: 'daily'
});The OSS 120B PM operates under a comprehensive prime directive that ensures:
Autonomous Actions: Updates timestamps, calculates health scores, syncs descriptions
Approval Required: Archiving projects, major status changes, budget modifications
Prohibited: Deleting data, modifying code, sharing credentials
View the full prime directive:
await mcp.call('get_prime_directive', { section: 'all' });┌─────────────────────┐
│ OSS 120B Model │
│ (Local via Ollama) │
└──────────┬──────────┘
│
┌─────┴─────┐
│ MCP Server│
└─────┬─────┘
│
┌──────┴──────┐
│ Engines │
├─────────────┤
│ • Analysis │
│ • Sync │
│ • Patterns │
│ • Memory │
└──────┬──────┘
│
┌──────┴──────┐
│ APIs │
├─────────────┤
│ • GitHub │
│ • Notion │
│ • Motion │
│ • Mem0 │
└─────────────┘# Clone the repository
git clone https://github.com/CryptoJym/oss-120b-pm-mcp.git
cd oss-120b-pm-mcp
# Install dependencies
npm install
# Run in development mode
npm run dev
# Build for production
npm run build
# Run tests
npm testNode.js >= 16.0.0
Ollama with gpt-oss:120b model installed
API keys for integrated services (GitHub, Notion, Motion, Mem0)
MIT
Contributions are welcome! Please read our contributing guidelines and submit pull requests to our repository.
For issues and feature requests, please use the GitHub issue tracker.
Analyze a GitHub repository and extract project information autonomously
| Name | Required | Description | Default |
|---|---|---|---|
| repo_name | Yes | Repository name | |
| repo_owner | Yes | Repository owner (username or org) | |
| deep_analysis | No | Perform deep analysis including README, issues, PRs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It says 'autonomously' but gives no details on actions (e.g., API calls, read-only nature), leaving ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. However, it could include more detail without harming conciseness.
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 tool with 3 parameters and no output schema, the description is too brief—does not explain what project information is extracted or how deep_analysis affects behavior.
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%, and the description adds no meaning beyond parameter names and types. 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?
The description clearly states the tool analyzes a GitHub repository and extracts project information, but does not differentiate from sibling tools like detect_patterns or generate_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings, no context on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect patterns in project management activities and suggest optimizations
| Name | Required | Description | Default |
|---|---|---|---|
| days_back | No | Number of days to analyze (default: 7) | |
| min_confidence | No | Minimum confidence threshold (0-1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the tool modifies data (read-only vs. destructive), requires specific permissions, or has side effects. The phrase 'suggest optimizations' is too vague to establish behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the primary action. However, it is too brief and omits important details, making it marginally less effective.
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?
The tool has no output schema and no annotations, yet the description does not explain return values, behavior in edge cases, or how it relates to sibling tools like 'analyze_project' and 'query_pm'. It is incomplete for confident 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?
The input schema has 100% description coverage for both parameters ('days_back' and 'min_confidence'), so the schema already provides meaning. The description does not add additional context beyond what the schema offers.
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 'Detect' and identifies the resource as 'patterns in project management activities' and mentions 'suggest optimizations'. It clearly states the tool's function, but does not differentiate it from sibling tools like 'analyze_project' which may overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate daily/weekly summary report of PM activities
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Report period | |
| end_date | No | End date for custom period (ISO format) | |
| start_date | No | Start date for custom period (ISO format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects and behavior. It only says 'generate', implying a read operation, but doesn't confirm whether it modifies data or has prerequisites. No output schema or return value description is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no extraneous information. It is appropriately concise, though it could benefit from a brief note about custom periods.
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 tool with no output schema, the description is somewhat complete but fails to mention what the summary contains or how it is delivered (e.g., text, file). It lacks return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds 'daily/weekly' context but doesn't enhance understanding of date formats or interaction between 'period' and 'start_date'/'end_date'.
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 that the tool generates a summary report of PM activities, with daily/weekly scope. However, it doesn't mention the 'custom' period option from the schema, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like 'analyze_project' or 'query_pm'. The description does not specify when to choose summary generation over other analytical tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the current prime directive and operational parameters
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Specific section to retrieve (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a safe read operation but does not provide additional behavioral details beyond the schema. Since annotations are absent, it carries the burden but is adequate for a simple retrieval.
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 concise sentence that front-loads the verb and resource. 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?
For a simple tool with one optional parameter and no output schema, the description is mostly complete. It could briefly explain what the prime directive contains, but it is adequate given the tool name.
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 the description adds no extra meaning. It does not explain how the section parameter relates to 'prime directive' or 'operational parameters'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'current prime directive and operational parameters'. It distinguishes from sibling tools like analyze_project or query_pm which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, frequency, or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Autonomously populate missing Notion fields based on GitHub data
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Notion project ID or GitHub repo full name | |
| auto_approve | No | Auto-approve high confidence suggestions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'autonomously populate', which hints at automation but does not specify whether it mutates data, requires special permissions, or handles edge cases. Important safety and behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (8 words) with no fluff. However, it may be too brief to be fully informative, earning a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and limited context, the description does not explain what 'missing fields' are, the expected return format, or error scenarios. The agent lacks sufficient information to use this tool 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for 'project_id' and 'auto_approve'. It does not explain how these parameters interact with the populate logic.
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's action ('populate'), target ('missing Notion fields'), and data source ('based on GitHub data'). It distinguishes from sibling tools like 'analyze_project' or 'sync_projects' which do not mention populating fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the PM agent with natural language for any project management task
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language query or instruction | |
| context | No | Additional context for the query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the tool queries a PM agent, but does not mention side effects, idempotency, rate limits, or action consequences. The agent cannot infer safety or 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?
The description is a single sentence, concise and front-loaded. However, it could be more informative without losing conciseness, e.g., by adding typical use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain return values, error behavior, or usage constraints. It does not, leaving significant gaps for the agent to infer.
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 both parameters described adequately. The description adds no additional semantic value beyond the schema, so baseline score of 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 queries a PM agent for project management tasks via natural language. It is specific about the action ('query') and the resource ('PM agent'), but does not differentiate from siblings like 'analyze_project' which may overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The phrase 'for any project management task' is too broad and does not specify context or exclusions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run self-optimization analysis and get improvement recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| include_metrics | No | Include detailed performance metrics | |
| apply_recommendations | No | Automatically apply safe recommendations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits, but it omits whether the tool modifies state, requires permissions, or any side effects. It only states it runs analysis.
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, efficient sentence that front-loads the core action and outcome without unnecessary 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?
Given the low complexity (two optional boolean params, no output schema), the description is minimally adequate but could benefit from context on when to apply recommendations or what metrics include.
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% and descriptions are provided for both parameters. The description adds no additional meaning beyond what the schema already conveys.
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's action ('run self-optimization analysis') and outcome ('get improvement recommendations'), making its purpose distinct from sibling tools like analyze_project or detect_patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any conditions or prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure automation rules and thresholds
| Name | Required | Description | Default |
|---|---|---|---|
| stale_threshold_days | No | Days before marking project stale | |
| auto_populate_confidence | No | Minimum confidence for auto-population | |
| pattern_detection_frequency | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral disclosure burden. It states 'Configure' but does not clarify if this is a mutation operation, if it requires specific permissions, or if changes are reversible. This lack of transparency is a gap for a tool likely altering automation state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. It is efficient with no wasted words, though it could benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It fails to explain return values, side effects, or prerequisites. For a tool with 3 parameters including an enum, more context is needed to ensure correct usage.
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 67% (2 of 3 parameters have descriptions). The tool description adds no additional meaning beyond the schema, merely summarizing the resource. Baseline 3 is appropriate as the schema provides adequate parameter info.
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 'Configure automation rules and thresholds' uses a specific verb and resource, clearly indicating the tool's purpose of setting up automation parameters. It distinguishes from sibling tools like analyze_project or detect_patterns, which focus on analysis rather than configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for configuration but provides no explicit guidance on when to use this tool versus alternatives like detect_patterns or analyze_project. No prerequisites or exclusions are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run autonomous synchronization between GitHub, Notion, and Motion
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Sync mode: full (all projects), quick (active only), changes_only (modified recently) | |
| dry_run | No | Preview changes without applying them |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose behavioral traits such as whether synchronization modifies data, requires authentication, or has side effects. 'Autonomous' is vague.
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 of 8 words is concise, but it lacks structure and front-loading of critical details. It earns a 4 for being to the point, though slightly under-specified.
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 synchronization tool across three services, the description is too sparse. It does not explain return values, scope of sync, or potential impacts, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it does not elaborate on mode meanings or dry_run behavior.
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 'Run autonomous synchronization between GitHub, Notion, and Motion' clearly states the tool's action and the three platforms involved, distinguishing it from sibling tools like analyze_project or detect_patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The description lacks context about appropriate scenarios for synchronization.
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.0analyze_projectdetect_patternsgenerate_summaryget_prime_directivepopulate_fieldsquery_pmself_optimizeset_automation_rulessync_projectsScored across 9 tools
Each tool has a distinct purpose, though 'query_pm' could overlap with specific tools like 'analyze_project' or 'generate_summary' if used broadly. Overall, boundaries are clear.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., 'analyze_project', 'sync_projects', 'set_automation_rules'. No deviations observed.
9 tools is well within the optimal range for a project management server. Each tool serves a clear function without redundancy or unnecessary expansion.
The set covers core autonomous PM activities like analysis, sync, configuration, and query. Minor gaps exist, such as no explicit tool for manual issue creation, but 'sync_projects' and 'query_pm' may address these.
AI-native project management for tasks, docs, collaboration, and agents.
AI-native project management + agent memory: tasks, sprints, risk, burnout, knowledge search.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
