Loading ToolBench
A local MCP server for managing Giftful lists, friends, and wishes
Strong foundation with 20 well-named tools, comprehensive schemas using Zod, and consistent tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools have descriptions (avg 95 chars) and input schemas with typed parameters. Key strengths: verb_noun naming (giftful_create_list, giftful_delete_wish), enum constraints for list types, confirmation gates on destructive ops. Weaknesses: parameter descriptions are minimal (often just 'Giftful list slug' without context on when/why to use); output schemas not formally documented; error handling returns generic error kinds without recovery guidance; no pagination metadata (total count, next_cursor) in list responses.
Check whether a persistent Giftful session exists. Set validate=true to verify it with Giftful.
Claim a wish in a Giftful list. Claiming reserves a wish inside Giftful but does not purchase it from a retailer.
Create a category in a Giftful list.
Create a wishlist, registry, or personal list for the authenticated user.
Create a wish in a Giftful list.
Delete a category from a Giftful list.
List tools (giftful_list_wishes, giftful_list_friend_lists, giftful_list_followers, giftful_list_following) accept pagination but responses do not document total count, has_more, or next_cursor. LLMs cannot determine if more results exist without explicit metadata.
Error handling returns generic error kinds (GiftfulApiError.kind) without recovery guidance. Errors like 'unauthorized' or 'not_found' do not tell the LLM what to do next (e.g., 'Call giftful_auth_status to check login').
Output schemas are not formally documented. The jsonResult() helper returns both 'content' (text) and 'structuredContent' (object), but the structure of structuredContent is not declared. LLMs cannot plan downstream tool calls without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 72 | 2025-06-18+ | v2 |
Delete a Giftful list by slug. This is permanent and cannot be undone.
Delete a wish from a Giftful list. This is permanent and cannot be undone.
Get list settings, categories, collaborators, owner, and counts by Giftful slug.
List people who follow the authenticated user. This is read-only and cannot accept, decline, remove, or otherwise change relationships.
List active Giftful accounts followed by the authenticated user. This is read-only and cannot follow or unfollow anyone.
List accessible wishlists belonging to people the authenticated user follows. Returns slugs for giftful_get_list and giftful_list_wishes.
List the authenticated user's active Giftful wishlists, registries, and personal lists.
List wishes in a Giftful list by slug with optional sorting and pagination.
Revoke the current Giftful refresh token and remove the persisted local session.
Reorder categories in a Giftful list.
Reorder wishes in a Giftful list by specifying a wish and its predecessor.
Unclaim a previously claimed wish in a Giftful list.
Patch a list's title, type, description, date, privacy, guest access, reactions, recipient, claim code, or cover. Omitted values remain unchanged.
Update a wish in a Giftful list. Omitted values remain unchanged.
Parameter descriptions are minimal and lack context. E.g., 'Giftful list slug, minimum length 1' does not explain when to use slug vs name, or how to obtain a slug. Descriptions should guide LLM selection and usage.
giftful_create_list and giftful_update_list accept optional boolean parameters (private, public_view, guest_claiming, allow_reactions) with no defaults documented. Unclear whether omitting these preserves existing values or applies API defaults.