Skip to main content
Glama
norman2112

Planview Portfolios Actions MCP Server

by norman2112

create_project

Create a new project in Planview Portfolios by providing a name and parent structure code. Optionally set start and finish dates, and auto-generate default tasks.

Instructions

[LOCAL — write operation. Beta MCP is read-only and cannot create projects.]

Create a new project.

Creates a project using the Planview Portfolios API. The payload should match the CreateProjectDtoPublic schema from the Swagger documentation.

Projects MUST have defined start and finish dates. If dates are not provided, default dates will be set: start date = today, finish date = 6 months from today.

Args: data: Project creation payload. Minimum required fields: - description: Project name/description (required) - parent: Object with structureCode (required) Optional fields: - scheduleStart: Start date (ISO 8601 format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS) - scheduleFinish: Finish date (ISO 8601 format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS) If not provided, defaults to today and 6 months from today respectively. attributes: Optional list of attributes to return in response create_default_tasks: If True, automatically creates 5 default sample tasks (Project Setup, Requirements Gathering, Design, Development, Testing)

Returns: Created project data from API response. The response may include warnings (e.g., "InvalidStructureCode", "InvalidDefaultValues") which are non-fatal. Projects are created successfully even with these warnings - they indicate configuration issues but don't prevent project creation.

Example: { "description": "Jon's MCP Project", "parent": {"structureCode": "14170"} }

With explicit dates:
{
    "description": "My Project",
    "parent": {"structureCode": "14170"},
    "scheduleStart": "2024-01-01",
    "scheduleFinish": "2024-06-30"
}

Notes: - See your instance's Swagger docs at {PLANVIEW_API_URL}/swagger/index.html for full schema details and additional optional fields like shortName, attributes, etc. - Warnings are non-fatal: Warnings like "InvalidStructureCode" or "InvalidDefaultValues" indicate Planview configuration issues (e.g., default region code not configured) but don't prevent successful project creation. Check response for warning details.

Note: On create, you MUST provide 'description' (project name) and 'parent' (structureCode of parent work item). Optional: scheduleStart, scheduleFinish (default to today and +6 months). For available writable fields, call list_field_reference() to browse by category: core_identity, dates, progress, status_assessments, investment_scoring, strategic_classification, wsjf_safe, risk, business_case_text, lifecycle_roles, financial_metrics, agileplace_integration, swot

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesProject creation payload (CreateProjectDtoPublic).
attributesNoOptional attributes to return (comma-separated string or list of names).
create_default_tasksNoIf true, create five default sample tasks via SOAP.
Behavior5/5

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

No annotations are provided, but the description fully compensates. It states it's a write operation, explains default date behavior, and details warning handling ('non-fatal', 'projects are created successfully even with these warnings'). It also describes the return value (created project data with possible warnings). This is comprehensive.

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 well-structured with sections (Args, Returns, Example, Notes). It front-loads key context (local write operation). However, there is slight redundancy in warning explanations appearing twice (in Returns and Notes). Overall, it is efficient for the tool's complexity but could be tightened slightly.

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 the parameter count (3), one required parameter, nested objects, and no output schema, the description is very complete. It covers input format, defaults, output behavior, warning semantics, and references external Swagger docs. Examples illustrate typical usage. No gaps are apparent.

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 schema covers all three parameters (data, attributes, create_default_tasks). The description adds significant value beyond the schema: it breaks down required vs optional fields for 'data', provides ISO 8601 format examples, explains the effect of 'create_default_tasks', and gives full JSON examples. This greatly aids correct usage.

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 the tool creates a new project using the Planview Portfolios API. It distinguishes from sibling tools like update_project or delete_project by specifying 'Create a new project' and detailing the required payload. The verb+resource pairing is specific and unambiguous.

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 explicitly mentions that Beta MCP is read-only, so this tool is for local write operations. It provides clear instructions on required fields and defaults. However, it lacks explicit guidance on when not to use this tool versus other creation tools (e.g., create_task). The non-fat warning handling is well explained.

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