Loading ToolBench
YouMap MCP Server - Create interactive maps, posts, actions and manage geographic content through the YouMap platform API
YouMap MCP server has 3 tools with complete input schemas and descriptions. Tool naming follows verb_noun convention (create_map, list_maps, create_post). However, descriptions lack LLM-optimization guidance, parameters have inconsistent documentation depth, and there is no documented output schema. The create_post tool has a complex set of mutually exclusive parameters (actionId vs quickActionId) that are mentioned in the description but not formally enforced in the schema as a constraint. Error handling is present but minimal, no recovery guidance or classification by retryability. Security considerations are basic (API key injection via environment variables) but lack per-tool scope declarations and audit logging patterns.
Create a new map for a user. Maps are spaces where users can add posts, places, and organize content geographically.
Create a new post on a map. Posts are content items that users can place on maps at specific geographic locations. The post must reference EITHER a regular per-map template via `actionId` OR a global quick post template (Note / Photo / Question) via `quickActionId` — exactly one of the two is required, never both. Use `list_actions` to find per-map templates and `list_quick_post_templates` to find the global quick templates. When creating post with image, NEVER use generate_image action. Use search_image instead.
Retrieve a list of maps belonging to the authenticated user with pagination support.
create_post has undocumented mutually exclusive parameters (actionId vs quickActionId). The description mentions 'exactly one of the two is required, never both' but the JSON Schema does not enforce this constraint. LLMs will not reliably follow the text instruction without formal schema validation.
No output schemas documented for any tool. LLMs need to know what fields to expect in responses (e.g., map_id, created_at, url for create_map; maps[], total_count, next_offset for list_maps). Without documented output schemas, agents cannot plan downstream tool calls reliably.
create_post description is verbose (293 chars) and buries critical constraints. 'The post must reference EITHER...' is guidance text that belongs in a formal schema constraint, not prose. The description should focus on WHEN to use this tool and WHAT it creates, not implementation rules.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Error handling is minimal. The server catches errors and logs them but returns no structured error classification (retryable, user-fixable, fatal) or recovery guidance. An LLM receiving a generic error has no way to know whether to retry, ask the user for clarification, or stop.
No tool annotations present. Tools like create_map and create_post are write operations and should be annotated with destructiveHint or idempotentHint. list_maps is read-only and should be annotated as such. Tool annotations guide agent planning and safety.
create_map accepts optional coverImageFromUrl but the description says 'Always try to include image for map.' This is prescriptive guidance that should be a schema constraint or default behavior, not a text suggestion. LLMs may ignore prose instructions.
create_post description includes implementation detail about search_image vs generate_image ('When creating post with image, NEVER use generate_image action. Use search_image instead.'). This is a tool composition hint but assumes other tools exist and are known to the LLM. Should be a separate tool chain validation or design pattern, not embedded in the description.