Multi-server MCP registry aggregating tools for GitHub PR review, Asana task management, Slack messaging, and system prompts. Used by a webhook host to process GitHub PR events and generate AI-driven reviews.
Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
This MCP server provides 11 tools across four functional areas (Asana, Slack, GitHub, and prompts). While tool naming follows verb-first conventions and schemas are generally present, there are significant gaps in description depth, parameter documentation, output schema specification, and error handling guidance. The server integrates with external APIs (Asana, Slack, GitHub) but lacks robust error handling patterns and structured output documentation. Most tools have basic descriptions (40-100 chars) that are adequate but not optimized for LLM agent selection. Parameter descriptions exist but are minimal. No evidence of output schema documentation, pagination handling, or error recovery guidance. Tool compositions chain through the host webhook server, but tool-to-tool data flow is not well-documented.
Tools (11)
asana_create_taskwriteauth50/100
Creates a new Asana task with the given name and description.
Output schemas not documented. No tool explicitly documents what fields its response contains, their types, or structure. LLMs cannot plan downstream tool usage or extract needed data for composition.
Parameter descriptions are minimal (10-30 chars). Descriptions like 'The name of the task to find' and 'The message content to post' lack context about format constraints, example values, or dependency hints.
Add explicit output schema documentation for all tools. Document return object structure, field types, and presence of chaining IDs (e.g., task_id in asana_create_task response enables downstream tool calls). Use JSDoc or OpenAPI format.
Expand parameter descriptions to 60-150 characters. Include format constraints, ranges, enums, and dependency hints. E.g., 'channel_name: Name of the Slack channel (max 80 chars, no spaces). Required; if you only have a channel ID, call get_channel_info() first.'
Add error recovery guidance to tool descriptions. E.g., asana_find_task: 'If task not found, call search_tasks_by_keyword() with partial name, or list_tasks() to see available tasks in workspace.'
Document pagination for list tools. slack_get_last_messages should document: 'Returns up to limit messages; include cursor in next call for older messages. Set limit to 100 to retrieve larger batches efficiently.'
Specify result limits in descriptions and enforce in code. Cap github_get_pull_request_files at perPage <= 100 with clear guidance: 'Limited to 100 per page for performance; use pagination to fetch all files.'
Define the pr_review_prompt 'arguments' parameter schema explicitly. Document required keys (e.g., owner, repo, pullNumber, author) and value types. Provide a helper tool or documentation showing example argument objects.
Implement confirmation or dry-run patterns for destructive tools (create_task, post_message). Add an optional 'dry_run' boolean parameter (default false) that returns 'Would create task X with description Y' without side effects.
No error handling guidance. Tools return generic HTTP responses (likely 404, 500, etc.) with no recovery hints for LLM agents. E.g., asana_find_task returns {status: 'not_found', task: null} but offers no next-step guidance like 'Try search_tasks_by_keyword()' or 'Available task IDs: ...'.
No pagination support documented. slack_get_last_messages accepts a 'limit' parameter (default 10) but no evidence of next_cursor, offset handling, or total_count return. For large Slack channels or GitHub PR reviews, agents lack guidance on iterating results.
Tool descriptions under 100 chars lack actionable context. E.g., 'Get pull request status checks' (27 chars) does not explain what 'status checks' means (CI/CD runs? Review status?), when to call it vs get_pull_request, or what data is returned. Baseline for A+ tools: 194 chars avg.
pr_review_prompt tool definition is unclear. Description 'Prompt for reviewing pull requests' (37 chars) is vague. Parameter 'arguments' typed as 'object' with description 'Dictionary of arguments to format the PR review prompt', no schema for which keys are required, expected values, or structure. LLMs cannot construct the arguments object without trial-and-error.
Destructive tools (asana_create_task, slack_post_message) lack confirmation or dry-run patterns. No evidence of pre-execution review, rollback capability, or user confirmation steps. An agent invoking create_task or post_message could execute irreversibly without safeguards.
Tool composition documentation missing. The GitHub tools proxy calls via streamablehttp_client to 'https://api.githubcopilot.com/mcp/', this external dependency and pass-through pattern is not documented. LLMs cannot understand failure modes, rate limits, or latency. tool_registry.py imports and prefixes tools but no documentation of how they interoperate.
Result limit not enforced or documented. github_get_pull_request_files accepts perPage parameter (default 100) but no cap mentioned. For large PRs or channels, agents could request unbounded data, wasting tokens and risking context window exhaustion.
Document the GitHub proxy architecture. Explain that github_* tools delegate to external MCP server; document retry behavior, rate limits, and failure modes so agents understand failure recovery.
Add tags/annotations to aid LLM tool discovery. Tools already use @annotations with readOnlyHint, expand with 'destructiveHint': true for create_task, post_message, and document tag use in prompts (e.g., 'Use tools tagged #github for PR operations').
Implement structured error responses with actionable guidance. Return {status: 'error', code: 'NOT_FOUND', message: 'Task X not found', suggestions: ['Try search_tasks_by_keyword()', 'Available task IDs: [123, 456, 789]']} instead of bare errors.
Add rate-limit headers or throttling guidance to tool descriptions. E.g., 'Slack allows ~60 messages/min; space out bulk message posts.'
Document tool interdependencies. E.g., 'Most agents follow this flow: github_get_pull_request → github_get_pull_request_diff → asana_create_task (to track review). Ensure returned IDs match downstream tool parameters.'