A Model Context Protocol (MCP) server that provides tools for interacting with Webex APIs. Supports both STDIO and HTTP modes with OAuth 2.1 authentication, streaming capabilities via Mercury, and comprehensive Webex resource management (people, messages, rooms, teams, meetings, transcripts, webhooks).
This MCP server exhibits severe definition quality gaps across nearly all 42 tools. Systematic inspection of the source code reveals: (1) NO visible input parameter schemas for ANY tool, all tool definitions are inferred from filenames and brief descriptions only; (2) Tool descriptions are minimal or missing entirely, averaging 5 - 15 characters; (3) Output schemas are not documented; (4) Parameter descriptions and type information are absent; (5) No error handling guidance. The codebase shows tool registration via function calls (e.g., tools.RegisterPeopleTools, tools.RegisterMessageTools) but the actual schema definitions are not present in the provided source excerpt. Without access to tools/*.go files showing explicit schema registration (inputSchema, description fields), tool definitions must be scored as inferred, capping individual tools at 50 and resulting in a severely depressed overall score. Even with charitable assumptions about the missing code, the visible evidence indicates a skeleton implementation lacking the rigor required for production agent use.
NO input parameter schemas visible for any of 42 tools. Schema definitions are not present in provided source code, all tools must be scored as inferred implementations.
Provide complete, explicit input schemas for all 42 tools. Each tool must have an inputSchema property with properties (name, type, description) for every parameter. Use JSON Schema Draft 7 format. Example: { "inputSchema": { "type": "object", "properties": { "user_id": { "type": "string", "description": "The unique Webex user ID. Pass the user_id returned from people_list or people_get." } }, "required": ["user_id"] } }
Write substantive tool descriptions (50 - 200 chars). Describe WHAT the tool does, WHEN to use it, and any prerequisites. Example for people_get: 'Retrieve a Webex user by ID. Returns email, display name, and avatar. Use this after people_list to get full details on a specific person. Requires the user_id from people_list output.'
Add a description to every parameter. Specify format, range, and allowed values. Example: 'The project status (one of: open, in_progress, closed). Defaults to open if omitted.' Never use example values like 'ABC123', use formal constraints (enum, pattern, minLength) instead.
Document output schemas. For list tools, specify pagination (limit, offset/cursor, total_count). Include all fields LLMs need for downstream tool calls. Example for people_list response: { "type": "object", "properties": { "items": { "type": "array", "items": { "type": "object", "properties": { "user_id": { "type": "string" }, "email": { "type": "string" }, "displayName": { "type": "string" } } } }, "total_count": { "type": "integer" }, "next_cursor": { "type": "string" } } }
Add tool annotations via mcp-go server capabilities. Use readOnlyHint for all 'get', 'list', 'transcripts' tools. Use destructiveHint for all 'delete' tools. Use idempotentHint for 'update' operations that produce identical results on replay. This enables agents to make smart retry and composition decisions.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Dynamic Client Registration (deprecated) - use Client ID Metadata Documents (CIMD)
Score history
Overall score trend
↑ 5 points across a rubric change (v1 → v2)
27/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
27
<=2025-11-25
v2
2026-03-09
F
22
-
v1
writeauth30/100
messages_createwriteauth30/100
messages_deletedestructiveauth30/100
messages_editwriteauth30/100
messages_getread onlyauth30/100
messages_listread onlyauth30/100
pagination_nextread onlyauth30/100
pagination_previousread onlyauth30/100
people_createwriteauth30/100
people_deletedestructiveauth30/100
people_getread onlyauth30/100
people_listread onlyauth30/100
people_updatewriteauth30/100
rooms_createwriteauth30/100
rooms_deletedestructiveauth30/100
rooms_getread onlyauth30/100
rooms_listread onlyauth30/100
rooms_updatewriteauth30/100
subscriberead onlyauth35/100
Subscribe to streaming events from Mercury (streaming notifications)
Tool descriptions are missing or trivially short (<20 characters). LLMs cannot determine when or why to select tools without meaningful descriptions explaining what the tool does, when to use it, and what it returns.
No parameter descriptions or type information visible. Every parameter (required and optional) must have a description explaining what it controls, its expected format, range, and allowed values. This is mandatory for LLM tool use.
No output schemas documented. Tools returning lists (people_list, messages_list, rooms_list, teams_list, memberships_list, meetings_list, transcripts_list, webhooks_list) must document pagination support, field structure, and chaining IDs. LLMs need to know what fields to expect.
Destructive tools (people_delete, messages_delete, rooms_delete, teams_delete, memberships_delete, meetings_delete, webhooks_delete) lack confirmation/dry-run support and error recovery guidance. No description explains irreversible consequences or how to recover from mistakes.
No error handling guidance visible. Tools must return actionable error messages that tell LLMs what to do next (retry, ask user, try alternative tool). Raw errors or stack traces are useless to agents.
Streaming tools (subscribe, unsubscribe, wait_for_message) lack documentation of event structure, subscription management, and expected message format. LLMs need explicit guidance on how to use these stateful operations.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. Tools must declare their risk level and mutability characteristics so agents can make informed retry and composition decisions.
Implement recovery-oriented error messages. Instead of 'Error 404' or stack traces, return: '{ "error": "User not found. Try calling people_list() with a partial name, or verify the user_id is valid (format: Y2F0ZWdvcnk...)." }' This guides LLM self-correction.
For destructive tools (delete operations), add a confirmation step. Either: (1) add a confirm parameter (boolean, defaults false) that performs a dry-run and returns what would be deleted, or (2) implement a separate tool like 'people_delete_confirm' that requires the LLM to call it after reviewing the target. Prevents accidental data loss.
Document streaming tool behavior. For subscribe: explain subscription ID format, event schema, and reconnection guarantees. For wait_for_message: specify timeout, blocking behavior, and how to handle timeouts. For unsubscribe: confirm idempotency and side effects. LLMs need explicit guidance for stateful operations.
Accept human-friendly identifiers (emails, usernames, display names) alongside Webex IDs. Update people_get, people_update, people_delete to accept either 'user_id' or 'user_email', and resolve internally. This matches chat data model where users say 'Jack' or 'jack@example.com', not 'Y2F0ZWdvcnk='.
Reduce parameter count by providing smart defaults. Example: people_list should default limit=20, status=active so simple calls work without agent reasoning. Document defaults in parameter descriptions.
Ensure tools return chaining IDs. When messages_list returns a list of messages, include room_id and team_id in each message object so agents can immediately call messages_get or rooms_update without extra lookups. Follow pattern:include-chaining-ids.
Cap result sizes. Even if the API allows 10,000 items, return max 20-50 and provide pagination. Large results blow context window and degrade reasoning. Document the limit in tool description: 'Returns up to 50 most recent messages. Use pagination_next to fetch more.'
Add batch variants for tools called in loops. Instead of requiring the LLM to call add_membership 10 times, provide 'add_memberships' accepting an array. Single call is faster, cheaper, and less error-prone than sequential calls.
Implement Multi-Round-Trip Requests (MRTR) for tools requiring user input. If subscribe needs topic confirmation, return { "result": "input_required", "required_input": { "type": "object", "properties": { "topic": { "type": "string", "enum": ["messages", "meetings", "webhooks"] } } } } instead of failing. This lets clients prompt the user mid-tool-execution.
Add rate limiting and timeout handling. Document expected latency for each tool (e.g. 'typically returns in <1s, times out after 30s'). Return clear timeout errors with retry guidance: 'Webex API timed out. This is retryable, try again in 5 seconds.'
Validate all inputs. Don't assume LLMs pass valid data. Return actionable errors: 'Invalid email: got "jack@", must be a full email address (name@domain.com).' instead of 500 errors.
For list/pagination tools, document filter and sort options. Does people_list support filtering by status or department? Does it sort by creation date or name? Document in parameter descriptions and examples.