PortfolioFit

Upload portfolio series rows

upload_portfolio_series_rows

Idempotent

Upload normalized series_key/date/value/distribution rows and commit a dataset version. For up to 5,000 rows, omit chunk_index and total_chunks to complete in one call. For larger inputs, declare total_chunks on every call, send chunks in order, and reuse upload_id and idempotency_key. The final chunk automatically verifies and commits all data and returns immutable series profiles. Parse files locally before calling.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "idempotency_key": "<idempotency_key>",
      "rows": "<rows>"
    },
    "name": "upload_portfolio_series_rows"
  }
}

Input Schema

Name	Required	Description
`rows`	Yes
`source`	No
`upload_id`	No
`dataset_id`	No
`chunk_index`	No	Zero-based chunk position; upload chunks in order.
`content_hash`	No
`dataset_name`	No
`portfolio_id`	No
`total_chunks`	No	Total number of chunks in this upload. The last accepted chunk commits the dataset automatically.
`analysis_name`	No	Optional private grouping name. The same case-sensitive name, after trimming outer whitespace, reuses one group for this user. Omit it for an independent operation. Keep the name on retries; each calculation still needs its own idempotency_key.
`idempotency_key`	Yes
`series_profiles`	No	Source-backed semantics for each series_key. Supply on the first or final chunk; the final chunk can complete the proposals before commit. Ambiguous or incomplete profiles require review before calculation.
`new_portfolio_name`	No

Output Schema

Name	Required	Description	Default
`status`	Yes
`row_count`	No
`upload_id`	Yes
`dataset_id`	Yes
`expires_at`	Yes
`total_rows`	Yes
`analysis_id`	Yes
`total_bytes`	Yes
`analysis_url`	Yes
`content_hash`	No
`dataset_name`	Yes
`finalized_at`	No
`portfolio_id`	Yes
`total_chunks`	Yes
`analysis_name`	Yes
`manifest_hash`	No
`chunk_replayed`	Yes
`review_required`	No
`series_profiles`	No
`next_chunk_index`	Yes
`idempotent_replay`	No
`chunk_content_hash`	Yes
`dataset_version_id`	No
`accepted_chunk_index`	Yes
`dataset_version_number`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 10, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover write/idempotent/non-destructive, and the description adds real behavioral detail on top: chunk ordering, auto-verify-and-commit on the final chunk, immutable series profiles as output, and idempotency_key/upload_id reuse across retries. It stops short of failure semantics (what happens if a mid-chunk call is retried or a chunk is out of order) and any 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.

Conciseness5/5

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

Four sentences, each doing distinct work: core action, small-payload path, chunked path, and the pre-call parsing caveat. The primary verb and resource lead the description, and nothing is repeated from the schema or annotations.

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

Completeness4/5

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

For a 13-parameter ingestion tool with an output schema, the description covers the operationally risky parts well (chunking, idempotency, commit-on-final-chunk) and does not need to restate return values. The remaining gaps are the unexplained optional identifiers (dataset_id, portfolio_id, new_portfolio_name, content_hash), which matter for correct invocation.

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

Parameters3/5

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

Schema coverage is only 31%, so the description has to carry extra weight, and it does explain chunk_index/total_chunks behavior, upload_id and idempotency_key reuse, and the row field shape. However, several parameters (content_hash, source, dataset_id vs portfolio_id vs new_portfolio_name, dataset_name) receive no explanation in either the description or the schema, leaving the agent guessing at their roles.

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 names a specific verb ('Upload') plus the exact resource shape ('normalized series_key/date/value/distribution rows') and the outcome ('commit a dataset version'), which separates it cleanly from siblings like list_portfolio_series, cancel_portfolio_series_upload, and review_portfolio_series_profile. An agent can place it without opening the schema.

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?

It gives concrete when-to-use conditions: omit chunk_index/total_chunks for up to 5,000 rows, declare total_chunks and send chunks in order for larger inputs, and reuse upload_id/idempotency_key on retries. It also implies the review path ('ambiguous or incomplete profiles require review before calculation') but never names the sibling review/cancel tools, so alternatives are left to inference.

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

All PortfolioFit tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?