JobMojito

Dismiss a possible duplicate

dismiss_candidate_duplicate

DestructiveIdempotent

[Candidates] Mark a suggested duplicate pair (duplicate_id from get_candidate include=duplicates) as not the same person, with an optional note. Nobody is notified, and no tool undoes a dismissal.

Every argument in full, with examples: get_tool_reference.

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": {
      "duplicate_id": "<duplicate_id>"
    },
    "name": "dismiss_candidate_duplicate"
  }
}

Input Schema

Name	Required	Description
`note`	No	Why the two records are different people; kept with the decision (at most 2000 characters).
`llm_model`	No	Your model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
`duplicate_id`	Yes	Duplicate pair id (a duplicate pair `id` from get_candidate include=duplicates), from the candidate's duplicates.
`conversation_id`	No	The conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.

Output Schema

Name	Required	Description
`note`	No
`status`	Yes
`decided_at`	No
`duplicate_id`	Yes
`_mcp_instructions`	No	Server-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedInput schema / properties / duplicate_id / description

Previous value: -"Duplicate pair id (profile_interview_duplicate.id), from the candidate's duplicates."New value: +"Duplicate pair id (a duplicate pair `id` from get_candidate include=duplicates), from the candidate's duplicates."

Changed6 schema fields changedNov 9, 2026

addedInput schema / properties / llm_model

Added value: +{
+  "description": "Your model id, e.g. \"claude-opus-4-8\"; \"unknown\" if unsure. For analytics.",
+  "type": "string"
+}

removedInput schema / properties / note / example

Removed value: -"Same name, different people: different dates of birth."

removedOutput schema / properties / decided_at / description

Removed value: -"When the pair was dismissed (ISO 8601); the first dismissal is kept."

removedOutput schema / properties / duplicate_id / description

Removed value: -"Duplicate pair id (profile_interview_duplicate.id)."

removedOutput schema / properties / note / description
```
Removed value: -"The note kept with the decision."
```

removedOutput schema / properties / status / description

Removed value: -"The pair's status: dismissed (never re-opened by later scans)."

AddedNov 8, 2026

TDQS

A4.1/5.0

Behavior4/5

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

The annotations already flag destructiveHint=true, idempotentHint=true, and readOnlyHint=false; the description adds genuinely new information: nobody is notified and no tool undoes a dismissal, so the action is irreversible. It also notes the note is kept with the decision. It does not describe any permission requirements or what the return value confirms, but the output schema covers the latter.

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 core action and the two critical behavioral facts (silent, irreversible) are front-loaded in one efficient sentence. The trailing pointer to get_tool_reference for full argument examples is not strictly necessary but is short and harmless.

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 an irreversible mutation with a full output schema and annotation coverage, the description supplies the missing decision-critical facts: silent to others, no undo, and the pair id's origin. Only a mention of required permissions or the resulting state change would add further value.

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 100%, so all four parameters are already documented in the schema, including where duplicate_id comes from and the 2000-character note limit. The description repeats "with an optional note" and the duplicate-pair provenance, adding little beyond the structured fields; baseline 3 applies.

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?

"Mark a suggested duplicate pair ... as not the same person" gives a specific verb, resource, and outcome, so the effect is unambiguous. It also identifies the source of the identifier (a suggested duplicate pair from get_candidate include=duplicates), which separates it from merge_candidates and preview_candidate_merge.

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?

It establishes the context of use (a suggested duplicate pair that turns out not to be the same person) and points to where the pair id comes from, so the agent knows the prerequisite lookup. It does not explicitly name the alternative to use when the records actually are the same person (merge_candidates), so the routing is implied rather than stated.

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

All JobMojito 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.