seodraft

Merge topics

merge_topics

Destructive

Fold one topic-bank question into another when two phrasings are the same query. Both sides are named by term or topicId. Without confirm this is a dry run: same envelope, applied: false, nothing written, and plan says exactly what would move (article: move|keep-into|none, brief, metrics, metricsFilled, status). With confirm: true the survivor keeps the fresher paid brief, the measured or fresher metrics block (an estimate never overwrites measured numbers, and empty fields are filled from a measured loser instead of being dropped), the article link when only one side has one, and the most advanced status; from ends archived, never deleted. Refuses instead of losing work: article-conflict when both sides already have an article (it names both post ids; one article has to be archived first), same-topic, topic-not-found, into-archived.

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": {
      "from": "<from>",
      "into": "<into>"
    },
    "name": "merge_topics"
  }
}

Input Schema

Name	Required	Description
`from`	Yes
`into`	Yes
`confirm`	No
`workspaceId`	No	The workspace this call acts on, as listed by list_workspaces. Left out, the call uses the workspace the account is in right now.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026

addedInput schema / properties / workspaceId

Added value: +{
+  "description": "The workspace this call acts on, as listed by list_workspaces. Left out, the call uses the workspace the account is in right now.",
+  "type": "string"
+}

First observedSep 27, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations: it details dry-run semantics (same envelope, applied:false, nothing written, plan contents), the exact field-resolution rules for the survivor (fresher brief, measured-beats-estimate metrics, empty-field fill, article link, most advanced status), and that 'from' ends archived, never deleted. It also enumerates specific refusal errors (article-conflict, same-topic, topic-not-found, into-archived).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Front-loads purpose, then the dry-run behavior, then the merge resolution rules, then refusals — a sensible order. It is a single dense paragraph with heavy parenthetical nesting, and the metrics-fill detail is more granular than most callers need, so it is thorough rather than maximally tight.

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

Completeness5/5

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

There is no output schema, yet the description still defines the returned plan shape and applied flag, plus all failure modes and the archive-not-delete outcome. For a destructive, non-idempotent merge tool, nothing an agent needs to call it safely is missing.

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

Parameters5/5

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

With only 25% schema coverage, the description carries the load: it explains that 'from' and 'into' are named by term or topicId, that 'into' is the survivor and 'from' the archived side, and that 'confirm' toggles dry-run vs real write. This fully compensates for the undocumented schema properties.

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?

States a specific verb and resource ('Fold one topic-bank question into another') plus the precise condition that triggers it ('when two phrasings are the same query'). An agent can distinguish this from archive_topic or add_topics without opening any 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?

Gives a clear when-to-use condition (duplicate phrasings of the same query) and thoroughly documents the dry-run vs confirm:true workflow and the refusal conditions that block the call. It does not name sibling tools (e.g. archive_topic) as the alternative path, so routing guidance is implied rather than explicit.

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

All seodraft 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?