Orchestrates payment processing workflow: reads payment messages from Slack, verifies payments, creates Jira tasks, logs to Notion, and posts Slack confirmations. Integrates with CodeGlide MCP servers for Slack, Jira, and Notion.
The server defines 4 tools with basic descriptions, but falls well short of production quality. Tool naming is generic and lacks action verbs. Descriptions are present but minimal (10-60 chars, below the 50-200 char production baseline). Input schemas exist but are severely underspecified: no type constraints, no enums where applicable, no validation rules, and missing critical documentation. Parameters like 'fields' (createIssue) accept raw objects with no structural guidance. Error handling is absent, no recovery guidance, no categorization, no actionable error messages. The tools lack idempotency hints, permission scope declarations, and composition awareness. Critically, the 'createIssue' tool exposes a complex nested object parameter with no schema validation or documentation of required nested structure. The 'pages.create' tool similarly requires knowledge of Notion's internal property structure without guidance. No evidence of output schemas or pagination support.
Post a message to a Slack channel
Fetch latest messages from a Slack channel
Create a Jira issue for a payment receipt with project, summary, description, issue type, labels, and priority
Create a Notion database page entry with payment information including Order ID, Amount, Currency, Payer, Status, Source, Timestamp, Jira Issue reference, and Transaction ID
Complex object parameters lack schema validation and nested structure documentation. 'createIssue' requires knowledge of Jira's nested 'fields' object structure; 'pages.create' requires knowledge of Notion's property objects. No schema constraints, no examples of valid structures, no error messages for invalid nested fields.
Tool naming does not follow verb_noun convention. 'conversations.history', 'chat.postMessage', 'createIssue', and 'pages.create' use inconsistent camelCase, dot notation, or lack clear action verbs. Production baseline: 90% of A+ tools start with action verbs (get_, create_, send_, list_).
No output schemas documented for any tool. LLMs cannot plan downstream calls without knowing what fields are returned. E.g., does 'conversations.history' return message.id, message.user, message.text, message.ts? Does 'createIssue' return issue.key, issue.id, or issue.url?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
No error handling or recovery guidance. Tools do not specify what errors are retryable, user-fixable, or fatal. No guidance on how LLM should respond to 'channel not found', 'rate limit', 'permission denied', or 'invalid field' errors.
No indication of WRITE operations or idempotency. 'chat.postMessage', 'createIssue', and 'pages.create' modify state, but descriptions do not state this. No tool annotations (destructiveHint, idempotentHint) to guide LLM on retry safety.
Parameter descriptions lack validation rules and constraints. 'limit' in 'conversations.history' is a number with no bounds; production baseline requires min/max (1 - 100). Enum values like 'Currency' and 'Status' are described as 'select' but have no enum constraint list.
Generic descriptions under production baseline length. 'Post a message to a Slack channel' (33 chars) is too short; baseline range is 50 - 200 chars. Descriptions lack context on when/why to use each tool vs alternatives or what dependencies exist.
No pagination support documented. 'conversations.history' likely returns many messages, but tool definition lacks limit, offset, cursor, or total count. Production baseline: all list tools must support pagination and document limits.
Parameters accept opaque IDs (channel_id, database_id) without support for human-friendly names. Users say 'post to #payments', not 'post to C01234567'. Tool should accept channel_name as an alternative.