Skip to main content
Glama

Rankwise

Replace several articles

bulk_replace_articles
DestructiveIdempotent

Replace up to 50 articles in one call, with the same rules as replace_article. Each article succeeds or fails on its own; the result lists both.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
articlesYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
failedYes
replacedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so safety is covered. The description adds genuinely non-derivable behavior: partial success semantics ('each article succeeds or fails on its own') and that the result enumerates both outcomes — important for a bulk destructive call, and not present in the annotations.

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 tight sentences, front-loaded with the operation and limit, then the failure-isolation contract. No filler.

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?

An output schema exists, so return-format detail is not required, and annotations cover the safety profile. The description still needs to carry the per-item parameter semantics it currently outsources to replace_article, which is the main remaining gap.

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 0%, so the description is the only prose source, yet it tells the agent nothing about the per-item fields (article_id, html, slug, title, meta_description) beyond delegating to replace_article. It does add the 50-item bound and the array-of-articles shape, but the nested field semantics are left entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (replace articles) plus scope (up to 50 per call), and differentiates itself from the single-item sibling replace_article via the bulk framing. The deferral 'same rules as replace_article' means the agent must consult that sibling for field-level meaning, which slightly weakens standalone clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the bulk framing and the explicit 50-item cap, which distinguishes it from replace_article, but there is no explicit when-to-use / when-not guidance, no prerequisites, and no statement of what happens if more than 50 are submitted.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources