|
| 1 | +# Postman API & CLI MCP Server Design Document |
| 2 | + |
| 3 | +Note see `cline_task_dec-17-2024_6-25-08-pm.md` for latest discussion on the design. |
| 4 | + |
| 5 | +## 1. Overview |
| 6 | + |
| 7 | +This document outlines the design for integrating Postman CLI capabilities into the existing Postman API MCP server. The design leverages the existing API infrastructure while adding CLI-specific functionality. |
| 8 | + |
| 9 | +## 2. System Architecture |
| 10 | + |
| 11 | +### 2.1 Core Components |
| 12 | + |
| 13 | +``` |
| 14 | +postman-api-server/ |
| 15 | +├── src/ |
| 16 | +│ ├── index.ts # Entry point |
| 17 | +│ ├── server.ts # Main server implementation |
| 18 | +│ ├── types.ts # Shared type definitions |
| 19 | +│ ├── tools/ # API operation tools |
| 20 | +│ │ ├── collections.ts # Collection operations (CRUD, forking, etc.) |
| 21 | +│ │ ├── environments.ts # Environments & variables |
| 22 | +│ │ ├── users.ts # Auth & user management |
| 23 | +│ │ └── workspaces.ts |
| 24 | +│ ├── cli/ # CLI operations |
| 25 | +│ │ ├── cli-operations.ts # Main CLI functionality |
| 26 | +│ │ └── session.ts # CLI session management |
| 27 | +│ └── reporting/ # Reporting system |
| 28 | +│ ├── reporters/ |
| 29 | +│ │ ├── base.ts |
| 30 | +│ │ ├── cli.ts |
| 31 | +│ │ ├── json.ts |
| 32 | +│ │ ├── junit.ts |
| 33 | +│ │ └── html.ts |
| 34 | +│ ├── factory.ts # Reporter factory (config-based) |
| 35 | +│ └── manager.ts # Reporting logistics |
| 36 | +``` |
| 37 | + |
| 38 | + |
| 39 | +### 2.2 Key Design Decisions |
| 40 | + |
| 41 | +1. **Separation of Concerns** |
| 42 | + - API operations remain isolated in `tools/` |
| 43 | + - CLI-specific logic contained in `cli/` |
| 44 | + - Reporting system modularized in `reporting/` |
| 45 | + |
| 46 | +2. **Pattern Usage** |
| 47 | + - Factory Pattern for reporter creation |
| 48 | + - Strategy Pattern for different report types |
| 49 | + - Singleton Pattern for session management |
| 50 | + |
| 51 | +3. **Extensibility** |
| 52 | + - New reporters can be added by extending base reporter |
| 53 | + - New CLI operations can be added without modifying API tools |
| 54 | + - New report formats can be supported through factory extension |
| 55 | + |
| 56 | + |
| 57 | + |
| 58 | +### 2.3 Component Relationships |
| 59 | + |
| 60 | +```mermaid |
| 61 | +graph TD |
| 62 | + A[PostmanAPIServer] --> B[API Tools] |
| 63 | + A --> N[SDK] |
| 64 | + A --> C[CLI Operations] |
| 65 | + A --> D[Report Manager] |
| 66 | +
|
| 67 | + B --> E[Collections] |
| 68 | + B --> F[Environments] |
| 69 | + B --> G[Users] |
| 70 | + B --> H[Workspaces] |
| 71 | +
|
| 72 | + C --> B |
| 73 | + C --> D |
| 74 | + N --> B |
| 75 | +
|
| 76 | + D --> I[Reporters] |
| 77 | + I --> J[CLI Reporter] |
| 78 | + I --> K[JSON Reporter] |
| 79 | + I --> L[JUnit Reporter] |
| 80 | + I --> M[HTML Reporter] |
| 81 | +
|
| 82 | +click B call linkCallback("/Users/d/Desktop/postman-cli-design-docs.md") |
| 83 | +click N call linkCallback("/Users/d/Desktop/postman-cli-design-docs.md") |
| 84 | +click C call linkCallback("/Users/d/Desktop/postman-cli-design-docs.md") |
| 85 | +``` |
| 86 | + |
| 87 | + |
| 88 | + |
| 89 | +## 3. Core Functionality |
| 90 | + |
| 91 | +### 3.1 API Operations (Existing) |
| 92 | +```typescript |
| 93 | +interface ToolHandler { |
| 94 | + getToolDefinitions(): ToolDefinition[]; |
| 95 | + handleToolCall(name: string, args: unknown): Promise<ToolCallResponse>; |
| 96 | +} |
| 97 | + |
| 98 | +class CollectionTools implements ToolHandler { |
| 99 | + // Existing implementation for API operations |
| 100 | +} |
| 101 | +``` |
| 102 | + |
| 103 | +### 3.2 CLI Operations (New) |
| 104 | +```typescript |
| 105 | +class CLIOperations implements ToolHandler { |
| 106 | + getToolDefinitions(): ToolDefinition[] { |
| 107 | + return [ |
| 108 | + { |
| 109 | + name: 'cli_login', |
| 110 | + description: 'Authenticate with Postman API key', |
| 111 | + inputSchema: {/* schema */} |
| 112 | + }, |
| 113 | + { |
| 114 | + name: 'run_collection', |
| 115 | + description: 'Run a collection with configuration options', |
| 116 | + inputSchema: {/* schema */} |
| 117 | + }, |
| 118 | + { |
| 119 | + name: 'api_lint', |
| 120 | + description: 'Check API definitions against governance rules', |
| 121 | + inputSchema: {/* schema */} |
| 122 | + }, |
| 123 | + { |
| 124 | + name: 'publish_api', |
| 125 | + description: 'Publish an API version', |
| 126 | + inputSchema: {/* schema */} |
| 127 | + } |
| 128 | + ]; |
| 129 | + } |
| 130 | +} |
| 131 | +``` |
| 132 | + |
| 133 | +## 4. Reporting System |
| 134 | + |
| 135 | +### 4.1 Reporter Interface |
| 136 | +```typescript |
| 137 | +interface Reporter { |
| 138 | + generateReport(results: CollectionRunResult): Promise<void>; |
| 139 | +} |
| 140 | +``` |
| 141 | + |
| 142 | +### 4.2 Reporter Types and Options |
| 143 | +```typescript |
| 144 | +interface ReporterOptions { |
| 145 | + export?: string; |
| 146 | + omitRequestBodies?: boolean; |
| 147 | + omitResponseBodies?: boolean; |
| 148 | + omitHeaders?: boolean; |
| 149 | + omitAllHeadersAndBody?: boolean; |
| 150 | +} |
| 151 | + |
| 152 | +interface CliReporterOptions extends ReporterOptions { |
| 153 | + silent?: boolean; |
| 154 | + showTimestamps?: boolean; |
| 155 | + noSummary?: boolean; |
| 156 | + noFailures?: boolean; |
| 157 | + noAssertions?: boolean; |
| 158 | + noSuccessAssertions?: boolean; |
| 159 | + noConsole?: boolean; |
| 160 | + noBanner?: boolean; |
| 161 | +} |
| 162 | + |
| 163 | +interface JsonReporterOptions extends ReporterOptions { |
| 164 | + structure?: 'native' | 'newman'; |
| 165 | +} |
| 166 | +``` |
| 167 | + |
| 168 | +### 4.3 Report Management |
| 169 | +```typescript |
| 170 | +class ReportManager { |
| 171 | + constructor(config: ReportingConfiguration) { |
| 172 | + this.initializeReporters(config); |
| 173 | + } |
| 174 | + |
| 175 | + async generateReports(results: CollectionRunResult): Promise<void> { |
| 176 | + await Promise.all( |
| 177 | + this.reporters.map(reporter => reporter.generateReport(results)) |
| 178 | + ); |
| 179 | + } |
| 180 | +} |
| 181 | +``` |
| 182 | + |
| 183 | +## 5. Integration Points |
| 184 | + |
| 185 | +### 5.1 CLI to API Integration |
| 186 | +```typescript |
| 187 | +class CLIOperations { |
| 188 | + constructor( |
| 189 | + private collectionTools: CollectionTools, |
| 190 | + private environmentTools: EnvironmentTools, |
| 191 | + private reportManager: ReportManager |
| 192 | + ) {} |
| 193 | + |
| 194 | + async runCollection(args: RunCollectionArgs): Promise<void> { |
| 195 | + // 1. Use API tools to fetch resources |
| 196 | + const collection = await this.collectionTools.getCollection(args.collection); |
| 197 | + const environment = args.environment |
| 198 | + ? await this.environmentTools.getEnvironment(args.environment) |
| 199 | + : undefined; |
| 200 | + |
| 201 | + // 2. Execute collection |
| 202 | + const results = await this.executeCollection(collection, environment, args.options); |
| 203 | + |
| 204 | + // 3. Generate reports |
| 205 | + await this.reportManager.generateReports(results); |
| 206 | + } |
| 207 | +} |
| 208 | +``` |
| 209 | + |
| 210 | +### 5.2 Authentication Flow |
| 211 | +```typescript |
| 212 | +class SessionManager { |
| 213 | + async login(apiKey: string): Promise<void> { |
| 214 | + // Validate API key |
| 215 | + await this.validateApiKey(apiKey); |
| 216 | + // Store for session |
| 217 | + await this.storeCredentials(apiKey); |
| 218 | + } |
| 219 | + |
| 220 | + async logout(): Promise<void> { |
| 221 | + await this.clearCredentials(); |
| 222 | + } |
| 223 | +} |
| 224 | +``` |
| 225 | + |
| 226 | +## 6. Configuration |
| 227 | + |
| 228 | +### 6.1 Environment Variables |
| 229 | +```typescript |
| 230 | +interface ServerConfig { |
| 231 | + POSTMAN_API_KEY: string; |
| 232 | + CLI_WORKING_DIR?: string; |
| 233 | + REPORT_OUTPUT_DIR?: string; |
| 234 | +} |
| 235 | +``` |
| 236 | + |
| 237 | +### 6.2 Reporter Configuration |
| 238 | +```typescript |
| 239 | +interface ReportingConfiguration { |
| 240 | + reporters: ('cli' | 'json' | 'junit' | 'html')[]; |
| 241 | + cliOptions?: CliReporterOptions; |
| 242 | + jsonOptions?: JsonReporterOptions; |
| 243 | + junitOptions?: ReporterOptions; |
| 244 | + htmlOptions?: ReporterOptions; |
| 245 | + globalOptions?: ReporterOptions; |
| 246 | +} |
| 247 | +``` |
| 248 | + |
| 249 | +## 7. Error Handling |
| 250 | + |
| 251 | +### 7.1 Error Types |
| 252 | +```typescript |
| 253 | +enum ErrorCode { |
| 254 | + AuthenticationError = 'AUTHENTICATION_ERROR', |
| 255 | + ValidationError = 'VALIDATION_ERROR', |
| 256 | + ExecutionError = 'EXECUTION_ERROR', |
| 257 | + ReportingError = 'REPORTING_ERROR' |
| 258 | +} |
| 259 | + |
| 260 | +class PostmanError extends Error { |
| 261 | + constructor( |
| 262 | + public code: ErrorCode, |
| 263 | + message: string, |
| 264 | + public details?: unknown |
| 265 | + ) { |
| 266 | + super(message); |
| 267 | + } |
| 268 | +} |
| 269 | +``` |
| 270 | + |
| 271 | +### 7.2 Error Handling Strategy |
| 272 | +```typescript |
| 273 | +class ErrorHandler { |
| 274 | + handle(error: unknown): ToolCallResponse { |
| 275 | + if (error instanceof PostmanError) { |
| 276 | + return this.handlePostmanError(error); |
| 277 | + } |
| 278 | + if (axios.isAxiosError(error)) { |
| 279 | + return this.handleApiError(error); |
| 280 | + } |
| 281 | + return this.handleUnknownError(error); |
| 282 | + } |
| 283 | +} |
| 284 | +``` |
| 285 | + |
| 286 | +## 8. Implementation Strategy |
| 287 | + |
| 288 | +1. Phase 1: Core CLI Integration |
| 289 | + - Implement CLIOperations class |
| 290 | + - Add session management |
| 291 | + - Basic collection running |
| 292 | + |
| 293 | +2. Phase 2: Reporting System |
| 294 | + - Implement base Reporter class |
| 295 | + - Add all reporter types |
| 296 | + - Implement ReportManager |
| 297 | + |
| 298 | +3. Phase 3: Advanced Features |
| 299 | + - API governance checking |
| 300 | + - Version publishing |
| 301 | + - Advanced collection running options |
| 302 | + |
| 303 | +4. Phase 4: Testing & Documentation |
| 304 | + - Unit tests for all components |
| 305 | + - Integration tests |
| 306 | + - API documentation updates |
| 307 | + |
| 308 | +This design provides a comprehensive framework for integrating Postman CLI functionality while maintaining the existing API capabilities and ensuring clean separation of concerns. |
| 309 | + |
| 310 | +## 9. Conclusion |
| 311 | + |
| 312 | + |
| 313 | +The MCP wrapper for Postman tools makes sense primarily as an AI interaction layer for complex, multi-step operations where structure and safety are paramount. However, it may be overengineered for simple operations where direct CLI or API usage would suffice. The MCP wrapper provides most value when: |
| 314 | + |
| 315 | +1. **Complex Operations** |
| 316 | +- Managing multiple collections |
| 317 | +- Coordinating environments |
| 318 | +- Generating comprehensive reports |
| 319 | + |
| 320 | +1. **AI-Driven Automation** |
| 321 | +- Automated testing workflows |
| 322 | +- API documentation maintenance |
| 323 | +- Environment management |
| 324 | + |
| 325 | +1. **Error-Sensitive Operations** |
| 326 | +- Critical API testing |
| 327 | +- Production deployments |
| 328 | +- Compliance checking |
| 329 | + |
| 330 | +It provides less value for: |
| 331 | + |
| 332 | +1. **Simple Operations** |
| 333 | +- Basic collection runs |
| 334 | +- Single API calls |
| 335 | +- Quick environment checks |
| 336 | + |
| 337 | +2. **Direct CLI Usage** |
| 338 | +- Developer-driven operations |
| 339 | +- Local testing |
| 340 | +- Quick iterations |
0 commit comments