Loading ToolBench
Multi-service MCP server platform providing Calendar (Google Calendar) and Notion integrations with JWT authentication and HTTP transport
MCP-Nexus presents 13 tools across Calendar and Notion domains. Tool naming follows basic verb_noun conventions (crear_evento, notion_search, notion_get_page), which is appropriate. However, descriptions are brief (ranging 50-200 characters, mostly adequate), but parameter documentation is inconsistent. Schemas ARE visible for all tools and include type definitions and basic descriptions, but several critical gaps undermine usability: (1) several parameters lack explicit descriptions or constraints (e.g., 'properties' in notion_create_page is typed 'object' with minimal guidance on structure); (2) no output schemas are documented, forcing LLMs to infer response structure; (3) error handling patterns are absent, no guidance on recovery, retryability, or validation failures; (4) no confirmation mechanisms for destructive operations (delete_block should confirm before removing); (5) no pagination or result limits documented for list-like tools (notion_query_database, notion_search could return arbitrary amounts); (6) sensitive parameters (calendar_id, page_id, block_id) appear unvalidated in signatures; (7) Spanish naming ('crear_evento', 'google_resumen_diario') mixes language conventions without English aliases, complicating multi-language agent discovery. These gaps are typical of early-stage MCP servers but prevent confident production deployment.
Crea un nuevo evento.
Disponibilidad diaria: espacios libres entre eventos para una fecha dada en horario de Ecuador (GMT-5).
Resumen diario de todos los calendarios o calendario seleccionado.
Resumen semanal de todos los calendarios o calendario seleccionado.
Append child blocks to a Notion block.
Create a new page in Notion.
No output schemas documented. LLMs cannot infer response structure or plan downstream calls. E.g., notion_search returns results but schema is unspecified, does it return page IDs, titles, both? notion_create_page returns what? Without documented output, agents guess and fail.
Destructive operation (notion_delete_block) has no confirmation or dry-run support. Risk: agent deletes blocks unintentionally. Pattern: confirmation-request or result='input_required' to gate execution.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Delete a Notion block.
Retrieve child blocks of a Notion block.
Retrieve the schema/structure of a Notion database.
Retrieve a Notion page by ID.
Query a Notion database with optional filters.
Search for pages, databases, and blocks in Notion workspace.
Update properties of an existing Notion page.
Parameter 'properties' in notion_create_page and notion_update_page_properties is typed 'object' with minimal description. LLMs cannot infer required structure (e.g., {'Title': {'title': [{'text': {'content': '...'}}]}} in Notion's API). Likely cause of runtime failures.
No pagination or result limits declared for query/search tools (notion_search, notion_query_database). Large result sets will consume context, risk timeout, and dilute LLM reasoning. Missing: limit param, total_count in response, next_cursor, and documentation of default result cap.
Spanish tool names ('crear_evento', 'google_resumen_diario', 'google_resumen_semanal', 'google_disponibilidad_diaria') conflict with English tooling conventions. LLM agent discovery and routing may fail or be ambiguous across multi-language systems. Recommend English aliases or standardization.
No error handling guidance. Tools provide no actionable recovery hints. E.g., 'calendar_id not found' vs 'Calendar ID not found. Try list_calendars() first.' Agents cannot self-correct without extra discovery.
Parameter descriptions lack constraints. E.g., 'start_time' and 'end_time' in crear_evento documented as 'ISO format' but no pattern or validation rules. LLMs may submit malformed dates (2025-13-01, etc.). Descriptions should include format pattern and example.
Parameter 'blocks' in notion_append_block_children is typed 'array' with description 'List of block objects' but no schema for individual block structure. Notion's block format is complex; LLMs will guess and fail. Provide example or JSON Schema for block objects.
Optional parameters not clearly marked. E.g., 'calendar_id' in google_resumen_diario is documented 'Optional' but not strictly required in schema. Inconsistent boolean(required) vs. description text. Standardize on JSON Schema 'required' field.
No resource resolution for human-friendly names. E.g., crear_evento requires 'calendar_id' (opaque) but users say 'send to my work calendar'. No lookup tool exists for calendar names → IDs. Agents will fail without extra discovery step.