How do I use cedrus-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cedrus-mcp Start a new map: should AI be regulated?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

cedrus-mcp

by cedrus-mcp

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

CEDRUS

Reasoning scaffolding that supercharges your small AI.

CEDRUS gives a local model an argument map to think in: the model lays out claims and the reasons for and against them, and the map keeps everything in place.

A scaffold, not a scratchpad. The map records which reason answers which claim, so the model doesn't have to hold it in its head, and a small model can work through a debate that would otherwise swamp it.
Structure is checked for the model. IDs, sides and placement are worked out by the server. A move that doesn't fit is refused with an explanation, so mistakes get fixed instead of piling up.
You see the reasoning. Every step lands in a map you can read, question and extend: "add an objection to A3", "what supports A7?".
Local and private. Made for small models on your own machine, with maps saved as plain text and JSON.

What a map looks like

- C1 Legalisation of Soft Drugs
  - A1 Minimize destructive activity [con] — attacks C1
  - A2 No harm, no ban [pro] — supports C1
    - A3 Law must protect [con] — attacks A2
      - A4 Soft drugs are harmful [con] — supports A3 (also attacks A2, supports A1)
  - A5 Lifestyle decision [pro] — supports C1
    - A6 Moral leadership [con] — attacks A5
  - A7 Alcohol and tobacco analogy [pro] — supports C1
    - A8 Tobacco and alcohol more dangerous [pro] — supports A7
    - A9 Major differences [con] — attacks A7
    - A10 Poor reason [con] — undercuts A7
  - A11 Listen to society [pro] — supports C1
  - A12 Argument from addiction [con] — attacks C1
    - A13 Soft drugs are addictive [con] — supports A12
    - A14 Addiction no reason to ban [pro] — undercuts A12
  - A15 Slippery slope [con] — attacks C1
    - A16 Coffee houses [pro] — attacks A15
  - A19 Tax revenue [pro] — supports C1

This is the outline. The full view the model reads also has every claim and argument in full, and notes which ones nothing has challenged yet.

Related MCP server: deep-thinking-engine

Quick start

1. Install uv

CEDRUS is started by uv, which downloads and runs it for you.

# macOS and Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

2. Add CEDRUS to your app

Each setup below saves your maps to ~/cedrus-maps, a folder in your home directory. Use any folder you like, or leave out --save-dir and its path if you don't want files.

Whichever app you use, the model has to support tool calling.

LM Studio

In the right sidebar, open the Program tab and choose Install → Edit mcp.json. Add CEDRUS under mcpServers:

{
  "mcpServers": {
    "cedrus": {
      "command": "uvx",
      "args": ["cedrus-mcp", "--save-dir", "~/cedrus-maps"]
    }
  }
}

Jan

Go to Settings → MCP Servers, click +, and fill in:

Field	Value
Server Name	`cedrus`
Command	`uvx`
Arguments	`cedrus-mcp --save-dir ~/cedrus-maps`

For a local model, turn on tool calling in the model's settings (the edit button under Model Capabilities).

Goose

Run goose configure, choose Add Extension → Command-line Extension, name it cedrus, and give the command uvx cedrus-mcp --save-dir ~/cedrus-maps. In Goose Desktop, the same is under Extensions → Add custom extension.

Or add it to ~/.config/goose/config.yaml (%APPDATA%\Block\goose\config\config.yaml on Windows) yourself:

extensions:
  cedrus:
    name: cedrus
    type: stdio
    cmd: uvx
    args: [cedrus-mcp, --save-dir, ~/cedrus-maps]
    enabled: true
    timeout: 300

Goose can run local models through Ollama, so this is also the way to use CEDRUS with Ollama.

Other MCP clients

Any client that can start a local (stdio) MCP server works: the command is uvx, the arguments are cedrus-mcp and any options below.

Try it

Map the debate on whether cities should ban cars from their centres. Start with the main claim, then add the strongest arguments on both sides.

Now add an objection to the weakest pro argument.

Which arguments has nobody challenged yet? Add a reply to one of them.

Whenever you want to see the whole map, ask the model to show it.

Saving your maps

With --save-dir DIR, CEDRUS writes the map after every change to DIR/<id>.txt, the readable view, and DIR/<id>.json. Each time your app starts CEDRUS, it gets a new <id>, so earlier maps are kept. --save-file PATH writes to one fixed file instead, and a new session overwrites it.

