Update multiple indexers in bulk with one request. Supply the payload containing fields to modify indexer settings.
Update Indexer.
PUT /api/v3/indexer/bulk
Args: body: Request payload. Read the matching GET or the /schema endpoint first to see the fields this resource expects.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey idempotentHint=true and destructiveHint=false. The description adds no behavioral context beyond the HTTP method and the generic body argument; it does not disclose bulk semantics, partial failure behavior, field replacement/merge behavior, or any side effects.
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 description is compact and well-structured: it front-loads the endpoint, lists the argument, and gives a one-line prerequisite. Every sentence contributes useful information without filler or repetition.
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?
The presence of an output schema and annotations reduces the burden on the description. However, the body parameter is opaque and the description does not clarify bulk scope or when to use this tool over single-resource update alternatives, leaving a notable contextual gap.
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?
The schema only documents an opaque 'body' object with additionalProperties, so coverage is 0%. The description at least labels body as the request payload and instructs the agent to inspect the matching GET or /schema endpoint to discover expected fields, which partially compensates for the missing parameter details.
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 clearly identifies the operation as an update to the indexer resource and includes the exact PUT endpoint, so the basic action is evident. However, it does not explicitly explain that this is a bulk operation or distinguish it from the sibling update_indexer_by_id tool.
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?
The description advises reading the matching GET or /schema endpoint first, which is useful preparation guidance. But it gives no guidance about when to choose this bulk update tool over update_indexer_by_id or other alternatives, and it states no exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.