Outcomet

Mutate Competitor

competitor_mutate

Execute competitor mutations: upsert_profile, create_assessment, upsert_relation, upsert_risk, add_source, set_status, or create_rubric_version (admin only).

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": {
      "action": "<action>"
    },
    "name": "competitor_mutate"
  }
}

Input Schema

Name	Required	Description
`url`	No	Source URL.
`kind`	No	Source kind: homepage, pricing, interview, review, news, other.
`note`	No	Relationship context note.
`facts`	No	Structured facts (pricing, funding, stage, etc.).
`quote`	No	Verbatim quote or excerpt.
`since`	No	Date when relationship began (YYYY-MM-DD).
`action`	Yes	Mutation operation to execute.
`impact`	No	Risk impact rating (1-5).
`riskId`	No	Existing risk UUID if updating; omitted when creating a new risk.
`status`	No	Competitor tracking status.
`firedAt`	No	Timestamp when risk fired.
`ratings`	No	6 Outcomet rubric ratings on 0-10 scale (job, buyer, distribution, proof, differentiator, market).
`againstUs`	No	Strategic comparison points against own product.
`companyId`	No	Company UUID if known.
`firedNote`	No	Explanation of how risk fired.
`profileId`	No	Competitor profile UUID. Required for assessments, relations, risks, sources, status.
`rationale`	No	Justification per changed dimension.
`subjectId`	No	Company or Person UUID to link.
`summaryMd`	No	Markdown profile brief.
`changeNote`	No	Summary explanation of what changed.
`confidence`	No	Confidence rating: A (verified), B (mixed), C (inferred).
`dimensions`	No	Rubric dimensions (Admin only).
`likelihood`	No	Risk likelihood rating (1-5).
`riskStatus`	No	Risk status.
`rubricNote`	No	Rubric change note.
`categoryKey`	No	Competitor category key (e.g. direct, adjacent, legacy).
`companyName`	No	Company name if companyId is omitted.
`counterMove`	No	Planned response if risk triggers.
`subjectType`	No	Linked relation subject type.
`uvpVerbatim`	No	Verbatim positioning statement or headline.
`archetypeKey`	No	Risk archetype key.
`relationship`	No	Relationship type: uses, evaluating, switched_from, lost_to, won_from, champion, etc.
`statusReason`	No	Optional status explanation.
`uvpSourceUrl`	No	Source URL where UVP was identified.
`cadenceByTier`	No
`companyDomain`	No	Company domain for matching or creating in Contacts.
`quoteLanguage`	No	Language code of quote (e.g. de, en).
`idempotencyKey`	No	Caller-generated UUID or hash for idempotent retries.
`ringThresholds`	No
`tierThresholds`	No
`contextCompanyId`	No	Context employer company UUID if subject is a person.
`triggerCondition`	No	Condition that signals this risk is unfolding.
`cadenceOverrideMonths`	No	Custom re-check cadence in months.

Output Schema

Name	Required	Description	Default
`meta`	Yes
`action`	Yes
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false and idempotentHint=false, so the safety envelope is largely covered; the description adds the admin-only gate on create_rubric_version, which is genuine extra context. It says nothing about what an upsert overwrites, whether partial failures roll back across actions, or how idempotencyKey in the schema relates to the declared non-idempotent hint.

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?

One sentence, mutation verb front-loaded, and the complete action list presented as a scannable enumeration with the one qualifier (admin only) attached inline to the item it modifies. Nothing is redundant and nothing is padded.

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

Completeness2/5

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

For a seven-way polymorphic mutation tool carrying 43 parameters, the definition names the branches but omits everything an agent needs to choose and populate one: per-action required fields, ordering expectations, and error behavior. The existing output schema removes the need to explain return values, but the input-selection gap is severe enough to leave the definition incomplete.

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?

With 93% schema description coverage, the schema itself documents nearly every one of the 43 parameters, so the baseline of 3 applies. The description adds no mapping from action value to the subset of parameters that action consumes — the single most valuable thing it could contribute for a 43-param polymorphic payload — leaving the agent to infer that relationship entirely from the schema.

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 states a specific verb ("Execute") plus resource ("competitor mutations") and enumerates all seven valid action values, which cleanly separates it from read-side siblings like competitor_get and competitor_search. It stops short of explaining what any individual action does (upsert_profile vs create_assessment vs set_status), so the agent knows the surface but not the semantics of each branch.

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?

Declaring the tool as the mutation entry point implicitly routes write intent here and read intent elsewhere, and "(admin only)" flags a privilege precondition for create_rubric_version. However, there is no explicit when-to-use/when-not guidance, no statement that competitor_get should precede this call, and no hint that parameter requirements differ per action.

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

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