Point MCP Server shows solid foundational quality with 23 well-named tools, explicit descriptions for all tools and parameters, and complete JSON Schema definitions. Naming conventions are strong (all tools use verb_noun pattern: get_, list_, create_, update_, delete_, set_, replace_). Parameter descriptions are consistently present and explain constraints. However, there are moderate gaps in output schema documentation (not explicitly visible in provided code), incomplete guidance on destructive operation safety, and missing details on certain parameter constraints like enums for status/formatter fields. Tool annotations for destructive hints exist (toolAnnotations=true) which is good. The server demonstrates solid understanding of agent tool patterns but lacks some advanced composition features and detailed error recovery guidance.
Tools (23)
point_create_postwriteauthsource verified87/100
Create a new blog post with content, metadata, and optional scheduling
Add explicit enum constraints to schema for categorical parameters: status in [draft, published, scheduled, all], formatter in [markdown, html], field in [content, css, excerpt], sort in valid_sort_order_list. This prevents LLM hallucination and makes constraints machine-parseable.
Document full output schemas for all tools. Example for point_get_post: 'Returns {id: int, title: string, content: string, slug: string, status: string, tags: [object], created_at: ISO8601, ...}'. Use these to verify downstream tool parameters match.
Add dependency hints to parameter descriptions. Example: 'thumbnail_path (string), media path from point_upload_media; omit for no thumbnail' and 'tags (array of tag slugs), discover slugs with point_list_tags'.
Enhance descriptions for destructive tools with explicit irreversibility warnings and recovery hints. Example: 'Permanently deletes the post and all associated comments (cannot be undone). Consider archiving instead via point_update_post with status=draft.'
Add constraint documentation to free-form string parameters. Example: 'slug (string, 1-100 chars, lowercase alphanumerics + hyphens, unique), auto-generated from title if omitted'.
Include examples of valid parameter combinations in descriptions where dependencies exist. Example for point_replace_in_post: 'field must match post content type, use content for body text, css for styling, excerpt for summary.'
Add error response examples or recovery guidance for common failures: 'If you get 'slug already exists', append a date (post-slug-2024-12-01) or use point_list_posts to check current slugs.'
No error recovery guidance for validation failures
All write/destructive tools
Specify pagination behavior and result limits. Example: 'point_list_posts returns max 50 items per page by default; use page parameter for more results. Returns {posts: [...], total: int, page: int, per_page: int, has_more: bool}.'
Document implication of 'is_featured' and 'scheduled_at' in relation to 'status'. Example: 'is_featured only applies to published posts; scheduled_at must be future time and status must be scheduled.'
Add note about idempotency. Example: 'point_update_post is safe to retry, same input always produces same result; partial updates merge with existing fields.'
Expose immersive_mode as an enum in schema or list valid values: 'immersive layout variant (centered, full-width, dark-mode, focus-view), call point_list_themes for theme-specific variants.'
For point_replace_in_post, add validation guidance: 'allow_multiple: false (default) fails if old_string appears multiple times in field; set true to replace all occurrences. This is destructive, verify with LLM before calling.'
Document rate limits and timeout behavior for media uploads: 'Max file size: 50MB; supported types: image/jpeg, image/png, image/webp, image/gif. Large uploads may time out, consider splitting into chunks.'