A Genkit-based AI agent that integrates Slack and GitHub to manage scrum tasks. It uses Gemini 2.5 Flash as the LLM, processes Slack mentions, drafts tasks via a custom taskWriter agent, and interacts with GitHub through an MCP client to create, update, retrieve, and list issues.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server exhibits critical definition quality gaps across all dimensions. Tool schemas are entirely absent from the provided source code, no explicit input/output type definitions are visible for any of the five tools. Descriptions exist but are generic and lack LLM-optimized detail. Parameter documentation is missing. Tools are inferred to exist via string references in the chatAgent flow ('github/create_issue', etc.) rather than explicit registration with schemas. The custom taskWriterAgent tool is referenced but its implementation is not provided. Error handling guidance is minimal. No security measures (secret injection, permission gates, scope declarations) are evident in the tool layer.
Tools (5)
github/create_issuewriteauthsource verified37/100
Creates a new GitHub issue/task in the specified repository with title, description, assignee, and labels
Lists GitHub issues from a repository, used to provide context and help locate desired tasks when a specific issue_id is not provided
github/update_issuewriteauthsource verified37/100
Updates an existing GitHub issue with new details such as title, description, assignee, or labels
taskWriterAgentread onlyauth30/100
A custom AI prompt-based tool that generates draft task details (title, description, assignee, labels) for user review and revision before final creation in GitHub
No input schemas visible for any tool. Tools are referenced as strings in the chatAgent ('github/create_issue', 'github/update_issue', etc.) but their actual schema definitions are not present in the provided source. This is a CRITICAL blocker for LLM tool selection and parameter validation.
Tools are inferred via string references, not explicitly registered with schema. The source code does not show Tool/ToolDefinition registrations with name, description, and inputSchema properties. All five tools are affected.
CRITICAL: Add explicit tool registration with input schemas for all five tools. Define each as a Tool object with name, description, and inputSchema (JSON Schema) properties. Example for github/create_issue: { name: 'github/create_issue', description: '...', inputSchema: { type: 'object', properties: { owner: { type: 'string', description: '...' }, repo: { type: 'string', ... }, title: { ... }, ... }, required: [...] } }.
Add detailed parameter descriptions following the rubric baseline of 72 chars per param. For each parameter, specify: (1) what it controls, (2) expected format (string, enum, number, date), (3) constraints (min/max, allowed values, regex), (4) whether it is required or optional, (5) examples if helpful. Replace vague 'assignee' with 'GitHub username or email of the user to assign (string, required; e.g., john_doe or john@example.com)'.
Document output schemas for each tool. E.g., github/create_issue returns { issue_id: number, issue_url: string, created_at: string (ISO 8601) }. github/list_issues returns { issues: [ { issue_id, title, assignee, status }, ... ], total_count: number, has_more: boolean, next_cursor?: string }.
Enhance tool descriptions to 150 - 250 characters following the WHAT-WHEN-RETURN pattern: (1) What does the tool do? (2) When should the LLM call it? (3) What does it return? Example: 'Create a new GitHub issue in the specified repository. Use this when the user asks to create a task or bug report. Returns the issue_id and URL for reference in follow-up operations.'
Score history
Overall score trend
↑ 8 points across a rubric change (v1 → v2)
38/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
38
2025-06-18+
v2
2026-03-09
F
30
-
v1
No parameter descriptions visible. For create_issue, update_issue, get_issue, list_issues: no documentation of what title, description, assignee, labels, issue_id, repo, owner, etc. mean, what formats they accept, or constraints they have.
Tool descriptions are vague and generic. E.g., 'Creates a new GitHub issue/task in the specified repository with title, description, assignee, and labels' lacks LLM-critical detail: What is the expected format of assignee (username, email, or ID)? Are labels a comma-separated string or an array? What happens if the repo doesn't exist? Current descriptions average ~80 chars; rubric baseline for A+ tools is 194 chars with actionable WHAT, WHEN, and RETURN details.
taskWriterAgent lacks implementation visibility. Description states it 'generates draft task details' but its actual invocation, input parameters, output schema, and behavior are not present in the provided source. Cannot verify schema, error handling, or composition with other tools.
No output/response schemas documented. What does create_issue return? (issue_id only, or full issue object?) What fields does list_issues return per item, and does it support pagination? LLMs need to know what fields to expect.' Current state: no visible output schema declarations.
GitHub Personal Access Token is used as a credential, passed via environment variable. While this avoids parameter leakage, there is no evidence of scoped token use, permission verification per tool, or audit logging. This enables least-privilege agent configurations and clear audit trails.'
No input validation or sanitization visible. LLM-provided inputs (repo owner, repo name, issue_id, title, description) are not checked for injection, path traversal, or constraint violations before being passed to GitHub API. Sanitize against SQL injection, command injection, and path traversal.'
Tool naming uses enum-like prefixes (github/) but lacks verb-noun clarity for some operations. 'list_issues' is clear, but 'github/update_issue' could be clearer as 'github/update_issue_description', 'github/update_issue_status', etc. if different update verbs exist. Current baseline: 90% of A+ tools start with an action verb; these do, but descriptions of WHAT changes would help.
No idempotency hints or confirmation patterns for destructive operations. github/update_issue and github/create_issue modify state but have no dry-run, preview, or confirmation step.
github/create_issuegithub/update_issue
Add error handling guidance. Wrap tool calls in try-catch blocks that categorize errors as: (1) retryable (network timeout, rate limit), return 'Retrying in 5 seconds...', (2) user-fixable (repo not found, invalid assignee), return 'Repository owner/repo-name not found. Check spelling and permissions.', (3) fatal (auth failure), return 'Permission denied. Verify GitHub token has repo write scope.'
Declare tool permissions and scopes. Add comments or metadata for each tool indicating required GitHub scopes (repo:read, repo:write, repo:delete, etc.). Enforce least-privilege: create_issue and update_issue need repo:write; get_issue and list_issues need only repo:read.
Add input validation. Before calling GitHub API, validate: (1) repo owner/name are alphanumeric+hyphens, (2) issue_id is a positive integer, (3) assignee (if provided) matches a known username or email, (4) labels (if provided) are from a predefined set or API-backed list.
Add idempotent markers and confirmation for state-changing tools. For github/create_issue, consider accepting an optional idempotency_key parameter (UUID) so the LLM can safely retry without duplicating issues. For both create and update, return a 'dry_run_result' before actual modification if the LLM requests it.
Implement pagination support in github/list_issues. Add optional parameters: limit (1 - 100, default 20), cursor or offset. Return total_count, has_more, and next_cursor in response. Document that large result sets (>100 issues) will be capped at 100 to avoid context window exhaustion.
Add audit logging. Log every tool invocation: timestamp, calling user/agent, tool name, parameters (sanitized: omit secrets), result (success/error code). Use stderr or a structured logging system (Firebase Functions logs, as available).
Verify taskWriterAgent implementation is registered and exposed. If it is a Genkit flow or external tool, ensure it has a schema and is properly wired into the MCP server. Provide its input schema (what does it expect from the LLM?) and output schema (what does it return for draft review?).
Consider tool composition improvements. The system prompt says 'use taskWriterAgent to draft, then confirm, then github/create_issue to finalize', this works but is implicit. Consider a high-level 'create_task_with_confirmation' tool that wraps taskWriterAgent + confirmation loop + github/create_issue internally, reducing the number of back-and-forth turns.
Add per-parameter type validation hints in descriptions. Instead of 'assignee: string', write 'assignee: GitHub username (e.g., john_doe) or email (e.g., john@example.com). Required.'
Document the GitHub context (owner, repo, thread link) injection in system prompt. LLMs need to know these come from the 'context' parameter in each request. Add a note: 'The GitHub owner and repo are provided in the request context and used as defaults for all operations. To switch repos, include the new owner and repo in your request.'
Add expected HTTP status codes and error messages to tool docs. E.g., 'If the repo doesn't exist: HTTP 404 with message "Repository not found. Verify owner and repo name."'.