Dataiku MCP has complete input schemas with proper types and enums for all 9 tools, and every tool has a description. However, descriptions are terse (avg ~80 chars, well below the 194-char baseline for A+ tools) and lack actionable context. Parameter descriptions are minimal, many lack format guidance, constraints, or dependency hints. Output schemas are undocumented. Error handling is present (DataikuError with status/category/retryable fields) but recovery guidance is absent. Tool naming is generic (project, dataset, recipe, job) rather than verb-first (list_projects, get_dataset, create_recipe), making intent less obvious to LLMs. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite 7 of 9 tools being WRITE operations. Composition is reasonable, tools chain via projectKey, but no batch variants or multi-step wrappers for common workflows.

• Rename tools to verb_noun pattern: 'list_projects', 'get_dataset', 'create_recipe', 'run_job', 'abort_scenario', 'set_variable', 'list_folders', 'infer_connections', 'list_code_envs'. This makes intent obvious without reading descriptions.
• Expand tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Call this to retrieve project metadata before creating datasets'), prerequisites (e.g., 'Requires DATAIKU_PROJECT_KEY env var or projectKey param'), and side effects (e.g., 'Creates a new project in Dataiku; cannot be undone').
• Document output schemas for each tool. E.g., 'Returns {projectKey, projectName, owner, createdDate, datasetCount}' so LLMs know what fields to expect and can chain calls.
• Add tool annotations: mark create/delete/run/set/abort tools with destructiveHint=true; mark list/get/infer tools with readOnlyHint=true; mark idempotent operations with idempotentHint=true.
• Add format constraints to parameter descriptions. E.g., 'projectKey: 2-10 uppercase alphanumeric characters', 'limit: integer 1-100 (default 20)', 'offset: non-negative integer (default 0)'. Include examples of valid values.