When the model starts a new map, the old one is kept beside the live file as .1, then .2, and so on.

What the model can do

Tool	What it does
`show`	Print the whole map.
`add_claim`	Add a claim: the statement being debated, or a principle.
`add_argument`	Add an argument for or against something already in the map.
`link`	Relate two items already in the map, or change how they relate.
`unlink`	Remove one relation.
`edit`	Change a label or a text.
`delete`	Delete an item, optionally with the arguments that respond only to it.
`new_map`	Start over with an empty map, for another question.

An argument can support or attack what it responds to, or undercut another argument: grant its premises, but deny that they lead to its conclusion.

Options

Option	What it does
`--save-dir DIR`	Save each session's map in `DIR`. Also `CEDRUS_SAVE_DIR`.
`--save-file PATH`	Save the map to one file, `PATH` and `PATH` with `.txt`. Also `CEDRUS_SAVE_FILE`.
`--max-chars N`	Size limit for the map view, default 24000 (roughly 6k tokens). Larger maps are shown shortened.
`--hints`	Add a short hint to each tool result.

Running over HTTP, from a checkout, or under the MCP inspector is covered in docs/ADVANCED.md.

docs/ADVANCED.md: running from source, HTTP, the file format, context pruning, development.
docs/PLAN.md: the design.
Version 1 is a separate code base, tagged v1-final.

Licence

GNU Affero General Public License v3.0 or later. See LICENSE.

Available Tools

8 tools

add_argumentA

Add a new argument that responds to a claim or argument already in the map.

Args: target: The ID the argument responds to, e.g. "C1" or "A7". relation: How it responds to the target. One of: "supports" - the argument gives a reason for the target; "attacks" - the argument gives a reason against the target; "undercuts" - the argument says the target's reasons do not lead to its conclusion, without denying that those reasons are true. The target of an undercut must be an argument, not a claim. label: A short title of a few words, e.g. "Tax revenue". text: The argument written out in full.

Returns: The new ID (A1, A2, …) and the state of the map.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`label`	Yes
`target`	Yes
`relation`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It explains the operation, the important constraint that an undercut must target an argument rather than a claim, and the return value of a new ID plus map state. It does not mention validation failures or side effects beyond the obvious map mutation, but it is still substantially transparent.

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?

The description is well organized with short Args entries and a Returns line. The relation bullet list is the longest section but is necessary because it defines domain-specific semantics. There is no filler or repetition of schema content.

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?

The description covers target ID format and existence requirement, all relation values and their target constraints, label and text purpose, and the return value. Given no annotations and no schema descriptions, nothing essential for calling the tool correctly 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?

The input schema has zero description coverage, so the description fully compensates by defining each parameter with examples and enumerating all valid relation values with their meanings. This is exactly the level of detail needed for an agent to choose and fill parameters correctly.

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?

The description states a specific verb ('Add'), a specific resource ('new argument'), and the precise scoping condition ('responds to a claim or argument already in the map'). It also clearly differs from sibling tools like add_claim because it is about attaching an argument to an existing node, not creating a claim.

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?

The description makes the intended scenario clear through the phrase 'already in the map' and through the detailed relation semantics. However, it never explicitly says when to use this tool instead of alternatives such as add_claim or link, leaving some routing to inference.

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

add_claimA

Add a claim: the statement being debated, or a general principle arguments rely on.

Add a claim first; arguments need something to respond to. A claim that responds to nothing is a root claim. To make a claim support or attack something, use link afterwards.

Args: label: A short title of a few words, e.g. "Legalisation of soft drugs". text: The claim written out as one statement.

Returns: The new ID (C1, C2, …) and the state of the map.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`label`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden, and it does reveal important traits: a claim is created as a standalone node, linking is not automatic, and the call returns the new ID and full map state. It could go further by noting any constraints or failure conditions, but for a simple add operation the disclosure is solid.

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?

The description is compact, front-loaded, and each sentence adds value: purpose, sequencing, parameter semantics, and return behavior. The Args/Returns split makes it scannable.

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?

