The operational-ontology server exposes ONE tool, createContactTask, with a complete input schema and substantive description. The tool name starts with a clear action verb (create_), the description explains WHAT it does and WHEN to use it (manufacturing window context), and the schema includes 7 parameters with types and descriptions. However, there are moderate gaps: (1) the tool description does not explicitly state it is a WRITE/state-modifying operation (critical for agents to know retry safety), (2) parameters lack format/constraint details (e.g., ISO 8601 datetime format is mentioned in description but not enforced in schema), (3) no output schema is documented, callers cannot plan downstream actions without knowing the response structure, (4) no error handling guidance, if a task already exists or the equipment is invalid, what should the agent do?, (5) the lineIds parameter requires minimum 1 element but this constraint is not visible in the schema type definition. The single tool is well-intentioned but incomplete for production use.

• Update tool description to state 'This is a WRITE operation, creates a new task record in the system. It is NOT idempotent: calling it multiple times with the same inputs will create duplicate tasks.' This tells agents the operation has state-changing consequences.
• Document the response schema. Add to the tool definition or description: 'Returns: { taskId, status, createdAt, updatedAt }' (or actual fields). This enables agents to extract task_id for downstream operations.
• Add error handling guidance to the description: 'If equipment_id is not found, returns error "EquipmentNotFound". If manufacturing window is in the past, returns "InvalidDateRange". If task_id already exists, returns "TaskAlreadyExists", use a different task_id or query existing tasks to check.'
• Enforce minimum constraints in the JSON schema: add 'minItems: 1' to lineIds array definition. Do not rely on description text alone.
• Expand datetime parameter descriptions with concrete examples: 'after: ISO 8601 datetime marking the start of the manufacturing window (e.g., 2024-01-15T09:30:00+00:00)'.
• Add a parameter description noting dependencies: 'customerId and equipmentId must both be valid identifiers in the manufacturing system. Call the ontology discovery endpoint first to list available equipment if unsure.'
• Consider whether this tool should support a dry_run parameter (e.g., dry_run=true) to let agents preview the task without committing it. This follows the confirmation-request pattern for state-modifying tools.