Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@customplanview MCP server search portfolios for digital transformation"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Read-only Model Context Protocol access to Planview Portfolios Enterprise, targeting the August 2026 API version (2026-08).
The server runs over stdio and is suitable for VS Code, Claude Desktop, and the MCP Inspector.
List portfolios with pagination and an optional status filter
Get a portfolio by ID
Search portfolios by text
Forward the configured API version with every request
Keep the tool surface read-only
Related MCP server: Parseable MCP Server
Install or obtain the following before starting:
Node.js 20 or newer
Access to a Planview Portfolios Enterprise tenant
A bearer token with permission to read portfolio data
The portfolio API route used by your tenant or API gateway
Check your installations:
node --version
npm --versionFrom the project directory, run:
npm installCopy the example file:
Copy-Item .env.example .envOpen .env and set the required values:
PLANVIEW_BASE_URL=https://your-planview-tenant.example.com
PLANVIEW_API_TOKEN=replace-with-your-bearer-token
PLANVIEW_API_VERSION=2026-08
PLANVIEW_PORTFOLIOS_PATH=/api/portfoliosOptional scopes can be supplied as a comma-separated list:
PLANVIEW_SCOPES=portfolio.read,portfolio.listVariable | Required | Description |
| Yes | Base URL for your Planview tenant or API gateway. |
| Yes | Bearer token used for read-only API requests. |
| No | API version. Defaults to |
| No | Portfolio route. Defaults to |
| No | Comma-separated scopes sent to the API. |
The default portfolio path is a placeholder convention. Confirm the exact route and authentication requirements in your tenant's Planview August 2026 API documentation before connecting.
Run the TypeScript check and build the server:
npm run check
npm run buildBoth commands should complete without errors. The compiled server is written to dist/.
Run the compiled server:
npm startOr run directly from TypeScript during development:
npm run devThis is a stdio server. It does not open a web port, and stdout must remain reserved for MCP protocol messages.
The repository includes .vscode/mcp.json.
Make sure .env contains your tenant URL and token.
Open the project in VS Code.
Open the MCP view or chat tools panel.
Start planview-portfolios-enterprise.
Ask your MCP client to list, search, or retrieve portfolios.
VS Code starts the server with npm run dev and loads variables from the workspace .env file.
Tool | Inputs | Purpose |
|
| Return a page of portfolios. |
|
| Return one portfolio by identifier. |
|
| Search portfolios using the tenant's query behavior. |
All tools make GET requests. No create, update, or delete operations are exposed.
PLANVIEW_BASE_URL is requiredMake sure .env exists and contains a valid PLANVIEW_BASE_URL value.
PLANVIEW_API_TOKEN is requiredAdd a valid bearer token to .env. Do not commit or share this file.
Planview request failed (404 ...)Your tenant likely uses a different route. Update PLANVIEW_PORTFOLIOS_PATH after confirming the correct August 2026 API path.
Planview request failed (401 ...) or (403 ...)Verify that the token is active, is intended for the configured tenant, and has the required read permissions or scopes.
Run npm run build, confirm that Node.js is version 20 or newer, and restart the MCP client. For protocol-level inspection, run the server through MCP Inspector.
.env is excluded from Git by .gitignore.
Use a short-lived, least-privilege read token where possible.
Never place tokens in source code, prompts, issues, or logs.
Review tenant response shapes and pagination behavior before extending the server.
Keep new capabilities read-only unless a separate write capability is explicitly reviewed.
src/server.ts MCP server and Planview HTTP client
.vscode/mcp.json VS Code MCP launch configuration
.env.example Environment template
.github/copilot-instructions.md Project-specific development guidancenpm install # Install dependencies
npm run check # Type-check without emitting files
npm run build # Compile to dist/
npm run dev # Run TypeScript directly
npm start # Run the compiled serverPrivate application code. Add the license required by your organization before publishing.
Get one portfolio by its Planview identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| portfolioId | Yes | Planview portfolio identifier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only lookup but says nothing about permissions, error behavior when the ID is missing or invalid, rate limits, or what is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation and its lookup key.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation with full schema coverage, the description is minimally sufficient for invocation. However, with no output schema and no annotations, it leaves the return shape and failure behavior unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single portfolioId parameter is already fully documented in the schema. The description restates the identifier requirement but adds no format, syntax, or constraint details beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('one portfolio') with the lookup key ('by its Planview identifier'). This implicitly distinguishes it from the list/search siblings, but it never names them or explicitly contrasts the operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus planview_list_portfolios or planview_search_portfolios. The only implied context is that a Planview identifier must already be known, but no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List portfolios from Planview Portfolios Enterprise.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of portfolios to return. | |
| offset | No | Number of portfolios to skip. | |
| status | No | Optional tenant-defined portfolio status filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It does not state that this is a read-only operation, does not mention pagination semantics or ordering, and does not note any tenant/permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. It is efficient, though the brevity borders on under-specification rather than genuine tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should explain the return shape (list of portfolio records), pagination behavior, and how results relate to sibling tools. None of that is present, leaving the agent under-informed for a tool it must route correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (limit, offset, status) is already documented in the input schema, and the description adds no further meaning such as default page size behavior or status value syntax. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'List portfolios from Planview Portfolios Enterprise.' An agent can tell it enumerates portfolios. However, it does nothing to differentiate itself from the sibling planview_search_portfolios, which plausibly also returns portfolios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus planview_search_portfolios or planview_get_portfolio, nor any stated prerequisite or exclusion. The agent must infer the distinction purely from the tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search portfolios by a tenant-supported text query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matches to return. | |
| query | Yes | Text to search for in portfolio names or descriptions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it discloses nothing about matching semantics (substring vs token), ranking, permissions/tenant scoping, or error behavior on no matches. 'Tenant-supported' is the only behavioral hint and it is undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is efficiently sized, though it borders on under-specification rather than tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and only one descriptive sentence for a search tool. The agent is not told what a result looks like, how many fields, or how to interpret ordering, so the definition is thin for the operation's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'query' and 'limit' are already documented in the schema, establishing the baseline score of 3. The description adds nothing beyond the schema, but nothing is missing either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource ('portfolios'), scoped to a text query on names or descriptions. It is distinguishable from planview_get_portfolio (single fetch), but it never explicitly contrasts itself with planview_list_portfolios, which would be the nearest alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no mention of alternatives such as planview_list_portfolios for unfiltered enumeration. The phrase 'tenant-supported text query' hints at a constraint but does not tell the agent what that constraint means in practice or which tool to pick instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0planview_get_portfolioplanview_list_portfoliosplanview_search_portfoliosScored across 3 tools
The three tools have clearly distinct purposes: list all portfolios, get one by identifier, and search by text query. No two tools could reasonably be confused for the same operation, and the descriptions make the boundaries explicit.
All tools follow the same predictable pattern: the planview_ prefix plus verb_noun (list_portfolios, get_portfolio, search_portfolios). The convention is consistent in both prefix and snake_case style.
Three tools is a minimal but reasonable set for a portfolio-focused read surface. It is slightly under-scoped for a server named customplanview, which might be expected to cover more Planview entities.
The read surface for portfolios is fairly complete with list, get, and search, but there are no create, update, or delete operations. For a portfolio management domain, those missing lifecycle operations are a notable gap.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Model Context Protocol server for todo.vu task management and time tracking.
Query SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
Model Context Protocol server for Studex tools, notifications, and profile integrations