For a two-parameter, no-annotation tool, the description covers purpose, workflow position, root-claim semantics, the follow-up link tool, parameter meanings, and return values. An output schema exists, so return details are a bonus rather than a burden, and nothing needed for a correct call 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?

Schema description coverage is 0%, so the parameter documentation in the description is the only source of meaning. It explains label as a short title with a concrete example, and text as a single statement, going well beyond the raw string types in 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?

The opening sentence states a clear verb and resource: 'Add a claim' and defines what a claim is ('the statement being debated, or a general principle arguments rely on'). It also distinguishes add_claim from link and add_argument by framing claims as the things arguments respond to and support/attack links as separate follow-up steps.

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

Usage Guidelines5/5

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

The description gives explicit sequencing guidance: 'Add a claim first; arguments need something to respond to,' and tells the agent to use link afterwards for support/attack. It also clarifies the root-claim case, so the agent knows when no further linking is needed.

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

deleteA

Delete a claim or an argument, together with its relations.

The ID is never given to a new item. If some arguments respond only to this one, the deletion is refused and they are named, because they would be left with nothing to respond to.

Args: id: The ID to delete, e.g. "A7". with_replies: Set to true to delete those arguments as well.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`with_replies`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the burden and reveals important behaviors: relations are deleted, IDs are never reused, and deletion is refused with affected arguments named if they would be left with nothing to respond to. It does not state irreversibility or permissions, but it covers the main side effects and a critical failure condition.

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?

The description is compact and front-loaded with the core action, followed by a short behavior note and a clean Args section. Every sentence contributes, though the 'with_replies' explanation could be clearer.

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 description provides enough context for a moderate-complexity destructive tool: deletion scope, an edge-case refusal, ID behavior, and the flag for deleting replies. The output schema exists, so return values need not be described; a precise definition of 'relations' would make it fully 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 0%, so the description must compensate. It explains 'id' with an example ('A7') and gives a rough role for 'with_replies', but the phrase 'delete those arguments as well' is ambiguous about whether it means all replies or only the orphaned arguments mentioned in the prior sentence.

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?

The description uses a clear verb-resource pair: delete a claim or argument, and adds that relations are deleted along with it. It is distinguishable from the sibling 'unlink' by the deletion semantics, though the description does not explicitly contrast them.

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?

The conditions for use are implied: use it when an entire claim or argument needs to be removed, optionally with its replies. It does not explicitly state when to prefer a sibling such as 'unlink' for removing only a relation, and it gives no exclusion criteria.

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

editA

Change the label and/or the text of a claim or an argument.

The ID and every relation stay as they are.

Args: id: The ID to change, e.g. "A7". label: A new short title. Leave empty to keep the current one. text: A new full text. Leave empty to keep the current one.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`text`	No
`label`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It states that the ID and relations remain unchanged, which is important non-destructive context, and explains that leaving label/text empty preserves the current value. This goes beyond the bare schema and clarifies 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.

Conciseness5/5

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

The description is compact and well-organized: purpose first, then behavior, then parameter details. Every sentence adds useful information, and the Args section directly supports invocation without padding.

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?

For a simple three-parameter edit operation, the description is complete: it defines what changes, what stays the same, and how each parameter behaves. An output schema exists, so return-value details are not required, and no critical invocation information 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?

Schema description coverage is 0%, but the description compensates fully by documenting all three parameters in the Args section, including an example ID format, definitions of label and text, and the empty-string semantics. This adds substantial meaning beyond the bare 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?

The description opens with a specific verb and resource: "Change the label and/or the text of a claim or an argument." This clearly distinguishes the tool from siblings like delete, link, or add_claim, since it targets an existing entity and mutates only its content.

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 gives clear context: use this when you want to update label/text while preserving structure. The sentence "The ID and every relation stay as they are" implicitly tells the agent not to use delete/recreate, though it does not explicitly name alternative tools or state when not to use it.

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

linkA

Relate two claims or arguments that are already in the map.

Use this when one argument responds to more than one thing, or when a claim supports or attacks something. If the two are already related, this changes the relation to the new type.

Args: source: The ID that does the supporting, attacking or undercutting. relation: "supports", "attacks" or "undercuts". target: The ID being responded to.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes
`target`	Yes
`relation`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden and it discloses the key mutation: if the two are already related, the relation is changed to the new type. It does not cover failure modes like invalid IDs, but the core behavioral trait is transparent.

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?

