pit provides 10 well-named tools with consistent verb_noun patterns (pit_create_issue, pit_list_issues, pit_get_issue, etc.). All tools have descriptions and input schemas with types. However, parameter descriptions are sparse or missing entirely, most params lack explanations of their purpose, constraints, or expected format. Output schemas are not documented. Error handling guidance is absent. The server lacks tool annotations (readOnlyHint, destructiveHint) despite clear risk classifications. Descriptions are adequate (10-50 chars) but could be more LLM-optimized. No pagination guidance in list/search tools despite accepting limit/offset.

• Add descriptions to all parameters. For each param, explain: what it controls, valid values/ranges, and expected format. E.g., 'status: Filter issues by state. Valid values: open, in-progress, closed. Omit to return all statuses.'
• Document output schemas for all tools. Specify the structure of returned objects, field types, and which fields are always present. E.g., pit_get_issue returns {id: integer, title: string, body: string, status: string, comments: [{id, body, created_at}], ...}.
• Add tool annotations to the MCP response. Mark pit_delete_issue with destructiveHint=true, pit_create_issue/pit_update_issue with idempotentHint=false (or true if idempotent), and read-only tools with readOnlyHint=true.
• Enhance error messages with recovery guidance. When a resource is not found, suggest alternatives. When a constraint is violated, state the valid options. E.g., 'Issue #42 not found. Available issues: #1, #5, #12.'
• Clarify pagination limits in descriptions. State that pit_list_issues and pit_search_issues default to limit=50 and limit=20 respectively, and explain the maximum allowed limit. Mention that results are paginated and the agent should use offset to fetch more.