A lightweight collector that monitors AI agent logs in real-time and forwards events to the Devlog backend. Supports GitHub Copilot, Claude Code, Cursor, and other AI agents.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server has critical definition quality gaps. The server declares 3 tools, but only 2 have verifiable schemas visible in the provided source (health_check and ingest_events). The ws_handler tool definition appears to be inferred rather than explicitly registered in the MCP server code shown. Tool descriptions are minimal (12-97 characters) and lack LLM-optimized guidance on WHEN to use each tool or WHAT fields are returned. Parameters lack descriptions for the actual AgentEvent structure that ingest_events expects. No output schemas are documented, making it impossible for LLMs to know what fields to expect from responses. The server uses HTTP transport (good), but the tool definitions themselves are severely underdeveloped.
Tools (3)
health_checkread onlysource verified50/100
Check the health status of the collector server
ingest_eventswriteauthsource verified42/100
Ingest agent events and store them in the buffer
ws_handlerwriteauthsource verified23/100
WebSocket handler for real-time event streaming and ingestion
ws_handler tool definition is inferred, not explicitly visible in server registration code. No explicit MCP tool registration pattern found in the provided source.
ingest_events declares an 'events' parameter of type array with description 'Array of AgentEvent objects to ingest', but the AgentEvent schema itself is not documented. LLMs cannot know what fields AgentEvent requires or what their types are.
Tool descriptions are too short and lack LLM-optimized context. 'Check the health status of the collector server' (47 chars) does not explain WHEN to call this instead of other monitoring tools, or WHAT the response contains. Baseline for A+ tools is 50-200 chars with strategic context.
Recommendations
Add explicit output schemas to all 3 tools. Example for health_check: 'Returns {status: string (online|offline|degraded), uptime_seconds: number, buffer_size: number, last_event_time: ISO8601_string}'. This enables LLMs to understand what to extract from responses.
Document the full AgentEvent schema with required fields and types. Example: 'events parameter expects an array of {id: UUID, timestamp: ISO8601, agent_id: string, event_type: enum(start|step|end|error), payload: object}'. Without this, LLMs will pass malformed events.
Expand health_check description to 100-150 chars, adding context: 'Check if the collector is running and can accept events. Call this before ingest_events if recent events failed. Returns operational status and buffer capacity.'
Rename ws_handler to a verb_noun pattern like 'stream_events' or 'subscribe_to_events', and add description: 'Establish a WebSocket connection for real-time event streaming. Use when you need to push events continuously; for batch ingestion, use ingest_events instead. Returns a connection ID for managing the stream.'
Add an 'idempotent' field or annotation to each tool via toolAnnotations (currently not present). Mark ingest_events as idempotentHint=true if duplicate events are silently deduplicated, or false if they create duplicate records.
Document error cases for each tool. Example for ingest_events: 'Returns 400 if events array is empty or contains invalid AgentEvent objects. Returns 429 if buffer is full, retry after 5 seconds. Returns 500 if database write fails, this is retryable.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
ws_handler parameter 'message' has type 'object' but no schema or format guidance. The description 'WebSocket message containing AgentEvent JSON' does not specify required fields, structure, or how it differs from the events array in ingest_events.
Naming: 'ws_handler' is a transport implementation detail, not an action verb describing what happens. Should be 'stream_events' or 'subscribe_to_events' to clarify the business intent.
No indication of which tools are idempotent. ingest_events appears to append to a buffer, is it idempotent? Can the same event be ingested twice safely? This must be explicit.
ingest_events
For ws_handler, clarify parameter schema: 'message parameter must be a JSON object matching AgentEvent structure: {id, timestamp, agent_id, event_type, payload}. Invalid JSON will close the connection with error code 1002.'
Add a parameter description to the 'events' field in ingest_events: 'Array of AgentEvent objects. Each event must have: id (UUID), timestamp (ISO 8601), agent_id (string, < 256 chars), event_type (one of: start, step, end, error), payload (JSON object, max 10KB). Max 100 events per call.'
If ingest_events returns a batch response with per-event success/failure, document that structure: 'Returns {accepted: number, rejected: number[], errors: {index: string, reason: string}[]}. Use the errors array to identify which events failed and retry only those.'
Add pagination and rate-limit guidance: if health_check returns a buffer_size, explain the limit and whether ingest_events will reject calls that exceed it. Document backpressure behavior explicitly.