sf-intelligence vs Metazoa Snapshot

At a glance

Read-only is a category boundary, not a feature gap

Snapshot's verbs are act-shaped: deploy, roll back, migrate, seed, bulk-edit, merge, split, clone. Its MCP server is built accordingly — Metazoa describes escalating capability levels that include bounded UI actions such as opening tabs, drilling into report rows, saving output to a project folder and preparing deployments, and states that destructive or high-impact operations require explicit consent, with read-only activity distinguished from write-enabled activity. That is a well-considered design for a tool that can change production.

sf-intelligence has no such design because it has no such surface. There is no deploy code, no update call, no delete path anywhere in the product. Consent gating is not a feature we implemented well; it is a feature we did not need, because the worst outcome of a bad answer is a wrong answer rather than a wrong change. That distinction matters if you are trying to get an autonomous agent approved: "the tool cannot write" is a shorter security review than "the tool can write but asks first".

It also means Snapshot and sf-intelligence are not really substitutes at the extremes. Nothing here will refactor two hundred profiles for you. Nothing there is free.

Pricing and licensing models

Metazoa Snapshot is a paid commercial licence, sold with onboarding, support and training, and delivered as a desktop application plus a managed package installed in the org. Metazoa does not publish a price list on the Snapshot product page, so treat any figure you find in a third-party directory as unverified and ask them for a quote. What you are buying is not only software: it is a vendor relationship, an accountable support path, and a product that has been doing deployments and profile cleanups for years.

sf-intelligence is free and source-available under MIT + Commons Clause — deliberately not "open source", since the Commons Clause withholds the right to sell the software itself as a service. You can run it, read every line, fork it for internal use, and verify what it does with your metadata rather than taking a claim on trust. See the licensing page for what that does and does not permit. There is no managed package, so nothing is installed in your Salesforce org at all — only a local read-only retrieve into a directory you own.

Worked example: the same field, two jobs

Take Widget__c.Status__c on a custom object with a lookup to Account. Two entirely different questions:

"Who can edit it, and what breaks if it goes?" — this is the graph's job. Ask in an MCP host and you get dependents and a permission cascade, each cited:

› who can edit Widget__c.Status__c, and what breaks if I remove it?
▸ field-level access: 2 permission sets grant Edit  [declared]
  PermissionSet:Widget_Ops · PermissionSet:Widget_Admin
▸ dependents: Flow "Widget_Router" · ValidationRule "Widget_Status_Required"
  ApexClass "WidgetService" reads Status__c  [parsed]
  coverageCaveat: dynamic SOQL not visible; verdict is "no static evidence", not "safe"

"Now strip Edit from one of those permission sets across forty profiles, and deploy it to production on Friday night." — that is Snapshot's job, and sf-intelligence cannot help you with it beyond telling you what you are about to touch. The clean division of labour is to plan the change against the graph and execute it with a tool built to execute. If the change is a field removal specifically, the reasoning is written out in the dependency-first field cleanup guide, and the permission-cascade side is covered under sharing and permission troubleshooting.

Choose sf-intelligence when you want to…

• Spend nothing, and read the source rather than trust a claim about what runs locally
• Install nothing in the Salesforce org — no managed package, only a read-only retrieve
• Work from any MCP host your team already uses, not a specific desktop application
• Get an explicit confidence tier on every edge and a coverage caveat on every absence-based verdict
• Hand an AI agent a tool that provably cannot change production

Choose Metazoa Snapshot when you want to…

• Actually deploy — sandbox to production, with scheduling, rollback and CI support
• Migrate relational data, seed sandboxes, or run org splits, clones and merges
• Do permission and profile surgery in bulk instead of reading about it
• A catalogue of prebuilt reports and visual ERDs rather than composing your own queries
• A GUI for admins who do not live in a terminal, plus vendor onboarding, support and training
• A local MCP server that can drive that suite under explicit consent for high-impact operations

When not to use sf-intelligence

• You need to make the change, not plan it. This is the big one against Snapshot. No deploy, no migration, no bulk edit, no rollback — ever, by design.
• You want a UI. There is no desktop app, no ERD renderer and no report catalogue. It answers in text, in an editor.
• You want prebuilt reports to browse. The tools compose to produce answers on demand; there is no library of fifty canned reports to click through.
• You need vendor support. No SLA, no onboarding, no training. You read the source or file an issue.
• You need current-state guarantees. The vault is a point-in-time snapshot and goes stale as soon as someone edits the org; freshness is your refresh discipline.
• You need business record data. The vault holds metadata. An opt-in, consent-gated read-only live plane returns capped counts and samples, but this is not a data tool.

What still differentiates

Against cloud incumbents, both win on locality, and we should stop claiming sole ownership of "metadata never leaves the workstation" — Metazoa says it too, and says it credibly. Against each other the honest contrasts are cost, source availability, read-only versus write-capable, whether anything is installed in the org, and how explicitly each finding is labelled with its provenance. Those are narrower claims. They are also ones we can defend.

Try it in a minute — no org, no licence

Evaluating an org-management suite takes a sandbox, a licence conversation and an install. Evaluating this takes one command, no Salesforce org, no authenticated sf CLI and no configuration. It serves a synthetic org — "Verdant Energy", a fictional solar installer — over MCP, entirely offline:

claude mcp add --transport stdio --scope user sf-intelligence-demo -- npx -y sf-intelligence demo

Ask it an impact or permissions question and see whether the citations hold up on metadata that is not yours. Then point it at a real org with one read-only retrieve.

More comparisons

For the other local-and-official option, see Salesforce's own DX and Hosted MCP servers, which cover live data and DevOps and are frequently registered alongside this one. For hosted alternatives in the same job class, see dx0 and Hubbl. Full set: compare hub · Elements.cloud · Sweep.