repository_manager_test_projectsRuns pytest suites for specified projects in parallel, with optional live progress updates, so you can validate multiple repositories at once.
Execute pytests for the specified projects in parallel.
Args: progress_phase: Phase name for live progress updates. progress_dict: Shared mutable dict for live progress reporting.
| Name | Required | Description | Default |
|---|---|---|---|
| targets | Yes | ||
| progress_dict | No | ||
| progress_phase | No |
Changes observed during successful MCP inspections.
v3.5.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety envelope is partially covered. The description adds the parallel-execution behavior and the live-progress reporting mechanism, which aren't in the annotations, but says nothing about what running tests touches, whether failures abort the run, or how results are surfaced.
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 purpose is front-loaded in a single clear sentence with no padding, which is good. However, the space is spent on internal plumbing args and the single required input receives no coverage, so the structure is misallocated for an agent-facing tool.
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 output schema, no annotation explanation, an undocumented required parameter, and no note on how test results or failures are returned (the progress_dict hint implies in-process state an MCP caller can't meaningfully supply), the definition leaves too much unresolved for correct invocation. Also note the last case is wrong: the last tool listing does include rm_gates_run.
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 0%, so the description carries the full burden, yet the Args block documents only the two optional plumbing parameters and completely omits the one required parameter, targets. The expected shape of targets (array of objects mapping arbitrary strings to strings) is left entirely unexplained to the agent.
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 and resource (execute pytests for specified projects) and adds a distinguishing scope detail (in parallel). It does not name any sibling such as rm_gates_run or rm_projects_validate, so an agent cannot tell from the text alone when this is preferred over the other test/validate tools.
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 when-to-use guidance, no prerequisite (e.g. projects must be installed/cloned first), and no alternative named despite many sibling validation and gating tools. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.