Loading ToolBench

Reading the current corpus…

mcp-server MCP server · D · ToolBench

← Browse

mcp-server

github.com/imb96/mcp-server

MCP server implementation for Google Calendar integration

<=2025-11-25STDIO4 tools

50/100

Definition Quality71

Protocol Readiness47

Supportability18

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging, Dynamic Client Registration

Deprecated protocol patterns detected

Summary

Four tools with complete input schemas and basic descriptions, but significant gaps in parameter documentation and output schema specification. Tool names follow verb_noun convention (create_event, list_events, update_event, delete_event) which is good. However, parameter descriptions are minimal (e.g., 'Event title' for summary, 'Start time (ISO format)' for start_time). No output schemas documented. Error handling is present but generic. Missing tool annotations (destructiveHint for delete_event, readOnlyHint for list_events). Descriptions average ~50 chars, below the 194-char baseline for A+ tools.

Tools (4)

create_eventwriteauthsource verified72/100

Create a calendar event with specified details

delete_eventdestructiveauthsource verified68/100

Delete a calendar event

list_eventsread onlyauthsource verified72/100

List calendar events in a specified time range

update_eventwriteauthsource verified72/100

Update an existing calendar event

Issues (5)

HIGHtool ↗

Output schemas not documented. LLMs cannot plan downstream calls or extract required fields (e.g., event_id from create_event response needed for update/delete).

create_eventlist_eventsupdate_eventdelete_event

HIGHtool-description ↗

Parameter descriptions are minimal (10-20 chars). 'Event title' and 'Start time (ISO format)' lack context on format constraints, timezone handling, or when to use each parameter.

create_eventlist_eventsupdate_eventdelete_event

HIGHconfirmation-request ↗

delete_event lacks confirmation or dry-run pattern. Destructive operations should support a confirmation step to prevent accidental data loss.

delete_event

MEDIUMtool ↗

Tool annotations missing. delete_event should declare destructiveHint=true; list_events should declare readOnlyHint=true. These guide agent behavior and safety policies.

Recommendations

Document output schemas for all tools. E.g., create_event should return {event_id: string, summary: string, start_time: string, end_time: string, html_link: string} so agents can chain calls.
Expand parameter descriptions to 50-100 chars with format/constraint details. E.g., 'Start time in ISO 8601 format (e.g., 2024-01-15T09:00:00Z). Must be before end_time. Timezone: Asia/Seoul.'
Add tool annotations: destructiveHint=true for delete_event; readOnlyHint=true for list_events; idempotentHint=true for update_event (if it is).
Implement confirmation pattern for delete_event: return {status: 'confirm_required', event_id, summary, message: 'Confirm deletion of event X?'} and require a confirm_delete_event tool.
Enhance error messages with recovery guidance. E.g., 'Event not found (ID: xyz). Try list_events() to find the correct event ID.' Categorize errors: retryable (network), user-fixable (invalid ID), fatal (auth).

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

50/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	50	<=2025-11-25	v2