Repovive MCP Server

Update problem info

repovive_build_update_problem_info

Idempotent

Update a competitive-programming draft's metadata—slug, difficulty, time limits, memory limit, and interactivity—by passing only the fields to change; unspecified values remain intact.

Instructions

Update a draft's metadata: slug, difficulty, time limit, memory limit and interactive flag. Only the arguments you pass are changed; the rest keep their current values.

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": {
      "session_id": "<session_id>"
    },
    "name": "repovive_build_update_problem_info"
  }
}

Input Schema

Name	Required	Description
`slug`	No	URL-safe slug
`difficulty`	No	'easy' \| 'medium' \| 'hard'
`session_id`	Yes	Build session id
`time_limit`	No	Time limit in seconds
`memory_limit`	No	Memory limit in MB
`is_interactive`	No	Whether the problem is interactive

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 1, 2026

TDQS

A4.2/5.0

Behavior4/5

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

The annotations already mark mutation, idempotency, and non-destructive behavior, so the description adds the crucial partial-update trait: only the arguments passed are changed, and the rest keep their current values. This is a meaningful behavioral detail beyond what the annotations provide.

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?

Two sentences front-load the operation and scope, then state the partial-update behavior. There is no filler, redundancy, or restatement of field types already in the schema.

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?

The tool is simple, has full parameter documentation, and has an output schema, so the description does not need to explain return values. It could have stated null-clearing behavior or draft/session prerequisites, but for a metadata PATCH the essential calling logic is complete.

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 description coverage is 100%, so the schema already documents slug, difficulty, time_limit, memory_limit, and is_interactive individually. The description groups them as metadata and clarifies partial application, but it does not add per-parameter meaning beyond the schema.

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?

Explicit verb 'Update', specific resource 'draft's metadata', enumerates the five fields, and indicates it operates on a build session. This clearly distinguishes it from siblings like repovive_build_update_statement and repovive_build_update_sources by identifying metadata as the target.

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 makes the intended use clear—updating metadata on a build draft—and the partial-update semantics indicate this is the tool for targeted field edits. It does not explicitly name alternatives or exclusion conditions, but within the build_* sibling cluster the scope is evident.

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

Deploy Server