Klarix Intelligence Engine

SWOT matrix with exploit vectors and counter-plays

generate_swot_analysis

Read-only

Deep multi-source web crawl into a four-quadrant SWOT matrix for a company: internal strengths (moat, proprietary tech, distribution lock) and weaknesses (pricing friction, customer complaints, legacy tech), plus external opportunities (untapped verticals, market vacancies, adjacent expansion) and threats (substitutes, price commoditization, regulatory shifts). Every entry carries evidence and a consequence. Adds strategic exploit vectors for winning deals against them and defensive counter-plays. Curate it to your own business with our_company_name, our_domain, our_differentiators, or a Klarix client_id so every vector is one you can actually execute. Returns markdown plus structured JSON.

Input Schema

TableJSON Schema

Name	Required	Description
`domain`	Yes	Company web domain to analyze, e.g. "zoominfo.com"
`vertical`	No	Vertical to sharpen the analysis against, e.g. "lithium battery manufacturers".
`client_id`	No	Klarix client id (kebab-case, e.g. "alium-batteries"). Loads company name, domain, value propositions, win themes, and ICP from clients/{client_id}/context.json when that file is reachable. Explicit arguments always override it.
`our_domain`	No	Your own web domain, e.g. "klarix.ai". Lets the tool research your side of the comparison.
`company_name`	No	Proper company name, if the domain does not make it obvious. Improves search precision.
`our_company_name`	No	Your company name. Curates the analysis toward how YOU win instead of a generic read.
`our_differentiators`	No	What you actually win on, in your words, e.g. ["3-7 day delivery", "done-for-you, not DIY"]. Anchors talk tracks to claims you can defend.
`competitor_viewpoint`	No	Override the derived relationship. Left unset, the tool works out whether you actually compete with this company from your own business context and only then adds exploit vectors. Set true to force competitive framing, false to force a self-assessment or partner review.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`swot`	Yes
`domain`	Yes
`sources`	Yes
`category`	Yes
`unknowns`	Yes
`vertical`	Yes
`our_context`	No
`company_name`	Yes
`relationship`	Yes
`confidence_detail`	No
`evidence_confidence`	Yes
`competitor_viewpoint`	Yes
`one_line_positioning`	Yes
`relationship_rationale`	Yes
`defensive_counter_plays`	Yes
`strategic_exploit_vectors`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 4, 2026

changedInput schema / properties / competitor_viewpoint / description

Previous value: -"True (default) treats the company as a competitor and adds exploit vectors for winning deals against them. False frames the same matrix as a self-assessment or partner review."New value: +"Override the derived relationship. Left unset, the tool works out whether you actually compete with this company from your own business context and only then adds exploit vectors. Set true to force competitive framing, false to force a self-assessment or partner review."

addedOutput schema / properties / relationship
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / relationship_rationale
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "company_name",
-  "domain",
-  "vertical",
-  "competitor_viewpoint",
-  "category",
-  "one_line_positioning",
-  "swot",
-  "strategic_exploit_vectors",
-  "defensive_counter_plays",
-  "evidence_confidence",
-  "unknowns",
-  "sources"
-]New value: +[
+  "company_name",
+  "domain",
+  "vertical",
+  "competitor_viewpoint",
+  "relationship",
+  "relationship_rationale",
+  "category",
+  "one_line_positioning",
+  "swot",
+  "strategic_exploit_vectors",
+  "defensive_counter_plays",
+  "evidence_confidence",
+  "unknowns",
+  "sources"
+]

First observedSep 4, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=true; the description aligns by disclosing a 'deep multi-source web crawl' and adds the nuance that exploit vectors are added only after the tool determines whether you actually compete. It also promises evidence and consequence per entry, which annotations don't convey. It doesn't directly address idempotentHint=false, but nothing contradicts 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?

Five dense sentences, all substantive: the first defines the output and quadrants, the second promises evidence and consequence, the third adds exploit/counter-play, the fourth explains customization, and the fifth states the return type. No filler, no restatement of the title, and the most important information is front-loaded.

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 an 8-parameter, open-world research tool, the description is nearly complete: it covers inputs, customization, behavioral nuances, and output format while the output schema and annotations carry the rest. It does not enumerate exclusion criteria, but 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.

Parameters3/5

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

With 100% schema description coverage, the schema already documents each parameter thoroughly. The description adds only aggregate curation guidance ('Curate it to your own business with our_company_name, our_domain, our_differentiators, or a Klarix client_id') and the competitor_viewpoint override behavior, which is useful but not new per-parameter semantics.

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 the exact deliverable — a four-quadrant SWOT matrix for a company — and explains each quadrant's content plus the unique additions of exploit vectors and counter-plays. It also names the output format (markdown plus structured JSON). No sibling tool covers SWOT, so the definition clearly differentiates it.

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?

Clearly implies when to use it: to research a company and produce competitive strategy customized to your own business or a Klarix client. However, it never explicitly names sibling alternatives or states when not to use it, such as when a battlecard or head-to-head analysis would be more appropriate.

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

All Klarix Intelligence Engine 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?