The main purpose and usage condition are front-loaded in two short sentences, followed by a terse but complete Args block. No filler; every sentence earns its place.

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?

All parameters are explained, the overwrite behavior is disclosed, and an output schema exists, so return values need no elaboration. The only missing context is what happens on invalid source/target IDs, but this is a minor gap for a link operation.

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?

Schema coverage is 0%, and the Args section compensates fully: source is defined as the ID doing the supporting/attacking/undercutting, target as the ID being responded to, and relation enumerates exactly 'supports', 'attacks', or 'undercuts'. This adds meaning beyond the bare property titles.

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 ('Relate') and resource ('two claims or arguments that are already in the map'), which clearly separates it from node-adding siblings like add_claim and add_argument. The note about changing existing relations also separates it from unlink, providing functional differentiation without naming siblings explicitly.

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?

Explicitly provides the 'Use this when' context: one argument responds to more than one thing, or a claim supports/attacks something. It does not name alternative tools or give exclusion criteria, but the usage conditions are actionable.

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

new_mapA

Start a new, empty argument map, e.g. to map a different issue.

Only call this when you are done with the current map: it is cleared. IDs start again at C1 and A1, so IDs from the old map no longer apply.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so well: it discloses the destructive clearing behavior and the ID reset. This is exactly the kind of behavioral context an agent needs.

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, no filler. The core action is front-loaded, and the critical warning follows immediately without redundancy.

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?

For a parameterless tool with an output schema, this is complete. The agent knows what the tool does, when to call it, and what side effects to expect.

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

Parameters4/5

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

The tool has zero parameters, so parameter semantics are largely not applicable. The description still adds context by clarifying the resulting state (empty map, IDs restart), which is the baseline expected for a no-parameter tool.

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?

Description states a specific action ('Start a new, empty argument map') and its purpose ('to map a different issue'). This is clearly distinct from sibling tools like edit, add_claim, or delete.

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

Usage Guidelines5/5

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

Explicitly tells the agent when to call it: 'Only call this when you are done with the current map.' It also warns that the current map is cleared, preventing accidental data loss.

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

showA

Show the whole argument map: its claims, its arguments and all relations.

Call this whenever you need to see the current map. Its output replaces any earlier show output, so you only ever need the latest one.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the behavioral burden. It discloses a key behavior: its output replaces any earlier show output, so only the latest call matters. It could also explicitly state that it has no side effects on the map, but 'Show' reasonably implies a read-only operation.

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 short sentences, front-loaded with the core purpose and followed by a practical usage note. No wasted words.

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?

With no parameters and an output schema present, the description covers the key operational detail an agent needs: when to call it and that only the latest output matters. Nothing essential is missing.

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

Parameters4/5

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

The tool has zero parameters, so there is no parameter ambiguity to clarify. Baseline 4 applies because no parameter documentation is needed.

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?

Description clearly states the tool shows the whole argument map, its claims, arguments, and relations. This distinguishes it from the sibling mutation tools like add_claim, link, and delete.

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?

Explicitly instructs 'Call this whenever you need to see the current map,' which is direct usage guidance. It doesn't explicitly name alternatives, but the sibling set makes it clear this is the dedicated view tool.

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

unlinkA

Remove the relation that goes from source to target.

An argument must keep at least one target, so its last relation cannot be removed. A claim may lose all of its relations. To move an argument, link it to its new target first and unlink the old one afterwards.

Args: source: The ID the relation starts at. target: The ID the relation points to.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes
`target`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are present, so the description carries the behavioral disclosure burden. It does well by revealing non-obvious invariants: an argument's last relation cannot be removed, while a claim may end up with zero relations. It does not specify what error or result occurs when a forbidden removal is attempted, but the core behavioral constraints are disclosed.

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?

The description is well-structured and front-loaded: the core action appears in the first sentence, followed by important constraints and usage order, then parameter semantics. Every sentence earns its place without padding or redundancy.

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?

For a simple two-parameter removal tool, the description covers the action, parameter direction, key invariants, and the move workflow. Since an output schema exists, return-value details need not be in the description. The only notable omission is explicit handling of a forbidden last-relation removal, but this is inferable from the stated constraint.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must define the parameters, and it does. 'source: The ID the relation starts at' and 'target: The ID the relation points to' add directional meaning beyond the bare source/target property names in the schema. This is sufficient for a two-parameter tool, though it could specify expected ID types more explicitly.

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?

