Skip to main content
Glama
norman2112

Planview Portfolios Actions MCP Server

by norman2112

create_task

Create a new task in Planview Portfolios by specifying a task description and parent work entity key. Supports optional fields for schedule dates, duration, and milestone settings.

Instructions

[LOCAL — write operation via SOAP. Beta MCP cannot create tasks.]

Create a new task using SOAP TaskService.

Creates a task (planning entity below PPL) in Planview Portfolios using the SOAP API.

Args: task_data: Task data dictionary with TaskDto2 fields. Required fields: - Description: Task description (required) - FatherKey: Parent work entity key URI (required) Optional fields: - Key: External key URI (recommended to prevent duplicates) - ScheduleStartDate: Schedule start date (ISO 8601) - ScheduleFinishDate: Schedule finish date (ISO 8601) - Duration: Duration in minutes - CalendarKey: Calendar key URI - EnterProgress: Enable manual progress entry (bool) - IsMilestone: Is this a milestone (bool) - IsTicketable: Can create tickets (bool) - IsDeliverable: Is deliverable (bool) - PercentComplete: Percent complete (0-100) - WorkId: Work ID string - WorkStatusKey: Work status key URI - LifecycleAdminUserKey: Lifecycle admin user key URI - Notes: Task notes - Place: Task place/order options: Optional WorkOptionsDto dictionary: - CopyMissingValuesFromPlanview: Copy missing values from existing record (bool) - RollupActuals: Roll up actuals to parent (bool) - ClearStagingTableAfterRun: Clear staging table after run (bool, default: True)

Returns: Dict with: - success: True if operation succeeded - data: Task DTO (may have null fields - this is normal SOAP API behavior) - warnings: List of non-fatal warnings

Note: The SOAP API may return null for many fields (e.g., ScheduleStartDate, Duration)
even though the task was created successfully with those values. This is expected behavior.
Use read_task() to verify the task was created with the correct data.

Raises: PlanviewValidationError: If task data is invalid PlanviewAuthError: If authentication fails PlanviewError: For other errors

Examples: Minimal (required fields only): {"Description": "My Task", "FatherKey": "key://2/$Plan/12345"}

With external key (recommended to prevent duplicates):
    {
        "Description": "My Task",
        "FatherKey": "key://2/$Plan/12345",
        "Key": "ekey://2/namespace/task-1"
    }

With schedule dates:
    {
        "Description": "My Task",
        "FatherKey": "key://2/$Plan/12345",
        "ScheduleStartDate": "2024-01-01T08:00:00",
        "ScheduleFinishDate": "2024-01-15T17:00:00"
    }

Notes: - Field names must use PascalCase (e.g., FatherKey, not father_key) - Date format: ISO 8601 (YYYY-MM-DDTHH:MM:SS or YYYY-MM-DD) - Fields are automatically sorted alphabetically (Planview requirement) - None values are automatically filtered - Use external key (ekey://) to prevent duplicate creation

Known SOAP API Behaviors: - Response fields may be null: The SOAP API doesn't always populate all fields in the response DTO, even though the task was created successfully with those values. This is normal. The task IS created correctly in Planview - use read_task() to verify. - Warnings are non-fatal: Warnings indicate configuration issues but don't prevent creation. Check the warnings array in the response for details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
optionsNoOptional WorkOptionsDto.
task_dataYesTaskDto2 fields (Description, FatherKey, ...).
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description compensates fully by detailing behavioral traits: write operation, SOAP API null field behavior, suggestion to use read_task for verification, non-fatal warnings, field sorting, and auto-filtering of None values. It also lists error types.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with clear sections (Args, Options, Returns, etc.) and front-loaded with key purpose. Some redundancy exists (e.g., repeating 'creates a task' in multiple sentences), but overall efficient for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description thoroughly documents return values, error types, and notable behaviors (null fields, warnings). It covers the complex nested parameters and provides real-world usage context, making the tool fully understandable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds extensive meaning beyond the input schema: it lists all fields within task_data (required and optional), specifies formats (PascalCase, ISO 8601), provides examples, and notes about sorting and filtering. Schema coverage is 100% but description enriches it significantly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a task using the SOAP TaskService, specifying it is a write operation. This distinguishes it from sibling tools like read_task, batch_create_tasks, and delete_task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes usage context such as 'LOCAL — write operation' and that Beta MCP cannot create tasks, and provides examples and notes on preventing duplicates. However, it lacks explicit guidance on when to use this tool versus alternatives like batch_create_tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/norman2112/portfoliosMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server