MCP Toolset Design Review

[DESIGN a toolset / REVIEW my toolset] for an agent that does: [THE AGENT'S JOB, e.g. "manages our Linear tickets and posts standup summaries to Slack"]

The underlying API/system: [WHAT'S AVAILABLE: the endpoints/operations that exist]
The agent's real tasks: [5-10 CONCRETE TASKS IT WILL ACTUALLY PERFORM, e.g. "find all stale tickets assigned to X and nudge them": tools are designed backward from tasks, not forward from endpoints]
[IF REVIEWING: paste the current tool definitions]

Apply these design rules, flagging violations with their cost:
1. **Consolidate around workflows, not endpoints.** One CRUD wrapper per endpoint is the classic mistake: it forces long call chains (list_users → list_events → create_event) where one schedule_event tool should exist, and every intermediate result floods the context. For each of my listed tasks: how many tool calls does the current/proposed design need? More than ~2-3 for a routine task means consolidate.
2. **Response format control:** high-traffic tools get a response_format enum ("concise" | "detailed"), concise returns the human-meaningful fields for reasoning (names, statuses, dates), detailed adds the technical IDs needed for chained calls. Never return the raw API payload: resolve UUIDs to names, drop fields no task needs. Context is the scarce resource; a tool that returns 200 tokens where 70 carry the signal is taxing every downstream decision.
3. **Pagination and truncation with guidance:** default caps on list/search responses, and when truncating, the response TELLS the agent what to do about it ("Showing 20 of 214. Filter by [param] or paginate with [param]"): a bare truncation is a dead end the agent can't reason past.
4. **Errors that steer:** every error message is a prompt. It names what was wrong and what to try instead ("date must be YYYY-MM-DD, e.g. 2026-07-31" / "query too broad: add a project or assignee filter"). Opaque codes and stack traces make agents retry the same mistake.
5. **Namespacing:** [service]_[resource]_[action] naming so multi-server setups stay unambiguous (linear_tickets_search vs slack_messages_search), and the tool count stays curated; every tool's schema rides in every request, so shipping 40 tools makes the agent worse at picking the right 5.
6. **Descriptions as onboarding docs:** each tool's description says what it does, when to use it, when NOT to (naming the alternative), and any critical constraint; written for a new hire who can't ask follow-ups.

Deliver:
- The toolset: name | one-line purpose | key params (with formats + examples) | response shape (concise/detailed) | the tasks from my list it serves.
- Full definitions for the 3 most important tools.
- The eval plan: 10+ realistic multi-step tasks from my list, run against the toolset, measuring task completion, tool-call count, and token cost per task; then iterate on whatever the transcripts show agents fumbling.

Rules: every tool must trace to at least one of my listed tasks, a tool with no task is context tax. If my task list implies a capability the underlying API can't support, flag it now.