The description uses a specific verb and resource: 'Remove the relation that goes from source to target.' This clearly communicates the action and directed nature of the relation. It does not explicitly distinguish itself from sibling tools like link or delete, but the semantics are clear enough for an agent to tell this is the inverse of linking.

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

Usage Guidelines5/5

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

The description provides clear usage guidance: arguments cannot lose their last relation, claims can lose all relations, and for moving an argument the agent should link to the new target first then unlink the old one. This explicitly names the link alternative and the ordering needed, making when and how to use the tool clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv2.0.1Sep 18, 2026
- First observedadd_argument
- First observedadd_claim
- First observeddelete
- First observededit
- First observedlink
- First observednew_map
- First observedshow
- First observedunlink

Deploy Server

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

TDQS

A4.4/5.0

Scored 2026-09-18 15:35 across 8 tools

Disambiguation5/5

Each tool has a clearly distinct role: add_claim and add_argument create nodes, link and unlink manage relations, edit and delete mutate nodes, and show/new_map handle reading and resetting the map. There is no meaningful overlap that would cause an agent to select the wrong tool.

Naming Consistency4/5

All tool names are lowercase and imperative, and semantically grouped patterns like add_claim/add_argument and link/unlink are clear. The set is mostly consistent, though show, link, unlink, edit, and delete are verb-only while add_claim, add_argument, and new_map use a compound form, which is a minor deviation.

Tool Count5/5

Eight tools is well-scoped for an argument mapping server: creation, relation management, editing, deletion, viewing, and resetting are all covered without redundancy. Each tool earns its place in the workflow.

Completeness5/5

The tool set covers the full lifecycle of an argument map: adding claims and arguments, linking and unlinking them, editing labels/text, deleting with safety checks, displaying the map, and starting fresh. There are no obvious missing operations for the stated domain.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

MindlifyOAuth
co.mindlify
Turn AI conversations into visual knowledge maps. Create, connect, search, and organize thoughts.
Knowledge & Memory Note Taking
1
Humanity Commons B
io.github.Enrico55
Open federated knowledge network for humans and AI agents with provenance and visible disagreement.
Knowledge & Memory Open Data
611
Open Agent Polity A
io.github.societe-agents-ia-arch
Open governance for AI agents: discover live debates, deliberate, vote, follow, and invite.
Autonomous Agents
121
JAWAABOOK B
com.jawaabook
A moderated forum where AI agents read, cite and post under one house rule: claims need evidence.
91

Related MCP Servers

boardroom-mcp
Autonomous Agents Knowledge & Memory
randysalars
A
license
A
quality
C
maintenance
Multi-advisor debate, institutional memory, trust scoring, and cognitive governance for AI agents, all running locally.
Updated 7 months ago (2026-02-27 11:53 UTC)
5
28 npm
1
MIT
deep-thinking-engine
AI & Machine Learning Autonomous Agents
MitsudoAI
A
license
Not graded
quality
D
maintenance
Enables deep reasoning and cognitive enhancement through multi-agent debate, bias detection, and structured thinking, with privacy-first local execution.
Updated a year ago (2025-08-28 13:29 UTC)
1
MIT
debate-arena
Autonomous Agents Communication
dduyhai90
A
license
Not graded
quality
D
maintenance
Enables AI agents to engage in structured, turn-based debates with real-time message exchange and human moderation via a web UI.
Updated 3 months ago (2026-07-02 07:41 UTC)
MIT
Thinking Tools
Research & Data Autonomous Agents
PranayMahendrakar
A
license
Not graded
quality
C
maintenance
Provides five rigorous reasoning protocols (debate, red team, audit_argument, threat_model, check_study) that run on the AI you're already using, requiring no extra API keys or costs.
Updated 3 months ago (2026-07-15 10:56 UTC)
MIT

CEDRUS

What a map looks like

Quick start

1. Install uv

2. Add CEDRUS to your app

LM Studio

Jan

Goose

Other MCP clients

Try it

Saving your maps

What the model can do

Options

More

Licence

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers