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
- whether it is part of the free or Pro MCP path
Product differences
- Kognyt MCP exposes the six platform-knowledge tools only. It does not connect to a Salesforce org.
- Kognyt for VS Code exposes all six platform-knowledge tools plus six connected-org tools when you have an active org.
Availability matrix
| Tool | What it does | MCP | VS Code | Connected org required | Access |
|---|---|---|---|---|---|
kognyt_sf_constraints | Platform constraints, governor limits, and best practices | Yes | Yes | No | Free |
kognyt_sf_doc_search | Semantic search over Salesforce documentation | Yes | Yes | No | Free |
kognyt_sf_releases | Release metadata, API versions, and timelines | Yes | Yes | No | Free |
kognyt_sf_rules | Coding rules, standards, and anti-pattern guidance | Yes | Yes | No | Pro in MCP |
kognyt_sf_patterns | Reusable implementation patterns and templates | Yes | Yes | No | Pro in MCP |
kognyt_sf_decision_guides | Trade-off guidance for architectural decisions | Yes | Yes | No | Pro in MCP |
kognyt_sf_context | Org-specific context for an intent or change | No | Yes | Yes | Connected org |
kognyt_sf_schema | Object schema, relationships, record types, and validation rules | No | Yes | Yes | Connected org |
kognyt_sf_impact | Dependency and downstream impact analysis | No | Yes | Yes | Connected org |
kognyt_sf_retrieve | Retrieve metadata into the workspace | No | Yes | Yes | Connected org |
kognyt_sf_deploy | Deploy or validate metadata from the workspace | No | Yes | Yes | Connected org |
kognyt_sf_diff | Compare local metadata with org state and sync baseline | No | Yes | Yes | Connected org |
Platform knowledge tools
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 VS Code it is available as part of the extension tool catalog.
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 VS Code it is available as part of the extension tool catalog.
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.
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.