Tools Reference

This page is the canonical reference for the kognyt_sf_* tool catalog.

Use it when you need to know:

• what each tool does
• whether it is available in Kognyt MCP, Kognyt for VS Code, or both
• whether it requires a connected Salesforce org

Product differences

• Kognyt MCP is the standalone MCP server. It exposes six focused platform-knowledge tools and does not connect to a Salesforce org.
• Kognyt for VS Code exposes platform knowledge through a single consolidated kognyt_sf_knowledge tool, plus six connected-org tools when you have an active org.

The platform-knowledge capability is the same in spirit — Kognyt MCP splits it into six focused tools, while Kognyt for VS Code rolls it into the one kognyt_sf_knowledge tool.

Availability matrix

Kognyt MCP — platform knowledge tools

These six tools are available in Kognyt MCP without a connected org.

kognyt_sf_constraints

Use this when you need Salesforce limits, platform rules, or best-practice guardrails before writing or changing code.

Typical uses:

• checking governor limits for DML, SOQL, CPU time, heap, or callouts
• understanding bulkification requirements
• checking platform rules for triggers, flows, or sharing behavior

It can filter by release, constraint type, and context such as apex, soql, dml, or triggers.

kognyt_sf_doc_search

Use this when you want Salesforce documentation results for a natural-language question instead of manually searching docs.

Typical uses:

• looking up Apex or LWC syntax
• finding SOQL or metadata API details
• finding documentation for Flow, permissions, deployment, or platform features

It accepts a query and can also narrow by release, topic, and result count.

kognyt_sf_releases

Use this when the question depends on Salesforce release timing or API version support.

Typical uses:

• checking which API version maps to a release
• confirming whether a feature is tied to a specific release
• listing current or archived releases

It can return the current release or a broader release list.

kognyt_sf_rules

Use this when you want standards, anti-pattern warnings, or code-review guidance for Salesforce code.

Typical uses:

• checking whether Apex follows best practices
• looking up rules for trigger handlers, tests, naming, or security
• finding severity-tagged rules for a review workflow

In Kognyt MCP this is part of the Pro path. In Kognyt for VS Code, this guidance is folded into the consolidated kognyt_sf_knowledge tool.

kognyt_sf_patterns

Use this when you want reusable implementation patterns rather than raw platform facts.

Typical uses:

• finding trigger handler patterns
• finding selector, service, or batch structures
• finding template-like starting points for Apex or LWC work

In Kognyt MCP this is part of the Pro path. In Kognyt for VS Code, these patterns are folded into the consolidated kognyt_sf_knowledge tool.

kognyt_sf_decision_guides

Use this when the real question is a trade-off.

Typical uses:

• trigger vs flow
• batch vs queueable vs schedulable
• SOQL vs SOSL
• platform events vs CDC

This tool is for choosing between approaches, not just retrieving facts.

Kognyt for VS Code — knowledge tool

kognyt_sf_knowledge

In Kognyt for VS Code, the platform-knowledge tools above are exposed as a single consolidated tool. Use it for general Salesforce knowledge when you do not need connected-org context, exact schema facts, impact analysis, or a metadata workflow action. It requires no connected org.

Typical uses:

• platform limits, governor limits, and best-practice guardrails
• Apex, LWC, SOQL, and metadata API documentation
• release timing and API version support
• coding standards, anti-pattern warnings, and review guidance
• reusable implementation patterns and templates
• trade-off guidance such as trigger vs flow, batch vs queueable, SOQL vs SOSL, or platform events vs CDC
• governed warnings about undocumented platform behavior
• broad "what can Kognyt help with here?" questions, including which tool to use next

It can narrow results by focus, release, and target object, class, feature, or package, and can include examples, citations, decision points, and warnings.

Kognyt for VS Code — connected-org tools

kognyt_sf_context

Use this first when the answer depends on the actual Salesforce org, not just the platform in general.

It returns org-specific context relevant to an intent, including signals like:

• existing triggers
• active flows
• validation rules
• related Apex classes
• schema context
• potential conflicts and org-specific warnings

This is the highest-value connected-org tool when you are about to create, modify, review, explain, or debug Salesforce logic.

kognyt_sf_schema

Use this when you need exact schema facts from the active org.

Typical uses:

• checking field API names
• checking field types and requiredness
• checking relationships and record types
• checking validation rules before writing SOQL, flows, or Apex

This is the schema lookup tool for object-level questions.

kognyt_sf_impact

Use this when you need to know what might break if you change an Apex class, interface, enum, or trigger.

Typical uses:

• refactoring a class and checking downstream impact
• understanding dependencies before changing automation
• checking warnings and risk before a code change

This is the dependency-analysis tool, not the execution tool.

kognyt_sf_retrieve

Use this when you want to bring metadata from the active org into the local workspace.

Typical uses:

• retrieving metadata from manifest/package.xml
• retrieving specific metadata members into the current project
• refreshing local workspace state from the active org

This is a workspace operation and requires an active org.

kognyt_sf_deploy

Use this when you want to deploy local metadata to the active org or validate the deploy first.

Typical uses:

• deploying selected metadata paths
• running a check-only validation before deployment
• specifying test level and test classes for deployment

This is the deployment tool for connected-org metadata workflows.

kognyt_sf_diff

Use this when you need to compare local metadata with org state and Kognyt's last known sync baseline.

Typical uses:

• checking whether a file is local-only or org-only
• seeing whether metadata is in sync or diverged
• deciding whether to retrieve, deploy, or refresh before continuing

This is the drift-inspection tool for workspace versus org state.

Related pages

• MCP Getting Started
• MCP API Keys
• VS Code Getting Started
• Metadata Workflows