Charter defines 4 tools with basic schemas and descriptions. All tools have input schemas with type definitions and descriptions present. However, parameter descriptions are minimal (10-30 chars), falling well below the 72-char baseline for A+ tools. Tool names follow verb_noun convention (charter_init, charter_next, charter_submit, charter_status), which is good. Critical gaps: no output schemas documented, no error recovery guidance, no parameter constraints (enums, ranges), and descriptions lack WHEN/WHY context. The 'artifact' parameter in charter_submit is typed as 'object' with no structure definition, forcing LLMs to guess valid fields. No pagination, no idempotency hints, no permission scopes declared.

• Expand parameter descriptions to 50-150 chars. For 'methodology', add: 'The delivery methodology (scrum, cicd, kanban, etc.). Determines role roster and phase sequence. Defaults to scrum if omitted.' For 'role', add: 'The role name submitting the artifact (e.g., architect, developer, qa, security). Must match a role in the current roster.'
• Document output schemas for all tools. E.g., charter_init returns {methodology: string, roles: [string], state_dir: string}. charter_next returns {role: string, contract: {description, deliverables, acceptance_criteria}, ...}. Include these in tool descriptions or a separate schema reference.
• Replace untyped 'artifact' object with a discriminated union or explicit schema. E.g., artifact: {kind: 'code'|'test'|'review'|'security', ...kind-specific fields}. Document valid kinds and required fields per role.
• Add tool annotations: charter_init and charter_submit with destructiveHint=true; charter_next and charter_status with readOnlyHint=true. This signals to agents which tools have side effects.
• Enhance error messages with recovery guidance. E.g., 'charter already exists at .charter/, call charter_status to see the current build, or delete .charter/ and retry.' instead of bare error text.