Loading ToolBench
A Next.js web application that integrates Notion and Google Calendar, allowing users to view Notion database entries and sync them to Google Calendar events
This server has a web-based Next.js API architecture rather than a true MCP server. No MCP-specific tool registration, schemas, or protocol handling detected. Tools exist as HTTP endpoints with minimal schema documentation. Descriptions are present but vary in quality. Parameter validation is runtime-based in handlers rather than schema-declared. No output schemas documented. Error handling is basic. The codebase shows auth, Google Calendar, and Notion integration but lacks the structured tool definitions and LLM-facing schema clarity required for high-quality agentic tools.
Add an event to Google Calendar with title, date, and optional description, duration, and location
Check if the user is authenticated by forwarding the request to the upstream auth check endpoint
Delete an event from Google Calendar by event ID
List Google Calendar events with optional time range and result limit filters
Authenticate a user with username and password, encrypted with AES
Logout the current user by clearing authentication cookies
Query a Notion database with optional date filtering (after a specific date or today) and sorting by date property
No structured JSON Schema definitions visible in source code. Tool parameter schemas are declared as JSDoc comments or inferred from request handlers, not as formal JSON Schema. This violates the pattern:tool requirement for machine-readable, LLM-processable schemas.
No output schemas documented. The HTTP response bodies lack formal schema definitions that would tell an LLM what fields to expect. E.g., login returns { ok, ... } but structure is implicit, not declared. This violates pattern:tool-description and pattern:response-shaper.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 28 | - | v1 |
check_auth lacks input schema entirely. It takes no parameters but the schema requirement is not visible. Endpoint is GET with no query params documented in the function signature.
logout lacks input schema entirely. It is a POST with no body parameters, but the required schema structure is not declared.
delete_calendar_event has minimal error guidance. If eventId is invalid or the event doesn't exist, the error message is generic: 'Error deleting event: [message]'. No guidance on what to do next (e.g., 'Try list_calendar_events to find a valid event ID'). Violates pattern:recovery-guide.
add_calendar_event and delete_calendar_event accept destructive operations (create, delete) but lack a dry-run or confirmation mechanism. An agent could accidentally delete a calendar event without reversibility. Violates pattern:confirmation-request.
login tool exposes password parameter. Although encryption is applied server-side (encryptAES), the parameter itself is visible in logs and traces. Best practice is to accept a session or use OAuth, never raw password parameters. Violates pattern:secret-injection.
query_notion_database has an undocumented parameter 'editedAfter' that is accepted but explicitly noted as 'not currently applied'. This is confusing for LLMs, they will pass the parameter expecting it to work, then get unexpected results. Violates pattern:tool-description.
add_calendar_event description mentions 'date in YYYY-MM-DD or ISO datetime format' but does not specify what happens if both are invalid, or which format is preferred. LLMs need explicit format constraints. Violates pattern:constrained-input.
list_calendar_events maxResults parameter defaults to 50 if not provided, but this default is not documented in the schema or description. LLMs cannot infer defaults and may assume no limit. Violates pattern:tool-description.