Check what a tool can access, where information may go and what evidence is still missing before connecting it. Read every profile free.
124 tool trust records within 550 reviewed public records, 624 routes and 7,346 distinct question variants. These are documentation reviews, not certifications or independent tool tests.
What does payment add?
The complete answer, structured profile, sources and limitations are free. You can keep the JSON locally. A single purchase adds a server-saved snapshot for later retrieval. The Evidence Receipt option adds an unsigned delivery record. Both retain the selected profile and source-version bindings; neither adds a private answer, fresh research or a vendor safety guarantee.
Retain your access key to retrieve a purchase. Payment is verified by the service; routine delivery needs no email. Hashes identify content versions and do not certify truth. Continuous monitoring and change alerts are not included.
Use a profile in an agent workflow
Search the free MCP connector with a practical question such as How can I review repository access without enabling writes?. Preview the returned route and read its scope. Documented means the publisher states it; inference identifies a review consideration; unknown means the reviewed evidence does not establish it. No profile authorizes tool execution.
How can an agent review repository access without enabling GitHub MCP writes?
GitHub documents a read-only server mode that removes write tools and a separate choice of toolsets. Review both the credential's repository access and the configured server mode. Lockdown is a content filter with stated limitations. This profile helps scope a repository-review connection; it does not verify your token, server configuration or resistance to prompt injection.
Read the complete tool trust profile
Review scope: GitHub-hosted remote MCP and the documented local server configuration; deployment, release and organization policies must be supplied by the buyer.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Publisher and operator
GitHub publishes the server and hosts the remote service; a local deployment has its own operator.
Repository results return to the connected client. If that client uses a hosted model, selected content may leave the repository service; inspect that client's data policy.
Actual token grants, effective tool list, enterprise hosting configuration and client retention/training terms.
Not established
Suggested refusal or clarification condition
For a review-only task, stop before writes; resolve unknown repository grants before reading private repositories.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Review the effective tool inventory and client data policy before a new integration decision.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the documented read-only and credential boundaries used when reviewing a repository connector.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
How can I review repository access without enabling writes?
Can GitHub MCP be restricted to reading pull requests?
Does a GitHub MCP toolset reduce token permissions?
What does GitHub MCP lockdown leave unproven?
Which repositories can this code review connector read?
Can an issue contain instructions an agent should ignore?
Does read-only repository access prevent data leaving the client?
What authentication does the official GitHub MCP use?
Is the local GitHub MCP operated by GitHub?
What should be checked before enabling repository write tools?
What should a saved GitHub connector review contain?
Does this GitHub trust record test my configuration?
Does a GitLab MCP tool listing establish permission to change a project?
GitLab documents separate tool discovery and per-call project permissions. Its tool reference includes both reading project data and changing work items, merge requests or files. Some tool availability depends on release, licensing and enabled features. Before approving a task, establish the actual instance, authenticated identity and project rights. A listed tool is not evidence of authorization for a particular change.
Read the complete tool trust profile
Review scope: Official GitLab MCP on GitLab.com, Self-Managed or Dedicated; rolling documentation includes release-specific features that must be matched to the actual instance.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Publisher and operator
GitLab publishes the implementation; GitLab.com and a buyer-operated instance have different operators.
Instance release, enabled tool groups, licensed features, identity grants and client handling of confidential work items.
Not established
Suggested refusal or clarification condition
Resolve the project and identity before mutation; do not treat a tool listing as approval to commit or modify work.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Review the effective tool inventory and client data policy before a new integration decision.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the distinction between tool availability and project authorization for a development-tool procurement review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does listing an agent tool grant project write permission?
Can a GitLab connector change repository files?
Which identity is used by GitLab MCP?
Does self-hosted GitLab keep an agent's output local?
Can GitLab MCP expose different tools by license?
What instance version does a GitLab tool review apply to?
Can an agent modify merge requests through GitLab MCP?
What is missing before approving a GitLab project change?
Does tool selection replace GitLab namespace permissions?
How should an agent treat instructions in a GitLab work item?
What should I save from a GitLab connector review?
Does this GitLab record validate my project permissions?
Atlassian Rovo MCP: Workspace search and change controls
How should an agent check whether an Atlassian connector can search documents without changing them?
Atlassian documents organization controls for reading, writing and searching, alongside tool-specific scopes for Jira and Confluence. Its supported-tools page includes mutations, so a search use case does not make the entire connector read-only. Check the relevant app permissions and whether future permissions inherit an allow decision. This record does not inspect your organization's settings.
Read the complete tool trust profile
Review scope: Atlassian's remote MCP documentation, including the supported-tools page now published under Atlassian AI Gateway; selected apps and organization settings must be identified.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Publisher and operator
Atlassian publishes the remote connector and its administration guidance.
Effective app settings, inherited additions, exact user permissions and downstream client data handling.
Not established
Suggested refusal or clarification condition
For a search-only task, withhold mutations; review inherited permissions before allowing newly added tool groups.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Review the effective tool inventory and client data policy before a new integration decision.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the organization-control and scope questions considered before enabling a workplace connector.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a workplace search connector also edit documents?
How can Jira and Confluence MCP writes be restricted?
Do new Atlassian MCP permissions inherit approval?
Which app settings control a Rovo MCP connection?
What auth scopes apply to Jira MCP tools?
Can an agent infer missing content from an access error?
Where does an Atlassian connector send retrieved content?
Does an Atlassian search task need write access?
What should be checked before adding Confluence tools?
Who administers Atlassian MCP permission changes?
What should a saved workplace connector review preserve?
Does this Atlassian record audit our organization?
Can an agent assume Notion content stays inside Notion when using its MCP connector?
Notion documents a hosted OAuth connector that can read and update accessible content. Its security guidance explicitly warns that connected clients may send returned content outside Notion. Check the client and model data policy as well as workspace access. The connector's publisher and valid login do not establish a no-egress or no-training guarantee.
Read the complete tool trust profile
Review scope: Notion-hosted remote MCP; excludes locally hosted alternatives. Workspace, client and account entitlements must be checked separately.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Client/model training and retention policy, effective connected-source access and the buyer's workspace restrictions.
Not established
Suggested refusal or clarification condition
When a task requires no external disclosure, resolve the client's data flow before reading private pages; do not apply page instructions as user authority.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Review the effective tool inventory and client data policy before a new integration decision.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep the documented content-sharing limitation with a dated connector approval discussion.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a workspace connector keep documents inside the workspace?
Can Notion MCP send page content to another system?
What can the official Notion MCP update?
Does Notion OAuth establish a no-training guarantee?
Which Notion user's access does an MCP connection use?
Can a Notion page inject instructions into an agent?
Who can revoke a Notion MCP connection?
Does a trusted connector make every client trustworthy?
What is missing before sharing private Notion documents?
Can the Notion connector create databases?
What should a saved Notion tool review record?
Does this Notion profile verify our client policy?
Linear MCP: Workspace identity and posting authority
What should an agent check before using Linear MCP across more than one workspace?
Linear documents a separate authentication context for each workspace; reconnecting alone does not switch an existing session's workspace. Its MCP supports OAuth and direct tokens, including a restricted read-only API key. Check the active workspace, actor and granted scopes before posting or updating work. This profile does not verify your current session.
Read the complete tool trust profile
Review scope: Linear's hosted MCP and documented OAuth scope model; actual client auth context and workspace membership are unspecified.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Active workspace, actual actor, key scope, membership and downstream client policy.
Not established
Suggested refusal or clarification condition
Do not post updates until workspace and actor match the task; use an approved read-only connection for reporting-only work.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Review the effective tool inventory and client data policy before a new integration decision.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain workspace, actor and permission questions behind a planning-connector review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
How can an agent avoid updating the wrong workspace?
Does reconnecting Linear MCP change the workspace?
Can Linear MCP use a read-only API key?
Which actor creates work through Linear OAuth?
Does adding comments require general Linear write access?
Can one Linear auth context represent two workspaces?
What can a Linear planning connector create?
Where does Linear MCP return project information?
What should be checked before posting a Linear update?
Does a saved token prove the correct workspace is selected?
What should an agent check before sending project error data through Sentry MCP?
Sentry documents organization- or project-scoped connections for its remote MCP, with project scope recommended where possible. Its toolkit describes debugging workflows and notes that AI-powered search in self-hosted setup requires a configured model provider. Identify the deployment, enabled tools and model route before transferring sensitive event context. The public connection page and repository differ in their description of authentication options.
Read the complete tool trust profile
Review scope: Sentry remote MCP, with separately attributed toolkit notes for local/self-hosted setups; these deployments are not treated as interchangeable.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Publisher and operator
Sentry publishes the remote service and toolkit; a self-hosted deployment has its own operator.
The connection page says OAuth for all connections; the toolkit additionally documents an explicit upstream-token remote path. That path was not tested.
Event context reaches the client. The toolkit's self-hosted AI search requires a model provider; actual provider, payload and retention remain unverified.
Deployment, event redaction, active skills, model provider, token route availability and retention.
Not established
Suggested refusal or clarification condition
Resolve event sensitivity and recipients before retrieval; stop before project changes outside a debugging-only task.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Review the effective tool inventory and client data policy before a new integration decision.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve project-scope, data-flow and authentication ambiguity in a debugging-tool review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
What should be checked before sending errors to an agent?
Can Sentry MCP be scoped to one project?
Does a debugging connector also manage projects?
Does self-hosted Sentry MCP search use a model provider?
What authentication ambiguity exists in Sentry MCP documentation?
Could error events contain data unsuitable for an AI client?
Does Sentry project scoping prove data redaction?
Which Sentry skills are enabled in this connection?
What recipients need review for an error-analysis tool?
Can an agent assume every Sentry setup supports the same tools?
Does connecting Stripe MCP authorize an agent to refund or change a live account?
Stripe documents broad API read and write tools, with OAuth for interactive use and permission-scoped Agent Keys for autonomous access. A connection is not approval for a particular financial action. Check the account, live or sandbox environment, permissions and approval rules. The documentation announces an MCP key-acceptance change on 31 October 2026; this dated review does not test that future behaviour.
Read the complete tool trust profile
Review scope: Stripe MCP authentication and account operations as documented on the review date; separate from an application's server-side Stripe integration.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Actual key grants, selected account/environment, active approval rules and client retention.
Not established
Suggested refusal or clarification condition
Withhold live mutations until exact action, account and environment are authorized; never treat this profile as permission to spend or refund.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Review the documented 31 October 2026 MCP authentication change before use across that date.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the documented account-action boundaries and dated authentication notice used in a finance-tool review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does connecting a payment tool authorize refunds?
How should an agent distinguish live and sandbox Stripe access?
What permissions should a Stripe Agent Key have?
Can Stripe MCP cancel subscriptions?
When does Stripe MCP change accepted key types?
Does a Stripe MCP read tool expose customer account data?
Do approval rules replace reviewing the intended financial action?
Is an application server key the same use case as an agent key?
What should be checked before a Stripe MCP write?
Does OAuth alone approve a live payment action?
What is saved in a Stripe tool trust snapshot?
Does this Stripe profile verify our account settings?
Cloudflare API MCP: API reach behind a compact tool list
Does a small Cloudflare MCP tool list imply narrow account permissions?
Cloudflare's API MCP uses search and execute operations to reach a broad API surface. A small visible tool list therefore does not establish narrow authority. Check OAuth grants or API-token permissions and the intended account resources. The docs and repository describe different tool totals; this record preserves that ambiguity rather than using a count as a security claim.
Read the complete tool trust profile
Review scope: Cloudflare API MCP at its published remote endpoint; excludes separate domain-specific Cloudflare servers.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Effective account/token grants, current deployed tool inventory, client handling and compatibility of a particular restricted token.
Not established
Suggested refusal or clarification condition
Check account and requested API method before execution; stop when the selected token cannot meet the task's required restrictions.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Review the effective tool inventory and client data policy before a new integration decision.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the evidence showing why a compact tool interface still requires an account-permission review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a small tool list mean an agent has little authority?
Can Cloudflare MCP modify account resources through execute?
Which account does a Cloudflare API MCP connection use?
Can a Cloudflare API token restrict an agent's resource access?
Does Cloudflare MCP support token client IP filtering?
Why do Cloudflare MCP tool counts differ across sources?
Is Cloudflare code mode the same as read-only access?
Where do Cloudflare MCP API results go?
What should be checked before an infrastructure agent executes an API call?
Does the Cloudflare server cover only documentation search?
Supabase MCP: Database access and developer authority
What should an agent check before connecting a database project to Supabase MCP?
Supabase documents project scoping, read-only mode and feature-group restrictions. Its guidance identifies developer permissions and warns about untrusted database content. Review those controls and the actual data requested before connecting a sensitive project. A confirmation prompt or read-only query does not establish that returned data is suitable for the client or model receiving it.
Read the complete tool trust profile
Review scope: Supabase-hosted MCP for developer use; project, enabled features and authentication method must be specified.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Publisher and operator
Supabase publishes the MCP and hosted connection guidance.
Resolved grants, data sensitivity, effective feature restrictions, client retention and buyer-specific isolation.
Not established
Suggested refusal or clarification condition
For a diagnostic-only task, withhold writes and minimize returned data; do not give an end user the developer connector.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Review the effective tool inventory and client data policy before a new integration decision.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve project scoping, read-only and data-disclosure questions behind a database-tool review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can read-only database tools still disclose sensitive rows?
How should an agent scope a Supabase MCP project?
Does Supabase MCP use developer or end-user permissions?
Can Supabase MCP apply database migrations?
Does project scoping disable Supabase account management tools?
Do SQL confirmations prove a person approved every operation?
Can stored database content inject agent instructions?
What authentication can unattended Supabase MCP use?
Which database logs will reach the connected AI client?
What should be checked before connecting a production database tool?
What is retained in a Supabase trust snapshot?
Does this profile validate our database access controls?
Playwright MCP: Browser identity and session boundaries
Does an isolated Playwright MCP browser session prevent privileged web actions or data disclosure?
Playwright MCP documents persistent, isolated and existing-browser session modes. Isolation concerns session state; it does not make authenticated web actions read-only. Its origin filters explicitly exclude redirects from their protection, and the project states that MCP itself is not a security boundary. Review browser identity, destinations and task authorization separately.
Read the complete tool trust profile
Review scope: Microsoft's Playwright MCP in a local/operator-run browser setup; installed package version, launch settings and browser state were not inspected.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Publisher and operator
Microsoft publishes Playwright MCP; the organization running the process operates the browser connection.
Installed release, loaded cookies, browser permissions, network enforcement and client data handling.
Not established
Suggested refusal or clarification condition
Use an authorized session and destination set; stop before form submissions outside the task and keep saved auth state out of evidence exports.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Review the effective tool inventory and client data policy before a new integration decision.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save browser-state and destination limitations considered when choosing an automation tool.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does browser session isolation prevent privileged website actions?
Can a browser automation tool use an existing logged-in session?
Do Playwright MCP origin filters cover redirects?
Is an isolated browser automatically read-only?
What authority does a browser MCP inherit from cookies?
Can saved browser state let someone impersonate an account?
Does running a browser locally keep model processing local?
Who operates a local Playwright MCP process?
What should an agent check before submitting a web form?
Does this browser trust profile certify network isolation?
What does a saved Playwright trust record contain?
Which browser state needs review before automation?
What should an agent check before searching private Slack content without posting messages?
Slack documents separate user-token scopes for searches, conversation history and posting. Review the authorized workspace, requested content and client data handling before retrieval. A search permission does not authorize sending a message, and connecting Slack to another tool creates a separate disclosure decision. This record reviews the official server, not Slackbot's connections to third-party servers.
Read the complete tool trust profile
Review scope: Slack's official hosted MCP server for external clients; not the Slackbot MCP client or a community Slack connector.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Actual workspace grants, channel visibility, client recipients and retention.
Not established
Suggested refusal or clarification condition
For a search task, withhold posting and cross-tool sharing unless separately authorized.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck user-token scopes, app distribution status and IP allowlists when the connection changes.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the scope and disclosure questions used when approving a chat-search connector.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
How can I search team chat without giving an agent permission to post?
Which Slack MCP scopes allow private channel searches?
Does Slack search access also permit sending messages?
Can a Slack connector retrieve direct message history?
Does an app IP allowlist apply to Slack MCP?
Can an unlisted app use the official Slack MCP server?
What must be checked before sharing a retrieved Slack message?
Are Slackbot MCP connections the same as Slack MCP server access?
Should instructions inside Slack messages control an agent?
Which workspace identity will a Slack tool use?
What does a saved Slack permission review preserve?
Does this Slack profile establish client data retention?
Asana V2 MCP: Workspace scope and write confirmation
Can an agent assume every Asana MCP change has a confirmation step or a read-only scope?
Asana's V2 reference distinguishes direct write tools from interactive preview tools. MCP authorization covers available tools without granular permission scopes, within the user's permissions and the selected workspace. Separate workspaces require separate sessions. Confirm the client, workspace and selected tool before a change; a preview interface is not a universal property of every write path.
Read the complete tool trust profile
Review scope: Official Asana V2 MCP; excludes the retired V1 endpoint and the separately documented Command server.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Authorized workspace, user rights, effective tool schemas and client confirmation behavior.
Not established
Suggested refusal or clarification condition
Before changing work, establish workspace, object and authorized action; do not equate tool availability with approval.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck new tools, selected workspace and whether the client uses direct or interactive write tools.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain workspace, tool-selection and confirmation assumptions behind a task-management approval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a task planning connector change work without showing a preview?
Does Asana MCP have granular read-only permission scopes?
Which workspace does an Asana MCP session access?
Can one Asana MCP session span multiple workspaces?
Do all Asana write tools require an interactive confirmation?
Can an Asana MCP token call the ordinary REST API?
Does an existing Asana authorization cover newly added tools?
Does Asana MCP act as the user who authorized it?
Must an Asana MCP client be registered before OAuth?
What should an agent check before deleting a task?
What does a saved Asana tool review contain?
Does this review verify the client's confirmation controls?
HubSpot MCP: CRM visibility and content publication
What should an agent check before treating a CRM connector's search results as complete or allowing publication?
HubSpot's hosted MCP can read CRM content and perform permitted updates, including some publishing actions. Access depends on the user, subscription, granted tools and account configuration. With Sensitive Data enabled, the documented MCP restrictions block activity and conversation data. Missing results therefore do not establish that no records exist. New scopes require a renewed installation grant.
Read the complete tool trust profile
Review scope: HubSpot's remote account-data MCP; not the separate local developer MCP for building HubSpot apps.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Sensitive Data setting, installed grants, subscription, inbox restrictions and client retention.
Not established
Suggested refusal or clarification condition
Withhold publication or CRM changes during analysis; label results incomplete when access is unresolved.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck installation grants, Sensitive Data configuration and tool availability after account or subscription changes.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the documented visibility and publication limits behind a CRM integration review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a CRM connector miss records because sensitive-data access is blocked?
Does HubSpot MCP support publishing website content?
What does HubSpot Sensitive Data disable for MCP?
Does a missing CRM search result prove there are no records?
Who selects the scopes for a HubSpot MCP connector?
Do updated HubSpot scopes need a new installation grant?
Does HubSpot MCP authentication require PKCE?
Are HubSpot developer MCP and remote CRM MCP the same?
Can subscription level change the available CRM tools?
What should an agent check before exporting customer details?
What does a saved HubSpot review preserve?
Does this profile inspect my HubSpot account settings?
Can an agent treat a design connector as read-only when it can also capture UI and write to canvas?
Figma's remote MCP documents both design-context retrieval and canvas-changing workflows. OAuth sign-in and an eligible client are required; capabilities and file actions depend on the tool and access rights. Capturing an application UI sends information into Figma, while retrieving a design supplies context to the client. Those are different data-transfer decisions.
Read the complete tool trust profile
Review scope: Figma's official remote MCP; desktop-server behavior and third-party Figma connectors are outside this profile.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Actual file access, client eligibility, capture content, plan allowances and model data handling.
Not established
Suggested refusal or clarification condition
For design inspection, withhold canvas writes and UI uploads unless their content and destination are authorized.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck eligible client, file rights and new canvas or capture tools before changing the workflow.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the data-direction and file-change boundaries reviewed before a design-to-code workflow.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a design connector modify files as well as read them?
Does Figma MCP send captured application UI to Figma?
What is the difference between extracting a design and uploading a screen?
Does Figma remote MCP require OAuth?
Can any MCP client connect to the official Figma server?
What permission is needed to generate into an existing Figma file?
Can Figma seat type affect MCP actions?
Which design data can a Figma tool return to an agent?
Should confidential screens be excluded from UI capture?
Does this Figma review also cover third-party connectors?
What does a saved design-tool review preserve?
Does this profile verify my Figma file permissions?
What should an agent verify before using a deployment connector to inspect or change a team's project?
Vercel documents a separate sign-in and team-authorization step after adding its MCP server. Existing Vercel permissions still apply. Tools cover project and deployment inspection as well as operational changes, so a diagnosis request should not silently become a deployment or account change. Review the target team, project and environment, and the handling of returned logs.
Read the complete tool trust profile
Review scope: Vercel's hosted account-management MCP, not an arbitrary MCP application deployed on Vercel.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Authorized teams, effective role, target environment and client retention/approval settings.
Not established
Suggested refusal or clarification condition
During diagnosis, stop before deployment or account changes until the exact target and action are authorized.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck granted teams, project role and deployment target whenever the connection or task changes.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve team, environment and log-disclosure checks used to approve a deployment assistant.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does adding a deployment connector authorize access to every team?
What should be checked before an agent deploys a project?
Does Vercel MCP retain existing user permissions?
Can Vercel MCP read runtime logs?
Why might a Vercel team be missing after connection?
Is a hosted MCP app on Vercel the same as Vercel MCP?
Can a deployment diagnosis turn into an unintended change?
What data can leave Vercel through an AI client?
Which team owns the project a deployment tool will change?
How should an agent distinguish preview and production targets?
What does a saved Vercel connector review preserve?
Do old MCP-specific deny actions still establish a read-only boundary for an AWS agent?
AWS's current managed MCP documentation says downstream services apply the caller's IAM permissions. It explicitly marks the earlier MCP-specific IAM actions as ineffective and describes condition keys for distinguishing MCP-originated calls. OAuth through AWS Sign-in is also documented alongside the signed-request path. A historical policy name alone does not prove the current connection is restricted.
Read the complete tool trust profile
Review scope: AWS's managed MCP service in Agent Toolkit for AWS; not the local AWS API MCP package or Bedrock AgentCore runtime.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Publisher and operator
AWS operates the managed service covered by these documents.
Effective role/session policies, organization controls, endpoint region and client data handling.
Not established
Suggested refusal or clarification condition
Resolve account, role and effective current policy before acting; do not rely on an obsolete MCP deny action.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck IAM model changes, effective role/session restrictions and MCP-origin condition keys before relying on a policy.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep a dated policy-model reference showing why legacy deny statements need rechecking before agent access.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can an old MCP deny policy fail to restrict a cloud agent?
Which permissions govern calls through AWS managed MCP?
Do AWS MCP-specific IAM actions still enforce access?
How can a policy distinguish MCP-originated AWS calls?
Does AWS managed MCP support temporary credentials?
Is AWS MCP OAuth the same connection path as a SigV4 proxy?
Does cloud MCP access make service calls read-only?
What should an agent check before changing an AWS resource?
Does this AWS profile cover the local API MCP package?
Can an account role allow more than the intended agent task?
What does a saved AWS authorization review preserve?
Azure MCP: Caller identity and deployment boundaries
Can an agent assume a locally running cloud connector is isolated from production or has limited authority?
Microsoft documents Azure MCP access through Entra identities and Azure RBAC. A local process can still act with the developer's cloud permissions. Remote self-hosted deployments require protection of both the caller boundary and the server's execution identity. Microsoft explicitly excludes production data and credentials from its local-server guidance; this review does not verify a deployed gateway or role assignment.
Read the complete tool trust profile
Review scope: Microsoft-maintained Azure MCP Server, with local developer and remote self-hosted modes distinguished; excludes Foundry-specific MCP services.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Publisher and operator
Microsoft publishes Azure MCP; the party running a local or self-hosted deployment operates that instance.
Tenant, subscription, role assignments, deployment mode, gateway enforcement and client recipients.
Not established
Suggested refusal or clarification condition
Do not use the local developer path for production data; verify caller, server identity and target before a remote change.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck execution identity, caller validation, roles and tool definitions when changing deployment mode.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the caller/server-identity and local-versus-remote boundaries behind a cloud-tool review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a local cloud connector keep production credentials isolated?
Which Azure identity does an MCP tool use?
Do Azure RBAC permissions constrain MCP operations?
Can a broadly privileged server act for a less privileged caller?
What must protect a remote self-hosted Azure MCP endpoint?
Does Microsoft permit production credentials in local Azure MCP?
Can Azure MCP run deployment operations?
Does a local MCP process prove local-only model processing?
What should be checked before enabling updated cloud tools?
How should an agent distinguish Azure tenant and subscription?
What does a saved Azure access review preserve?
Does this profile verify my gateway or role assignments?
Datadog MCP: Telemetry access and result completeness
Can an agent treat an observability connector's returned trace as complete or assume it cannot change monitoring?
Datadog documents role and organization controls for MCP reads and writes, plus resource-specific permissions. Its tool reference warns that a large trace may be truncated without a way to retrieve every span. Incident details also omit timeline data. Treat those limits as coverage boundaries when investigating an outage; an incomplete response is not a complete incident record.
Read the complete tool trust profile
Review scope: Datadog's main remote MCP service; excludes the separate local Code Security MCP server.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Regional availability, actual roles, data-access restrictions, toolsets and client retention.
Not established
Suggested refusal or clarification condition
Mark incomplete traces and timelines explicitly; withhold monitoring changes during an evidence-only investigation.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck organization switches, toolset permissions and trace/timeline limitations before each new investigation workflow.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain access and response-completeness limits alongside an incident-review decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can an observability tool return an incomplete trace?
Does Datadog MCP include every span of a large trace?
Does the Datadog incident tool include its timeline?
What permissions are required for Datadog MCP writes?
Can an organization hide Datadog MCP write tools?
Does a Datadog MCP role replace resource-level permissions?
Can an AI client send Datadog logs to its model provider?
Is the local Code Security MCP the same as remote Datadog MCP?
How can restricted log visibility affect an investigation?
Should an agent change monitors during evidence collection?
What does a saved Datadog review preserve?
Does this profile measure a live incident's completeness?
Does a read-only monitoring connector prevent every database query or disclosure?
Grafana's MCP repository separates disabling writes from disabling queries. Read-only mode removes raw SQL query tools unless explicitly re-enabled, while other queries can remain. Query-free mode removes query tools but is not a universal block on every datasource path. Credential and datasource privileges still need inspection. A read-only label therefore does not establish a no-query or no-disclosure boundary.
Read the complete tool trust profile
Review scope: Grafana's official MCP package operated against Grafana Cloud or a local instance; deployment flags, transport and credentials must be identified.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Publisher and operator
Grafana publishes the server package; the deployer operates the MCP process.
Installed version, flags, transport protection, service account, datasource rights and client recipients.
Not established
Suggested refusal or clarification condition
For metadata-only work, resolve alternate datasource paths and credential rights before allowing queries.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck installed release, query/write flag combinations and datasource credential rights before expanding access.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the distinction between write prevention, query exposure and datasource authority for monitoring-tool approval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a read-only monitoring connector still allow queries?
What is the difference between Grafana MCP write and query restrictions?
Can Grafana MCP raw SQL tools change data?
Can SQL tools be re-enabled in Grafana read-only mode?
Does query-free Grafana MCP block every datasource path?
What permissions does a Grafana service account token inherit?
Can one Grafana service account span organizations?
Does disabling writes prevent telemetry from reaching an AI client?
What should be checked before allowing datasource queries?
Can a dashboard inspection task disclose sensitive data?
What does a saved Grafana boundary review preserve?
Does this profile verify my installed Grafana MCP flags?
Can an agent assume a shared search connector isolates each user's permissions and project data?
Elastic distinguishes shared API-key identity from per-user OAuth connections, with OAuth documented for Serverless projects. MCP access also depends on the Kibana space in the endpoint and its cross-project search scope. Restrict keys to intended indices and application privileges; a successful connection is not proof of per-user isolation or single-project coverage.
Read the complete tool trust profile
Review scope: Elastic Agent Builder acting as an MCP server for external clients; not its connector for calling external MCP servers.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, feature entitlement and effective configuration are not verified.
Publisher and operator
Elastic publishes Agent Builder; the chosen Stack deployment or Serverless project determines the operating environment.
Resolve identity, space and data scope before retrieval; do not claim user isolation for a shared key.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck API-key grants, endpoint space, linked-project search scope and workflow tools after configuration changes.
Record history: 2026-10-11 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the identity, index and space-scope assumptions behind an enterprise-search connector review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a shared search API key isolate each user's permissions?
Which Kibana space does an Elastic MCP connection use?
Can Elastic MCP search linked projects?
Is Elastic MCP OAuth available for every deployment type?
Do Elastic API keys and OAuth use the same identity model?
What privileges does an Elastic Agent Builder key need?
Should an Elastic MCP key be restricted to specific indices?
Does the Elastic MCP catalog include workflow tools?
Is Elastic's MCP server the same as its external-tool connector?
What should be checked before sharing an Elastic connector?
What does a saved Elastic access review preserve?
Does this profile inspect my cross-project search settings?
MongoDB MCP: Read-only tools and database authority
Can an agent inspect MongoDB without receiving permission to change data or clusters?
MongoDB documents a read-only MCP mode and recommends a separate read-only database identity. Write operations are otherwise enabled by default. Review both layers and any Atlas tools: selecting a safer tool set does not establish the effective permissions of an existing connection.
Read the complete tool trust profile
Review scope: MongoDB-published local server; not the separately hosted remote service
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
MongoDB publishes the local MCP server; the buyer controls its local configuration.
Actual credentials, database grants, Atlas privileges, telemetry settings and installed version have not been inspected.
Not established
Suggested refusal or clarification condition
Resolve the target identity and allowed operations before requesting sensitive data; do not treat tool names as proof of database restrictions.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck the server mode, disabled categories and database or Atlas grants.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the two-layer permission review behind an analysis-only database connection.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Which MongoDB identity will an analysis agent use?
Does MongoDB MCP enable writes by default?
What does MongoDB MCP readOnly restrict?
Can I disable Atlas tools without disabling database reads?
Are read-only MongoDB tools enough with a write-capable user?
Which collections can the MongoDB connection inspect?
Could MongoDB MCP create a cluster?
Which MongoDB MCP metadata operations remain available?
Where do MongoDB query results go after retrieval?
What telemetry settings should I review for MongoDB MCP?
What evidence is missing before approving MongoDB agent access?
What changes should trigger a MongoDB MCP permission recheck?
Postman MCP: Region, credentials and tool-set scope
Which Postman MCP configuration fits API discovery without granting unnecessary workspace changes?
Postman documents separate tool configurations and local or remote servers. Minimal is a smaller tool set, not a stated read-only guarantee. US remote authentication supports OAuth; the EU remote and local variants use an API key. Match the region, identity and specific tools to the task before connecting.
Read the complete tool trust profile
Review scope: Publisher remote and local variants; US and EU authentication differ
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Account rights, chosen tools, connected API secrets and downstream client retention are unverified.
Not established
Suggested refusal or clarification condition
Confirm region and specific operations before accessing internal definitions or allowing workspace mutations.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck tool configuration, account region, credentials and workspace membership.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the region and tool-set assumptions behind an API discovery connection.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is Postman Minimal MCP guaranteed read-only?
Can the Postman MCP Learn configuration search documentation?
Which Postman MCP variant needs an API key?
Does the EU Postman MCP server support OAuth?
Can local Postman MCP avoid all external data transfer?
What can Full Postman MCP change?
Does Postman Context Graph require team enablement?
Which workspace rights does my Postman agent inherit?
Should an agent receive internal API environment values?
How do Postman local and remote telemetry defaults differ?
What should I preserve when reviewing a Postman connection?
When should Postman tool access be reviewed again?
Snowflake MCP: Discovery permission and downstream role grants
Does permission to connect to Snowflake MCP also authorize every configured data tool?
Snowflake distinguishes access to the MCP server from privileges on its underlying tools and data. OAuth configuration and the effective role matter. Search, analyst, agent and custom-function tools can require different grants; successful tool discovery is not evidence that every invocation is authorized or read-only.
Read the complete tool trust profile
Review scope: Snowflake-managed MCP server object; not the Snowflake Labs local server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Snowflake provides the managed MCP server within the customer account.
Effective role grants, procedure behavior, data policies and client storage are not verified.
Not established
Suggested refusal or clarification condition
Inspect the named role and configured tools before treating the endpoint as an approved data-only interface.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck roles, OAuth binding, warehouses and custom tool definitions.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the distinction between connector discovery and actual data or procedure authority.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does Snowflake MCP USAGE grant access to all tables?
Which role will a Snowflake MCP session use?
Can Snowflake MCP expose stored procedures?
Is Snowflake-managed MCP the same as the Labs server?
Does Snowflake MCP support dynamic client registration?
What privileges does a Cortex Search tool need?
What evidence establishes a custom Snowflake tool is read-only?
Can a default warehouse problem break Snowflake MCP initialization?
Where can Snowflake MCP query results be retained?
What should I check before exposing a Cortex Agent through MCP?
Does listing a Snowflake tool prove I can call it?
What should a Snowflake connector review snapshot preserve?
Qdrant MCP: Retrieval scope and persistent memory writes
Can a retrieval agent search Qdrant without adding persistent memories?
The official Qdrant MCP server separates finding stored information from storing new information. Its read-only option disables the store tool. Review the collection, database credential and deployment transport separately; a retrieval setting does not establish who can reach a remotely exposed server.
Read the complete tool trust profile
Review scope: Official qdrant/mcp-server-qdrant deployment selected by the operator
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Qdrant publishes the server; the operator chooses its deployment and database.
Database-key scope, remote client authentication, retention and embedding deployment have not been verified.
Not established
Suggested refusal or clarification condition
Resolve collection and caller scope before retrieving private memory; obtain task authority before storing new material.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck collection routing, transport exposure, database credentials and store-tool availability.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve which memory collection and read-only assumptions supported a retrieval decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does Qdrant MCP have a read-only option?
Can Qdrant MCP store conversation memories?
Which Qdrant collection will an agent search?
Does a Qdrant API key authenticate remote MCP clients?
What metadata can Qdrant MCP persist?
Can disabling qdrant-store limit memory changes?
Does semantic similarity establish that a retrieved memory is true?
Where is information saved by Qdrant MCP?
Which Qdrant deployment transport is configured?
What evidence is needed before exposing Qdrant MCP remotely?
Can an agent search Qdrant without permission to add memories?
What should change review cover after a Qdrant key rotation?
Pinecone Developer MCP: Documentation access versus index changes
Can I give an agent Pinecone documentation access without exposing project data or index writes?
Pinecone Developer MCP can search documentation without a project API key. A configured key enables project interactions including supported index creation, upserts and searches. The reviewed server supports integrated-inference indexes; it should not be represented as universal access to every Pinecone product.
Read the complete tool trust profile
Review scope: Pinecone Developer MCP; separate from Pinecone Assistant MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Actual project grants, namespace selection, client retention and input-data rights are unverified.
Not established
Suggested refusal or clarification condition
Keep documentation-only tasks without project authority; verify target and approved data use before index operations.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck server variant, supported index types, key scope and namespace.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the reason a project credential was or was not needed for a developer workflow.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Pinecone Developer MCP work without an API key?
Does Pinecone MCP documentation search expose project data?
Can Pinecone Developer MCP create an index?
Can a Pinecone MCP upsert change existing records?
Does Pinecone Developer MCP support every index type?
How does Developer MCP differ from Pinecone Assistant MCP?
Which namespace will the Pinecone agent query?
What should I verify before granting Pinecone project access?
Where do records submitted through Pinecone MCP go?
Can a successful Pinecone search prove source truth?
When should a Pinecone MCP key be withheld?
What belongs in a saved Pinecone integration review?
ClickHouse MCP: Read-only defaults and write opt-ins
What evidence separates an analytical ClickHouse MCP session from one that may alter data?
The ClickHouse MCP documentation describes read-only queries by default, an explicit write-access opt-in and an additional destructive-operation control. Database restrictions still apply. Review the effective settings and whether embedded chDB is enabled before making a claim about the session boundary.
Read the complete tool trust profile
Review scope: Official ClickHouse/mcp-clickhouse; remote ClickHouse and optional embedded chDB configuration
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
ClickHouse publishes the MCP server; deployment configuration belongs to the operator.
Database grants, effective environment settings, transport exposure and installed version are unverified.
Not established
Suggested refusal or clarification condition
Confirm the backend and effective write policy before describing a connection as analysis-only.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck write flags, destructive-operation controls, backends and database identity.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the configuration assumptions that keep analytical access distinct from data changes.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is ClickHouse MCP read-only by default?
Can enabling ClickHouse MCP writes override database restrictions?
What additional control applies to destructive ClickHouse operations?
Is chDB enabled in my ClickHouse MCP configuration?
Which database user does ClickHouse MCP use?
Does database authentication protect the MCP listener itself?
Can a ClickHouse agent inspect schemas without writes?
What should I verify before allowing an INSERT through MCP?
Where can ClickHouse query results be copied by an assistant?
Does an old ClickHouse review cover new write settings?
What evidence distinguishes analytical and mutating ClickHouse access?
What triggers another ClickHouse MCP configuration review?
Zapier MCP: Dynamic tool discovery and cross-app actions
What should I check before a Zapier agent can discover tools and take actions across connected apps?
Zapier MCP uses connected-app actions and can discover and enable tools during a conversation. A fixed tool list is an alternative. Review the discovery mode, app identities and authorization for each destination; successful calls also consume the existing Zapier task allowance.
Read the complete tool trust profile
Review scope: Zapier hosted MCP with app connections; dynamic or manually fixed tool discovery
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Configured connections, effective workspace controls, budget and human approval behavior are unverified.
Not established
Suggested refusal or clarification condition
Resolve the app identity and permission for each write or external message before execution.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck enabled discovery, app connections, shared-server access and task charging.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the approved destinations and discovery assumptions for a cross-app workflow.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Zapier MCP discover and enable tools during a conversation?
Can I use a fixed Zapier MCP tool list?
Which connected app account will a Zapier action use?
Could a Zapier agent read CRM data and email it elsewhere?
Does Zapier MCP require approval for each message in my client?
Do successful Zapier MCP calls consume plan tasks?
Are failed Zapier MCP calls charged as tasks?
Can a repeated Zapier action create duplicate changes?
What should I check before sharing a Zapier MCP server?
Which client transport does Zapier MCP require?
What evidence defines an approved Zapier destination?
When should a Zapier cross-app workflow be reviewed again?
Docker MCP Toolkit: Profile isolation and retained credentials
Does removing a Docker MCP server also revoke its credentials and eliminate its previous access?
Docker documents profile-based server selection, explicit filesystem mounts and credential management. Removing a server does not itself remove its stored credentials. Container packaging and catalogue checks are useful evidence, but do not establish the permissions or safety of every tool in a selected profile.
Read the complete tool trust profile
Review scope: Docker Desktop Toolkit profiles and gateway; not Docker Sandboxes gateway
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Docker provides the Desktop Toolkit; individual tool publishers and downstream services remain separate operators.
Effective mounts, enabled servers, signatures, downstream grants and credential revocation have not been tested.
Not established
Suggested refusal or clarification condition
Review the active profile and revoke obsolete credentials explicitly; do not infer safety from catalogue inclusion.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck profile membership, dynamic discovery, mounts and residual credentials.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the reviewed server inventory and offboarding questions for a Desktop profile.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does removing a Docker MCP server remove its credentials?
Which servers are in the active Docker MCP profile?
Can Docker MCP servers access host files by default?
Does a container stop a tool sending data to external services?
What does Docker MCP catalogue verification establish?
Is Docker Desktop Toolkit the same as the Sandboxes gateway?
Can dynamic MCP add servers after a profile review?
What OAuth grants remain after stopping a Docker MCP container?
Which file mounts should a Docker tool review record?
Does switching Docker MCP profiles change available tools?
What evidence is needed for Docker MCP offboarding?
Shopify Cart MCP: Cart changes and purchase authority
Can a shopping agent prepare a Shopify cart without committing the buyer to payment?
Shopify separates Cart MCP from Checkout MCP. Cart tools can create, read, replace and cancel a pre-checkout cart using unauthenticated requests with agent-profile metadata. Checkout has a separate authentication boundary. Older Storefront cart tools were removed; a cart or estimated total is not proof of payment.
Read the complete tool trust profile
Review scope: Merchant Cart MCP over UCP; separate from checkout and deprecated Storefront cart tools
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Shopify documents the service; calls target the selected merchant storefront.
Merchant support, negotiated version, final pricing and buyer payment authority are unverified.
Not established
Suggested refusal or clarification condition
Keep cart preparation separate from purchase approval and verify the current cart before requesting checkout.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck merchant capabilities, cart replacement behavior and checkout authentication.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the protocol and buyer-authority boundary behind pre-purchase cart preparation.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Shopify Cart MCP prepare a cart without payment?
Does a Shopify cart total prove a completed purchase?
Does Shopify update_cart replace the whole cart?
What changed for older Shopify Storefront MCP cart tools?
Does Shopify Cart MCP require an agent profile?
Is Checkout MCP authentication separate from Cart MCP?
What happens if an agent omits items when replacing a cart?
Which merchant receives the Shopify cart request?
Should an agent treat estimated Shopify totals as final prices?
Can an agent cancel a pre-checkout Shopify cart?
What evidence separates cart authority from purchase authority?
When should a Shopify MCP migration review be refreshed?
Redis MCP: Database ACLs and state-changing memory tools
What prevents a Redis agent from changing session memory while performing a read task?
The Redis MCP server exposes both retrieval and state-changing tools. Its documentation points to Redis ACLs for database restrictions. Identify the database user, command scope and permitted keys; having a memory interface does not make the session read-only or establish a retention policy.
Read the complete tool trust profile
Review scope: Official redis/mcp-redis server; operator-selected Redis instance and identity
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Redis publishes the server; the operator chooses its Redis deployment.
Actual ACLs, instance selection, expiration rules, transport security and client retention are unverified.
Not established
Suggested refusal or clarification condition
Confirm command and key permissions before accessing private session state; do not infer read-only access from a search-oriented prompt.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck ACLs, database selection, expiry and supported tools.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the database identity and state-change assumptions behind a memory connector review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Redis MCP modify session memory?
Which Redis ACL identity is used by the agent?
Do Redis MCP search prompts guarantee read-only access?
Can Redis ACLs restrict the keys an MCP tool reaches?
Can a Redis MCP queue operation remove an item?
Can Redis MCP publish messages to other consumers?
Does storing memory in Redis establish an expiry policy?
Which Redis database number is selected?
Is TLS enabled for the Redis connection?
What should I check before exposing session keys to an agent?
What evidence distinguishes Redis reads from state changes?
Apify MCP: Actor discovery, execution and stored results
Can I let an agent discover Apify Actors without authorizing paid execution or storage access?
Apify separates unauthenticated discovery tools from authenticated Actor execution and access to run data. Select the tools and Actors needed for the task, then check account authority and spending limits before execution. Discovering an Actor does not establish permission to collect its target data.
Read the complete tool trust profile
Review scope: Official hosted or local MCP with selected Actors
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Apify publishes and operates the hosted service; local deployment is also documented.
The selected Actor implementation, target authorization and buyer spending controls are unverified.
Not established
Suggested refusal or clarification condition
Require target, budget and data-scope approval before running an Actor.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck exposed tools, Actor permissions, account billing and storage access.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep the Actor selection, allowed purpose and unresolved collection permissions with the reviewed source version.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Apify MCP search Actors without an API token?
Does finding an Actor authorize running it?
Which Apify tools expose stored run results?
What inputs will an Apify Actor receive?
Can an agent run an Actor beyond its approved budget?
How do I limit Apify MCP to selected tools?
Does Actor discovery establish permission to scrape a target?
Which account pays for an authenticated Actor run?
What should I record before giving an agent Apify access?
Are unauthenticated Apify discovery tools equivalent to storage access?
Can I retain the reviewed Apify execution boundary?
When should an agent ask before starting data collection?
Firecrawl MCP: Endpoint mode, browser state and interaction
Does a Firecrawl search connection also allow browser interactions or saved login state?
Firecrawl documents different hosted tool sets. Its full interface includes interaction tools that can click, type and preserve browser state, while a dedicated search-only endpoint has a restricted tool set. Review the actual endpoint and exposed tools before treating a connection as retrieval only.
Read the complete tool trust profile
Review scope: Official server; hosted full, keyless and search-only modes
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Firecrawl publishes the official MCP server and hosted endpoints.
Effective endpoint configuration, profile contents and account usage controls are unverified.
Not established
Suggested refusal or clarification condition
Require action authorization before using interaction tools or saving authenticated state.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck endpoint tools, authentication, browser profiles and credit consumption.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve which endpoint and browser-state boundary supported a retrieval-only decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is every Firecrawl MCP endpoint read-only?
Can Firecrawl interaction tools click and type?
What distinguishes Firecrawl search-only and full endpoints?
Can a Firecrawl browser profile retain login state?
Which Firecrawl tools are exposed without a key?
Does scraping a page authorize submitting its forms?
What data can enter a Firecrawl browser profile?
How should I review a Firecrawl connection for a search task?
Does using Firecrawl locally prove all processing stays local?
What should I check before allowing Firecrawl interactions?
Can I save the reviewed Firecrawl endpoint restrictions?
When should a Firecrawl task require action approval?
Tavily MCP: Account selection and query attribution
Does signing in to Tavily MCP prove that queries use the intended team API key?
Tavily documents a key-selection order for remote OAuth connections, including a named default and personal-versus-team precedence. Login alone therefore does not demonstrate the intended billing identity. Check the selected key and account before sending work queries; session attribution is separate from user authorization.
Read the complete tool trust profile
Review scope: Official remote OAuth/API-key and local wrapper
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Tavily publishes the MCP integration and operates the search API.
Selected credentials, retention obligations and effective client settings are unverified.
Not established
Suggested refusal or clarification condition
Resolve billing identity and query-data permission before sensitive or chargeable work.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck OAuth key-selection rules, account membership and client attribution settings.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the reviewed account-selection assumptions behind an agent research connection.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Which Tavily API key does an OAuth connection use?
Does Tavily MCP login select my team billing account?
Can personal Tavily credentials take precedence over team credentials?
What should I check before sending confidential search queries?
Does a Tavily session identifier identify an authorized human?
Can I distinguish Tavily authentication from billing attribution?
What evidence confirms the intended Tavily account?
Does running a Tavily wrapper locally keep queries local?
How should I document a Tavily research connection?
What changes require rechecking Tavily key selection?
Can I preserve the source version for Tavily account rules?
When should an agent pause a search for account clarification?
Exa MCP: Free search access and billable research tools
Can adding Exa authentication expose billable research beyond keyless search?
Exa documents keyless rate-limited access and authenticated modes. The authenticated default tool set includes a usage-billed research operation, while explicit tool selection replaces the defaults. Check the exposed tools and spending authority after connecting credentials; a successful search does not authorize a broader research run.
Read the complete tool trust profile
Review scope: Official hosted keyless and authenticated MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Actual team, credits, task cost and result completeness are unverified.
Not established
Suggested refusal or clarification condition
Require an agreed research scope and budget before usage-billed execution.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck default tools, account billing and explicit tool selection.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the tool and spending boundary chosen before an authenticated research task.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Exa MCP work without an API key?
Does Exa OAuth enable paid research tools?
Is an Exa agent research run billed by usage?
Does an explicit Exa tool list replace default tools?
Which Exa team is charged for a research run?
Can I connect Exa for search without approving open-ended research?
What data is sent in an Exa research task?
Does a successful Exa result establish complete coverage?
How should I record an Exa research budget boundary?
What should I recheck after adding Exa credentials?
Can I save the Exa tool-selection evidence?
When should an agent ask before extending web research?
Brave Search MCP: API plan and result-type limitations
Can I assume a Brave Search MCP response is a complete local-business or factual answer?
Brave documents separate search and summary tools, with plan-dependent local capabilities and a web-search fallback. Record the result type and account entitlement before relying on a local query. A generated summary or returned search page is supporting material, not independent verification of the underlying claim.
Read the complete tool trust profile
Review scope: Official API-backed local server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Brave publishes the server and operates the Search API.
Buyer plan, query coverage and factual accuracy of returned material are unverified.
Not established
Suggested refusal or clarification condition
Qualify the result type and verify cited evidence before consequential reliance.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck plan entitlements, fallback behavior and summary prerequisites.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the result-type and entitlement qualifications used in a search evidence review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does Brave Search MCP include local search on every plan?
Can a Brave local query fall back to web search?
Does a Brave summary prove the cited claim?
Which Brave API key pays for an agent search?
Does a local Brave MCP server keep queries on my computer?
What location information accompanies a Brave query?
How should I distinguish a summary from source evidence?
What plan evidence supports a Brave local-search result?
Can a missing Brave result prove a business does not exist?
What should an agent preserve from a web-search decision?
Can I save the Brave result-scope review?
When does search evidence need an explicit coverage limit?
Browserbase MCP: Cloud sessions, cookies and page actions
Can Browserbase MCP use a logged-in browser session to make changes on a website?
Browserbase documents cloud sessions that can retain authentication state and perform navigation, clicks, typing and form actions. Treat the session identity and target website as part of the permission review. Read access to a page does not establish authority to submit a form or make a purchase.
Read the complete tool trust profile
Review scope: Official hosted service and local MCP client setup
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Browserbase operates the cloud browser infrastructure and publishes the MCP integration.
Session contents, target permissions, retention and buyer model configuration are unverified.
Not established
Suggested refusal or clarification condition
Confirm the intended action and affected account before submitting or changing state.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck session persistence, credential recipients, model choice and target permissions.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the session-identity and action boundary reviewed before browser automation.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Browserbase MCP submit forms while logged in?
Are Browserbase sessions running on my computer?
Can Browserbase preserve cookies between interactions?
Which account is affected by a Browserbase page action?
Does permission to inspect a page include permission to purchase?
What credentials does Browserbase MCP need?
Can changing the model change credential requirements?
What page data can leave the user environment?
How do I review reuse of an authenticated browser session?
What should be recorded before automated form submission?
Can I retain a Browserbase action-scope review?
When should a browser agent stop for task authorization?
n8n MCP: Workflow visibility, authoring and execution
Does connecting to n8n MCP only let an agent run a fixed workflow?
The reviewed n8n documentation includes workflow search, execution and authoring. Search previews and full workflow access have different boundaries; OAuth grants and workflow exposure also matter. Check the installed version and execution mode before granting access, because a workflow can call connected services using its configured credentials.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
n8n publishes the instance MCP service for Cloud and self-hosted instances.
Installed features, effective grants and downstream credential scope are unverified.
Not established
Suggested refusal or clarification condition
Confirm workflow, execution mode and downstream action authorization before running it.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck instance version, OAuth grants, exposure settings and published workflow revisions.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the version, exposure and downstream-action assumptions behind workflow access.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can n8n MCP create or edit workflows?
Does n8n workflow search reveal only exposed workflow previews?
Can n8n MCP run unpublished workflows?
What distinguishes production and manual n8n execution?
Which user identity does an n8n MCP token represent?
Does enabling n8n MCP expose every workflow?
Can n8n workflows act through connected service credentials?
What permissions did an OAuth client receive in n8n?
Does revoking one OAuth client remove all personal-token access?
What evidence should precede an agent workflow execution?
Can I save an n8n workflow-authority review?
When should workflow authoring require a separate approval?
Semgrep Guardian: Available scan tools and enforced checks
Does installing Semgrep MCP prove every agent code change was scanned?
Semgrep distinguishes callable MCP scanning tools from event-triggered hooks. Tool availability alone does not prove invocation or coverage of a particular revision. Its former standalone MCP repository is archived and points to the main Semgrep distribution, so verify the installed integration and retain actual scan evidence.
Read the complete tool trust profile
Review scope: Current Guardian integration; archived standalone server distinguished
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Semgrep publishes Guardian and the current Semgrep distribution.
Actual hooks, permissions, data flow and completed scan coverage remain unverified.
Not established
Suggested refusal or clarification condition
Do not claim a revision was checked without a matching scan record and demonstrated trigger coverage.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck distribution migration, hook configuration, scan policy and retained results.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve why scanner installation was insufficient evidence of a checked code revision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does installing Semgrep MCP prove code was scanned?
What distinguishes Semgrep MCP tools from hooks?
Is the old standalone Semgrep MCP repository current?
Which revision does a Semgrep scan result cover?
Can an agent ignore an available scan tool?
What evidence proves a required scan ran?
Does an empty finding list certify secure code?
Which Semgrep integration handles my code and findings?
What should procurement ask about scanner enforcement?
Can a scan of one revision support another revision?
Can I save the Semgrep enforcement evidence boundary?
When should an agent refuse to claim a completed security check?
Snyk MCP: Folder trust and scan-time build execution
Can a Snyk dependency scan execute project tooling, even when the task is only a security review?
Snyk documents that dependency scanning can invoke ecosystem tools such as build systems to obtain a dependency tree. The MCP integration includes folder-trust and authentication controls. Review the repository and execution context before scanning; a scan request is not proof that untrusted project tooling is safe to run.
Read the complete tool trust profile
Review scope: Official Studio MCP and CLI-backed scanning
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Repository behavior, effective trust settings and scan-product data flow are unverified.
Not established
Suggested refusal or clarification condition
Require repository and execution-scope review before scans that invoke project tooling.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck scan type, build-tool behavior, folder trust and Snyk organization.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep the folder-trust and execution-context assumptions attached to a scan approval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a Snyk dependency scan run build tools?
Does a security scan always avoid local code execution?
What does Snyk folder trust establish?
Which Snyk organization receives a scan?
Can an MCP scan trigger authentication?
What should I review before scanning an unfamiliar repository?
Does a clean Snyk result establish deployment safety?
Which project data leaves the local scan environment?
Can an installed Snyk tool be skipped by an agent?
What evidence supports permission to run dependency tooling?
Can I retain the Snyk scan-execution boundary?
When should an agent stop before scanning untrusted project code?
PagerDuty MCP: Regional identity and incident changes
Can I connect PagerDuty MCP for incident review without granting authority to change operations?
PagerDuty documents read and management tools on its hosted MCP service. Authentication scopes constrain successful calls, while hosted tool filtering is not available. Check the regional endpoint, key type and granted scopes before connecting; incident visibility does not authorize changing schedules, services or incident state.
Read the complete tool trust profile
Review scope: Official hosted regional MCP service
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
PagerDuty operates the hosted MCP service; the self-hosted predecessor is deprecated.
Buyer region, effective scopes and approved incident actions are unverified.
Not established
Suggested refusal or clarification condition
Confirm affected resources and task authority before operational changes.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck hosted tool inventory, scope mapping, region and client authentication support.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the regional, identity and read-versus-action boundary for an incident assistant.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can PagerDuty MCP change incident state?
Can I filter hosted PagerDuty MCP tools to reads only?
Do PagerDuty OAuth scopes constrain management calls?
Which PagerDuty region should an MCP client use?
Are user-level and account-level API keys interchangeable for every tool?
Does incident visibility authorize changing an on-call schedule?
Is the old self-hosted PagerDuty MCP server still the current service?
What operational data reaches a PagerDuty MCP client?
Does an MCP connection prove incident-change approval?
What evidence supports an observation-only PagerDuty integration?
Can I save the PagerDuty scope review?
When should an incident agent request action-specific authorization?
Can an agent update my Airtable records without activating an automation?
Airtable documents record editing through MCP within the permissions of the connected user. Automation changes are saved as drafts and activation happens in the Airtable interface. Record-write access and permission to activate an automation are separate review questions; verify the selected bases, granted scopes and intended operation.
Read the complete tool trust profile
Review scope: Airtable hosted server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Airtable operates the documented hosted MCP service.
The actual integration grants and buyer automation state have not been inspected.
Not established
Suggested refusal or clarification condition
Require an identified base and authorised change; do not report an automation as active from draft creation alone.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck after base grants, scopes or automation capabilities change.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the access and draft/activation distinction used when approving a records task.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can an agent update Airtable records without turning on automations?
Which base should my assistant be allowed to change?
Does interface access mean access to every base record?
Can a read-only Airtable identity edit through MCP?
What distinguishes an automation draft from activation?
Does connecting Airtable approve every record change?
What evidence should I request for base access?
Can my assistant read confidential table data?
How should I review a request to create a new base?
Can an agent infer activation from a successful draft save?
What should a saved Airtable permission review contain?
When should I recheck an Airtable connector grant?
Does connecting Box MCP give my agent only document-search access?
The documented Box MCP tool set includes content reads and writes. Some sharing and move operations are disabled by default until an administrator enables them. Review enabled tools, OAuth scopes and existing user permissions together before calling the connection read-only.
Read the complete tool trust profile
Review scope: Box hosted remote server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer tool toggles, folder permissions and connected-client retention are unknown.
Not established
Suggested refusal or clarification condition
Require explicit approval for sharing or moving content and evidence of the currently enabled tools.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck after administrators change tool availability or sharing permissions.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the documented capability and enablement checklist behind a document-access decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is a Box agent connection limited to document search?
Can a Box connector upload files or add comments?
Which Box tools need administrator enablement?
Does a broad scope grant access to every folder?
Can enabling a tool change an existing risk review?
What should I verify before an agent shares a Box file?
Can search results expose content to an external assistant?
What evidence distinguishes reading from moving files?
Does connecting Box authorise an upload?
Which user acts when Box tools are called?
Can I preserve the source version for a Box onboarding review?
When should a Box agent permission review be repeated?
Can my agent use a Miro board from a different team after one connection?
Miro documents a team-specific OAuth connection and existing board-access controls. Its tools can read and change board content, so a request to summarise a board should identify both the authorised team and allowed actions. Enterprise availability also depends on administrative enablement.
Read the complete tool trust profile
Review scope: Miro hosted server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
The selected team, active board grants and client data handling are unverified.
Not established
Suggested refusal or clarification condition
Clarify the board and team before access; do not convert a summary request into edits or comment resolution.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck when the connection changes team or board permissions change.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep the team, board and action boundaries used in an assistant onboarding review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can an agent use boards across Miro teams after one connection?
What should I check before sharing workshop notes with an assistant?
Does a Miro summary task permit changing sticky notes?
Can resolving a comment count as a state-changing action?
Why might an accessible Miro board be missing from a connector?
Who approves Miro MCP for an Enterprise team?
Does a board URL by itself grant access?
Which identity determines board visibility?
Can board content leave Miro through tool results?
What evidence supports a read-only workshop task?
Can I save the limits of a board-access review?
When should a Miro team connection be reviewed again?
Can a monday.com agent connection do more than read task boards?
The Platform MCP exposes board operations and broader GraphQL queries and mutations, with calls tied to the authenticated user. Tool availability is therefore wider than task lookup. Confirm token permissions, permitted actions and the target board; distinguish this connection from the separate app-development MCP.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
The buyer grants, account settings and effective available tools are unverified.
Not established
Suggested refusal or clarification condition
Require approval for mutations and notifications; do not infer read-only access from a board-search use case.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck token type, exposed tools, API version and board permissions.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve a decision about permitted board operations and the wider GraphQL surface.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a task-board agent execute GraphQL mutations?
Does a monday.com lookup task permit sending notifications?
How do personal and app tokens differ for an assistant?
Which workspace should a board agent use?
Is the Platform MCP the same as Apps MCP?
Can a generic API tool exceed the named board tools?
What evidence supports limited monday.com access?
Could API limits interrupt a multi-step board change?
Does a successful connection authorise new items?
What data could board results reveal to an assistant?
Webflow MCP: Site changes and Designer dependencies
Does keeping the Webflow Designer closed stop an agent from changing my site?
Webflow documents that most MCP operations use its Data API without an open Designer. Only some live-session capabilities need the Bridge App. The server can change site content and design within existing permissions, so closing the Designer is not evidence of a read-only connection.
Read the complete tool trust profile
Review scope: Main hosted MCP; beta and documentation-only servers excluded
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
The buyer role, publishing workflow and site state have not been checked.
Not established
Suggested refusal or clarification condition
Require approval for the intended site change; do not treat closing the Designer as an access control.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck role grants, workspace connection and Bridge-dependent capabilities.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the distinction between API changes, live Designer requirements and role evidence.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can an agent change Webflow while the Designer is closed?
Does a missing Bridge connection prevent every site edit?
Which Webflow actions need a live Designer session?
Can my agent write site custom code?
Does a site-review request authorise publishing changes?
Can Webflow MCP add users or change roles?
What happens when the agent connects to the wrong workspace?
Does an empty interactions result prove there are no interactions?
Which evidence should precede a CMS change?
Can an agent read site analytics through this connection?
Can I save the reviewed site-change boundaries?
When should a Webflow connector permission review be renewed?
Can one Canva MCP authorisation stand in for every user of an AI application?
Canva requires individual user authentication, and operations follow the access that user has to designs and assets. The server supports creation, editing, export and collaboration, with some features depending on plan. An application connection alone does not establish entitlement for another user or permission to export a design.
Read the complete tool trust profile
Review scope: Canva hosted MCP for AI assistants
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
The actual user grants, content rights and export destination are unknown.
Not established
Suggested refusal or clarification condition
Require the intended user and approved export destination; do not reuse one user consent as organisation-wide authority.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck client registration, user access and plan-specific capabilities.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the user, plan and export questions behind an application-access decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can one Canva authorisation cover all application users?
Does registering an OAuth client grant access to designs?
Can a Canva agent export a confidential design?
Which identity determines whether a design can be edited?
What should I check before an assistant uploads brand assets?
Does a paid plan replace permission to edit a shared asset?
Can design comments be changed as part of a read task?
Where might an exported design be retained?
What evidence supports a Canva app onboarding decision?
Can an agent assume every design feature is included?
Can I save the reviewed export and access boundary?
When do changes to Canva client access need a new review?
Can an Intercom agent add a note when I only asked it to inspect a conversation?
Current Intercom documentation includes internal-note and article writes alongside conversation and contact reads. A note can affect conversation state. The service documents US and EU endpoints, with AU unsupported at review. Confirm the workspace region, consented permissions and exact task before allowing writes.
Read the complete tool trust profile
Review scope: Regional hosted Intercom MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer consent, workspace region and client data policy are unverified.
Not established
Suggested refusal or clarification condition
Do not turn inspection into a note or article edit without approval; clarify region and subject first.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck after new scopes, regional support or note behaviour changes.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep the dated region, note-side-effect and consent evidence behind a support-agent decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can an Intercom inspection task add an internal note?
Could adding a note reopen a customer conversation?
Which admin is recorded as the author of an agent note?
Which endpoint matches an EU Intercom workspace?
Does a region setting cover the connected AI client too?
Can an agent edit Help Center articles?
Does App Store approval approve an MCP redirect URI?
How should I check the application requesting OAuth consent?
Could pagination hide part of a conversation search?
What evidence supports granting conversation-write access?
Can I save the documented support-agent action boundary?
When should I review an Intercom connection again?
LaunchDarkly MCP: Flag changes and environment scope
How can I review a feature-flag agent without granting broad change authority?
The local LaunchDarkly MCP uses an API access token. Its documentation recommends both a read-only token role and read scope for a read-only setup, and supports selecting tools. Review the token, environment and enabled operations together; a flag change can affect application behaviour even without a new deployment.
Read the complete tool trust profile
Review scope: Local MCP server with API token; hosted OAuth variant excluded
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
LaunchDarkly publishes the MCP; the buyer operates this local variant.
The installed version, token grants and actual flag evaluation paths are unverified.
Not established
Suggested refusal or clarification condition
Require an explicit target environment and change approval; do not treat local hosting as read-only authority.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck token roles, selected tools and deployment variant.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the token, tool and environment evidence used for a flag-agent review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
How do I limit an agent to reading feature flags?
Does local MCP hosting stop external API changes?
Is a read tool filter enough without a read-only token?
Which environment would a feature-flag change affect?
Can a flag change alter behaviour without deployment?
What should I verify before allowing a targeting-rule update?
Does the hosted connector use the same authentication as local MCP?
Can tool selection narrow a flag-agent surface?
What evidence should identify the acting API token role?
Could configuration files expose agent credentials?
Can I save a feature-flag permission review?
When should I recheck a LaunchDarkly local MCP configuration?
Sanity MCP: Drafts, publication and release metadata
Does creating a Sanity release through MCP schedule its publication?
Sanity documents that creating a release records metadata but does not schedule it. Document patching saves drafts or release versions, while separate tools can publish documents. Agents should distinguish a saved draft, a release record and actual publication evidence.
Read the complete tool trust profile
Review scope: Sanity hosted workspace MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
The buyer project grants, document state and downstream publishing configuration are unknown.
Not established
Suggested refusal or clarification condition
Do not report scheduled or published content from draft or release creation alone; require the intended state and evidence.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck tool semantics, token scope and target dataset before relying on an older review.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the distinction between content preparation and completed publication.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does creating a release schedule Sanity publication?
Is a saved content draft already live?
Can a Sanity agent publish documents separately?
Which dataset should an agent modify?
Does an API token inherit the same permissions as OAuth?
What evidence proves a publication step completed?
Can a release version be confused with a draft?
Could retrying an uncertain upload duplicate work?
Do all Sanity MCP tools avoid AI-credit use?
What should I verify before granting project-management access?
Can I save the documented draft-to-publication boundary?
When should a Sanity content-agent review be refreshed?
Does adding Netlify MCP only give my agent deployment guidance?
Netlify describes MCP capabilities for creating and deploying projects, managing resources and changing configuration. The local package can use the API and CLI; current docs also distinguish a remote server. Review the chosen variant, credentials and permitted resources before treating the connection as guidance-only.
Read the complete tool trust profile
Review scope: Local Netlify MCP package; remote connector distinguished
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Netlify publishes the local MCP package; the buyer runs this variant.
The buyer token, local execution permissions and target deployment state are unknown.
Not established
Suggested refusal or clarification condition
Require explicit deployment and configuration authority; do not infer it from a request for hosting advice.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck when switching server variant, identity or target team/project.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the deployment, credential and configuration questions used before enabling hosting actions.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a Netlify connector only provide deployment advice?
Can an agent change environment configuration through Netlify MCP?
Which project would a deployment affect?
Does local MCP execution keep all data on my computer?
How should I distinguish a remote connector from the local package?
What evidence supports production deployment authority?
Can a hosting agent change access controls?
Does connecting a token approve extension installation?
What should an agent clarify before changing form handling?
Can resource information be returned to an external AI client?
Neon MCP: Project grants, SQL roles and write access
Does selecting a Neon tool category make a database agent read-only?
No. The README distinguishes category selection from read-only enforcement and a pinned SQL role. It documents OAuth grants and API-key requests differently, and warns against production use. Review the project, role and write setting together before approving database access.
Read the complete tool trust profile
Review scope: Hosted management server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
The buyer grant, role privileges and runtime have not been checked.
Not established
Suggested refusal or clarification condition
Clarify production use and effective grants; do not infer read-only access from category selection.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck category contents, OAuth grants and SQL-role privileges.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep the documented grant distinctions behind a database-agent onboarding decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a database tool category prevent writes?
Which Neon project can my agent reach?
Can a selected SQL role narrow database access?
Does changing a connection URL widen an existing OAuth grant?
How does API-key scoping differ from OAuth consent?
Can a schema inspection connection also run queries?
Does a read-only query share a transaction with later calls?
What should I capture before approving database-agent access?
Can development guidance establish production suitability?
Which connector settings should a database review preserve?
Does a permission category stay fixed as tools are added?
Prisma MCP: Workspace actions and CLI guardrail limits
Do Prisma CLI destructive-command safeguards also protect MCP operations?
Prisma explicitly limits those safeguards to CLI commands. Its MCP server exposes workspace operations, and the documentation directs users to review approvals in the AI client. A CLI safety claim therefore does not establish the approval behaviour of an MCP call.
Read the complete tool trust profile
Review scope: Hosted workspace server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Effective workspace rights and client approval rules are unknown.
Not established
Suggested refusal or clarification condition
Require task authority and the actual MCP approval policy before a destructive operation.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck MCP capabilities and client approval settings.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the CLI-versus-MCP control distinction for an onboarding review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Do CLI safety checks also apply to MCP calls?
Can my Prisma assistant manage more than database queries?
Which workspace is selected during Prisma authorisation?
Does an MCP connection approve destructive changes?
What evidence shows the client asks before resource deletion?
Can an assistant inspect deployment information?
Does a CLI refusal prove the MCP will refuse too?
What should procurement ask about agent approval policies?
How should I separate a database read from a resource change?
Can I save the documented Prisma guardrail boundary?
Which client settings affect MCP approvals?
When should a workspace automation review be repeated?
PlanetScale MCP: Branch permissions and query safeguards
Do PlanetScale query safeguards make full-access agent queries harmless?
No. PlanetScale documents branch-specific read-only or full-access permissions and particular query safeguards. These are bounded checks, not proof that every permitted query is appropriate. Review the branch, action and intended effect; a prompt to seek confirmation is not evidence that a person approved.
Read the complete tool trust profile
Review scope: Hosted OAuth server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
The actual grant and any human confirmation are unverified.
Not established
Suggested refusal or clarification condition
Require the intended branch and authorised effect; do not label full access harmless.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck branch grants, query protections and tool additions.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the specific branch and safeguard distinctions used in a query-access review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Do database query safeguards eliminate write risk?
Can an agent have read-only production and writable development access?
Which branch will a PlanetScale query use?
Does a schema-change prompt prove human approval?
Can full-access queries still change the wrong records?
What evidence shows an agent query reached a replica?
Are billing records part of every connection grant?
Can I review query authority before connecting a database?
What should a saved branch-permission review include?
Does a permitted query establish business authorisation?
How should I distinguish performance inspection from schema changes?
When should PlanetScale MCP permissions be rechecked?
Can an Aiven connection marked read-only still expose selected write tools?
Yes. Aiven documents an optional write allowlist that re-enables named actions in read-only mode. Service-family selection also leaves core discovery available. Review the complete configuration and authenticated user permissions, rather than treating one read-only label as the whole permission boundary.
Read the complete tool trust profile
Review scope: Hosted and local variants
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Aiven publishes the local server and hosts the remote variant.
Buyer exceptions, secret exposure settings and effective account rights are unknown.
Not established
Suggested refusal or clarification condition
Inspect write exceptions before approving a read-only task.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck write allowlists, service scope and user-role changes.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep the complete permission checklist for a managed-data connector review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can read-only mode contain a write exception?
Which Aiven tools remain after selecting a service family?
Can a Kafka inspection agent also produce messages?
What determines Aiven MCP effective permissions?
Does local execution avoid access to cloud services?
Which configuration proves writes are excluded?
Can service discovery expose more than one database?
What should I check before letting an agent read connection details?
Does an API token alone define the enabled tool list?
Can I save the read-only exception review?
When should an Aiven task require clarification?
How do hosted and local connector settings differ?
Databricks MCP: Governed and legacy connection paths
Does every Databricks MCP call pass through Unity Gateway controls?
No. The current AWS documentation distinguishes system.ai MCPs through Unity Gateway from legacy workspace endpoints. Legacy calls use underlying resource permissions and bypass MCP-level Gateway grants, policies and tracing. Record the actual connection path before accepting a governance or audit claim.
Read the complete tool trust profile
Review scope: AWS documentation: system.ai and legacy workspace endpoints
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
The buyer endpoint, enabled beta features and effective resource rights are unknown.
Not established
Suggested refusal or clarification condition
Require the actual endpoint path before accepting Gateway coverage.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck endpoint migrations, Gateway availability and underlying grants.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the connection-path evidence needed for an agent governance review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does every MCP connection use the same governance gateway?
Can legacy Databricks calls bypass Gateway tracing?
Which resource permissions govern an older workspace endpoint?
Does an enabled Gateway prove all agent calls are covered?
How do analytics and SQL MCP capabilities differ?
Which Databricks MCP features are still in beta?
Can an agent connect external services through Databricks?
What connection evidence should an audit reviewer request?
Does missing Gateway history prove no tool was called?
Can I save the distinction between legacy and governed access?
Which endpoint is my coding agent actually using?
When should a Databricks MCP migration trigger another review?
MotherDuck local MCP: Read-only queries and host access
Does read-only mode isolate a self-hosted MotherDuck MCP server from its host?
No. The publisher explicitly warns that read-only mode alone still allows filesystem access and DuckDB setting changes. The local server and hosted remote service have different boundaries. A data-write restriction is insufficient evidence of host isolation for third-party access.
Read the complete tool trust profile
Review scope: Publisher local DuckDB/MotherDuck server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
MotherDuck publishes the local server; the buyer operates a self-hosted instance.
Host isolation, token scope and third-party deployment controls have not been tested.
Not established
Suggested refusal or clarification condition
Require host-access evidence before treating self-hosted read-only access as isolated.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck local server version, exposed transport and host restrictions.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the distinction between database write protection and host isolation.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a read-only database connector isolate the host filesystem?
Can a self-hosted query tool change local settings?
How does MotherDuck local MCP differ from the remote service?
Which identity does a local database connector use?
What should I check before giving third parties query access?
Does disabling writes prevent every sensitive host operation?
Can database switching expand the available data?
Does local execution keep query results away from the AI client?
What evidence supports a host-isolation claim?
Can I preserve the documented local-server boundary?
Which server version was reviewed for read-only behaviour?
When should a local query connector be reassessed?
dbt MCP: Server variants and capability uncertainty
Can a dbt remote MCP connection replace every local development workflow?
No. dbt distinguishes the remote consumption service from self-hosted local development. API availability also depends on the plan. The overview contains overlapping Administrative API descriptions and a broad read-only statement, so it does not settle every operation: inspect the actual tool list before approving job or development actions.
Read the complete tool trust profile
Review scope: Self-hosted and remote server documentation
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
dbt provides the remote service and publishes the self-hosted server.
Effective tool definitions and Administrative API write coverage remain unverified.
Not established
Suggested refusal or clarification condition
Clarify the server variant and operation when the overview is insufficient.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck tool definitions, Administrative API wording and plan changes.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save documented variant limits and the unresolved capability question for supplier follow-up.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can remote dbt MCP perform every local development task?
Does a dbt plan include every API behind MCP?
What should I do when tool documentation conflicts with a read-only claim?
Which dbt server variant supports local CLI work?
Can an agent use Semantic Layer data without local installation?
Does turning off AI features disable all dbt MCP tools?
What evidence establishes an administrative tool can change state?
Which job artifacts are still available for retrieval?
Can a saved source review replace inspecting the tool list?
How should procurement record an unresolved capability claim?
Can I preserve the dbt variant ambiguity for follow-up?
ClickUp MCP: Task changes, time entries and usage limits
Does the absence of ClickUp deletion tools make an agent connection read-only?
No. ClickUp documents task changes, comments and time tracking while its FAQ says deletion tools are not currently included. It also requires OAuth and applies plan/add-on-dependent usage limits. Review the intended write actions and workspace before treating the connection as a reporting-only integration.
Read the complete tool trust profile
Review scope: Hosted OAuth server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer grants, workspace settings and remaining usage budget are unverified.
Not established
Suggested refusal or clarification condition
Require the target workspace and intended write before changing work records.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck deletion-tool availability, role restrictions and usage policy.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the task-action and usage-limit evidence behind a work-assistant review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does lacking delete tools make a work assistant read-only?
Can ClickUp MCP log time on my behalf?
Does a status-report request authorise posting a comment?
Can a personal API key authenticate ClickUp MCP?
Which workspace budget applies to tool calls?
Does an Everything AI add-on change MCP limits?
Can ClickUp MCP search connected external apps?
What should I verify before changing task assignees?
Does reconnecting reset a rolling usage limit?
Which work actions need explicit task scope?
Can I save the evidence behind a ClickUp onboarding decision?
When should a reporting connector be reviewed again?
Does connecting Todoist for a daily review also expose task-changing tools?
Yes. Todoist documents a hosted OAuth MCP service with task and project reads, creation and updates. A planning or review request should specify whether the agent may change the plan. The overview does not establish a buyer-specific read-only grant.
Read the complete tool trust profile
Review scope: Hosted task and project server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer sharing arrangements and precise granted scopes are unverified.
Not established
Suggested refusal or clarification condition
Clarify whether the request is advice or an authorised task update.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck tool scopes and project-sharing changes.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the capability boundary used when approving a personal or team planning assistant.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a daily-review assistant also change my tasks?
Does Todoist MCP expose project creation?
Which account is connected to the planning agent?
Can a review request remain suggestions only?
What evidence shows a Todoist grant is read-only?
Will task descriptions be returned to an external assistant?
Should an agent ask before changing project plans?
How should I scope a task rescheduling request?
Does a successful connection prove every project is accessible?
What should I save about a planning connector grant?
Can I retain the source version for a Todoist review?
When should task-sharing changes trigger another review?
Does enabling Glean MCP mean any assistant can access all company knowledge?
No. Glean documents per-user access, tenant-controlled server availability and application-registration controls. The organisational connector is distinct from the public documentation MCP. Review the selected tenant server, permitted client and configured tools; connection success alone does not establish the audience or allowed actions.
Read the complete tool trust profile
Review scope: Tenant-specific knowledge and configured tools
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Glean operates the tenant-specific remote MCP service.
Buyer client approval, configured actions and user entitlements are unknown.
Not established
Suggested refusal or clarification condition
Require the tenant server and enabled tool list before approving organisational access.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck application registration policy, configured tools and user access.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the identity and client-registration checks used for enterprise search onboarding.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does enabling an enterprise search connector grant access to everyone?
Which identity governs Glean search results?
Is the public Glean documentation server connected to company data?
Can administrators restrict which MCP clients register?
What if an assistant cannot complete Glean OAuth?
Does a configured tool necessarily provide read-only search?
Which tenant server should a buyer review?
Can hiding the configurator explain a failed connection?
What evidence supports an enterprise knowledge access decision?
Does connection success prove a client is approved for sensitive data?
Amplitude MCP: User identities and analytics changes
Does an Amplitude analytics connection only retrieve charts?
No. Amplitude describes querying behaviour alongside cohort, experiment and taxonomy workflows. User OAuth and service-account OAuth are separate identity choices, with existing permissions applying. Distinguish organisational MCP access from public documentation access and review the allowed read and write actions.
Read the complete tool trust profile
Review scope: Hosted organisation analytics server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer identity grants and client data handling are unverified.
Not established
Suggested refusal or clarification condition
Clarify write authority before changing cohorts, experiments or taxonomy.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck service-account permissions, regional endpoint and tool capabilities.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the identity and operational scope behind an analytics-agent decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can an analytics assistant do more than retrieve charts?
Which identity does an unattended Amplitude agent use?
Does public documentation access expose organisation data?
Can an Amplitude agent change cohort definitions?
What should I check before allowing experiment changes?
Which permissions distinguish analytics reads from writes?
Does a free MCP connection eliminate AI-client costs?
Which regional analytics endpoint should a review identify?
Can session-replay information enter the connected assistant?
What evidence supports an analytics service-account grant?
Can I preserve an Amplitude capability review?
When should an analytics automation grant be rechecked?
Mixpanel MCP: Verified labels and operational tools
Does Mixpanel Verified Mode exclude unverified entities from MCP results?
No. Mixpanel says requested entities remain in results; unverified ones are flagged and verified equivalents are preferred where available. The connector also exposes write tools. Review result labels and operation permissions separately rather than treating Verified Mode as either data exclusion or read-only access.
Read the complete tool trust profile
Review scope: Hosted analytics server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer grants and availability of individual beta tools are unknown.
Not established
Suggested refusal or clarification condition
Preserve verification labels and clarify the authority for writes.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck Verified Mode behaviour, beta availability and project grants.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save how verified/unverified evidence was interpreted for an analytics review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does Verified Mode remove unverified analytics data?
Can an agent mistake a preferred metric for a guaranteed one?
Which Mixpanel identity governs project access?
Can an analytics connector update dashboards?
What should I retain about an unverified event?
Does a service account use my personal project permissions?
Which MCP features are still in beta?
Can a query-only task use a connection with write tools?
What evidence should procurement request for analytics labels?
Does an enabled connector establish data quality?
Can I save the reviewed Mixpanel result boundary?
When should project access and metric verification be reassessed?
Does free PostHog MCP access mean every operation has no additional usage cost?
No. PostHog says MCP access and calls are free, while some tools invoke LLMs internally and may incur PostHog AI spend. The connector supports reads and writes across products. Review AI processing settings, the selected project and the intended action separately from the connection price.
Read the complete tool trust profile
Review scope: Hosted regional server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer usage limits, AI processing approval and identity rights are unknown.
Not established
Suggested refusal or clarification condition
Clarify action and spending authority before AI-powered or mutating work.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck AI billing, processing settings and enabled product tools.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the documented cost and action distinctions for analytics-agent approval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a free MCP connection make AI-powered tools free?
Can an analytics agent change a feature flag?
Which PostHog operations may incur AI spend?
Does disabling AI processing hide some tools?
What should I check before authorising an analytics write?
Can error details reach my connected assistant?
Which regional PostHog project is selected?
Does connecting a tool establish a spending budget?
What evidence separates connector fees from internal AI costs?
Can I save the cost boundary for a PostHog review?
Which permissions remain unverified by a public overview?
When should AI processing and spending authority be rechecked?
Render MCP: Workspace selection and deployment effects
Does read-only SQL support mean Render MCP cannot change my application?
No. Render lists read-only SQL alongside service creation, environment-variable updates and redeployment. Actions use the selected workspace. A database inspection task therefore needs a narrower authorised scope than the complete connector capability set.
Read the complete tool trust profile
Review scope: Hosted server with local alternative
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Render operates the hosted MCP and publishes a local alternative.
Buyer workspace rights and intended deployment state are unverified.
Not established
Suggested refusal or clarification condition
Require the target service and change authority before redeployment or configuration updates.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck selected workspace, account access and hosted tool additions.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the distinction between database inspection and application-changing capability.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does read-only SQL make a hosting connector read-only?
Can Render MCP change environment variables?
Which workspace will an agent deploy into?
Does a troubleshooting request authorise redeployment?
Can an agent create a billable hosting resource?
What evidence identifies the intended Render service?
Can database results enter the coding assistant?
Does running the connector locally stop remote effects?
Which identity authenticates an unattended Render connection?
What should I save before approving an application change?
Can I retain the source-bound Render capability review?
When should a hosting-agent permission review be repeated?
Can a Railway project token restrict an MCP agent to one project?
The current documentation says project tokens are not accepted: MCP requires a user identity. OAuth can select workspaces and projects, while the default CLI bridge reuses the login session. Destructive-action hints depend on client support, so verify both the grant and confirmation behaviour.
Read the complete tool trust profile
Review scope: Hosted server, CLI bridge and local alternative
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Railway operates the hosted server and publishes its CLI integration.
Buyer grant and actual client confirmation behaviour are unknown.
Not established
Suggested refusal or clarification condition
Require scoped identity evidence and authorised deployment intent.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck OAuth selections, CLI variant and confirmation support.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the identity and confirmation assumptions behind a hosting-agent approval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a project token authenticate Railway MCP?
Does a local CLI bridge still call a hosted service?
Which login identity does Railway MCP reuse?
Can OAuth narrow the projects visible to an agent?
Do destructive hints guarantee a confirmation prompt?
How does the local Railway tool set differ?
Can a debugging tool delegate multiple operations?
Does accepting staged changes also deploy them?
What evidence should I retain about a Railway grant?
Can an agent change project feature flags?
Can I save the documented confirmation boundary?
When should a hosting-client approval policy be retested?
Firebase MCP: CLI identity, core tools and remote requests
Does limiting Firebase MCP feature groups remove every other capability?
No. Firebase says core tools remain available when feature groups are selected. The local server inherits Firebase CLI credentials, and some tools proxy requests to remote services. Review identity, project context and the complete exposed tool list rather than assuming local execution or a feature filter is complete isolation.
Read the complete tool trust profile
Review scope: Local stdio server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer credentials, core-tool configuration and cloud permissions are unverified.
Not established
Suggested refusal or clarification condition
Check identity and complete tool exposure before approving cloud changes.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck CLI identity, project context and core-tool changes.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the inherited-identity and feature-filter boundaries for a Firebase agent review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Do selected feature groups remove all other Firebase MCP tools?
Which identity does a local Firebase connector inherit?
Can a local tool proxy requests to cloud services?
Does local execution prove application data stays local?
What project context will the Firebase agent use?
Can an assistant manage authentication users?
Does a data-reading task permit cloud messaging?
Which core tools remain available after filtering?
What evidence establishes the active CLI identity?
Can I save a Firebase permission review before onboarding?
Does a feature group name establish read-only access?
When should inherited credentials trigger another review?
Does connecting Resend for support drafting authorise the agent to send email?
No. Resend documents both drafting workflows and transactional sending, plus contact and webhook operations. OAuth grants or API-key access establish technical capability, not the requested business action. Identify whether the task ends at a draft or an authorised send and verify the recipient scope.
Read the complete tool trust profile
Review scope: Hosted email platform server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer grant, recipient authorisation and client retention are unknown.
Not established
Suggested refusal or clarification condition
Require explicit send authority and recipient scope before external delivery.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck account permissions, enabled tools and recipient policy.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the draft/send distinction used when approving an email agent.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does support drafting authorise an agent to send email?
Can Resend MCP change contact segments?
Which account is selected during email connector consent?
Can a headless agent use an API key instead of browser login?
What evidence separates a draft from a delivered email?
Where can Resend OAuth permissions be revoked?
Can an agent inspect webhook delivery history?
Does technical send access establish recipient consent?
What should I review before automated transactional sends?
Can I preserve the documented email-action boundary?
Which client can see returned email context?
When should email-agent permissions be reassessed?
Cloudinary MCP: Product environments and media operations
Does enabling Cloudinary media analysis also define every available asset action?
No. Cloudinary documents separate servers for asset management, configuration, metadata, analysis and MediaFlows. Their authentication options also differ. Review the enabled servers, selected product environment and available tools; analysis access alone is insufficient evidence about upload, deletion or configuration authority.
Read the complete tool trust profile
Review scope: Asset, configuration, metadata and analysis services
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Cloudinary hosts remote services and publishes local alternatives.
Buyer tool configuration, media rights and effective credentials are unknown.
Not established
Suggested refusal or clarification condition
Identify the cloud and permitted action before asset deletion or configuration changes.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck installed plugin contents, server roles and authentication differences.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the selected-server and media-action boundary for a connector review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a media-analysis connector also expose asset deletion?
Which Cloudinary product environment will the agent use?
Do all Cloudinary MCP servers accept the same credentials?
Can a plugin enable multiple media server roles?
What evidence separates analysis from configuration access?
Can an assistant rename or upload media assets?
Does a transformation request authorise deleting an original?
Which tools are enabled for structured metadata?
What should I record before approving a media connector?
Can returned media content enter the connected assistant?
Can I save the reviewed Cloudinary environment boundary?
When should an installed media plugin be reviewed again?
Algolia MCP: Public search, user analytics and code examples
Does every Algolia MCP connection access and modify my search indices?
No. Current documentation distinguishes application-scoped Public MCP, user-scoped Productivity MCP and DevEx code generation. Public and Productivity are read-only; DevEx does not access application data. Identify the offering before claiming either data access or write capability.
Read the complete tool trust profile
Review scope: Public, Productivity and DevEx services
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Algolia operates the three documented MCP offerings.
Buyer Public-MCP grants and selected indices have not been inspected.
Not established
Suggested refusal or clarification condition
Identify the offering and scope before asserting data access or change capability.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck offering definitions, selected indices and user permissions.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the offering distinction for a search-connector procurement decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can an Algolia MCP connector modify search indices?
Does code-generation MCP access my application data?
How does public search differ from user analytics access?
Which indices can a customer-facing assistant search?
Does enabling Productivity MCP sign in every user?
What evidence identifies the Algolia offering in use?
Can a generated code snippet prove a live query occurred?
Does a free connection remove normal plan usage?
Which user permissions govern internal search analysis?
Can I save the source version for an Algolia access review?
Should an agent clarify which search connector was configured?
When should application search scope be rechecked?
PayPal MCP: Merchant identity and sandbox separation
Does a successful PayPal MCP sandbox call establish a live merchant outcome?
No. PayPal documents separate sandbox and production settings and endpoints. Local access tokens and remote client-credential setup also need the intended account context. A sandbox result is testing evidence; it does not establish that a real payment, invoice or other production action completed.
Read the complete tool trust profile
Review scope: Local and remote merchant connectors
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
PayPal publishes the local connector and operates remote endpoints.
Live permissions, payment status and tool-level effects have not been verified.
Not established
Suggested refusal or clarification condition
Require environment and verified operation evidence before reporting a live financial outcome.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Recheck environment, merchant credentials and supported tool definitions.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the environment and evidence distinction used in a merchant-connector review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a sandbox tool result prove a live payment occurred?
Which PayPal merchant account is connected to the agent?
How do sandbox and production MCP endpoints differ?
Does local connector execution still reach PayPal?
What evidence establishes the enabled merchant tool set?
Can an invoice lookup prove money was received?
Should an agent clarify the intended payment environment?
Does a successful login authorise every merchant action?
What should I retain from a payment-connector onboarding review?
Can I save the reviewed PayPal sandbox boundary?
Which credential mode does the remote connector document?
When must live operation evidence be checked separately?
Pulumi MCP: Organisation selection and Neo actions
Can a Pulumi inventory question start paid infrastructure work?
Most tools retrieve information or instructions, but the Neo bridge can start billed tasks and pass approvals that let Neo change infrastructure. The documentation also describes fallback organisation selection. Verify the organisation and enabled tools before treating the connection as inventory-only.
Read the complete tool trust profile
Review scope: Hosted Pulumi MCP with optional Neo bridge
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
The buyer token, selected organisation and Neo limits were not inspected.
Not established
Suggested refusal or clarification condition
Clarify the target and authority before starting or approving Neo work.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Organisation fallback, Neo capability and billing changes.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve why an inventory-only approval excluded Neo work and which organisation needed checking.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can an inventory assistant start paid cloud work?
Does a Pulumi read role prevent every Neo task?
Which organisation will my infrastructure agent use?
What happens when the Pulumi organisation header is wrong?
Can a Neo approval permit infrastructure changes?
Is generating deployment guidance the same as deploying?
Which tool should an inventory-only review exclude?
Does connecting Pulumi also authorise spending?
What should I retain before approving Neo access?
Can a cloud inventory request open a pull request?
Terraform MCP: Tool selection is separate from destructive-operation gating
Does disabling destructive Terraform operations make MCP read-only?
The operation switch gates specified destructive actions, not every write. The reference also lists project, team and access-grant creation. Omitting toolset selection enables all toolsets, with authenticated management tools depending on the token. Review the actual tool list and token permissions.
Read the complete tool trust profile
Review scope: HashiCorp Terraform MCP registry and management toolsets
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Effective token access and server configuration are unverified.
Not established
Suggested refusal or clarification condition
Do not call the connection read-only without checking each exposed operation.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. New tools, default toolsets and operation-gate coverage.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the distinction between a destructive-operation gate and an approved management-tool set.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a Terraform connector write with destructive operations disabled?
Does omitting toolsets enable only public documentation?
Can my agent create a project without deleting resources?
Which Terraform token permissions should procurement request?
Does registry access require management credentials?
Can a tool grant another team access?
What is the difference between toolsets and individual tools?
Can a run be created before apply is approved?
Which actions remain behind the destructive-operation switch?
How should I evidence a read-only Terraform connection?
Does a management token widen the advertised tool set?
What should be saved before approving infrastructure automation?
Vault MCP: Secret disclosure and beta-use boundaries
Does keeping secrets in Vault keep them out of an AI client?
Not when an authorised MCP query returns them. The Vault MCP page explicitly warns that secret data can reach clients and models, and describes both read and write operations. It labels the feature beta and discourages production deployment. This review does not establish a buyer-specific access policy.
Read the complete tool trust profile
Review scope: Vault MCP beta for KV and PKI operations
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Credential policy, mounted engines and client handling are unverified.
Not established
Suggested refusal or clarification condition
Require credential and client-handling evidence before relying on secret isolation.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Beta status, supported engines and authentication documentation.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the documented disclosure and beta limitations when assessing a secrets connector.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a secrets connector reveal stored credentials to a model?
Does encrypted storage prevent authorised secret retrieval?
Is the Vault MCP feature documented for production use?
Can this connector issue a certificate?
Does a secrets assistant also change mounts?
Which client receives returned Vault data?
What evidence is missing for a path-level access claim?
Can a secret lookup become a write operation?
Which mounts should an agent review cover?
Does a Vault product claim establish MCP deployment safety?
When should secret isolation remain unproven?
What should I save before approving a Vault connector?
Auth0 MCP: Tenant changes and local credential files
Can an Auth0 onboarding assistant change the tenant and write local credentials?
Yes. The README describes onboarding that creates an application and saves its credentials to a project environment file. It also documents read-only and tool-selection controls. Assess both tenant authority and local file output; merely describing the task as setup does not narrow either.
Read the complete tool trust profile
Review scope: Official local Auth0 management MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Actual consent, file permissions and effective tenant access are unknown.
Not established
Suggested refusal or clarification condition
Clarify tenant changes and credential-file handling before onboarding.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Onboarding composition, tool filters and credential-storage behaviour.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep a review of tenant authority separate from permission to create local credential files.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can an authentication assistant write credentials into my project?
Does Auth0 onboarding create a tenant application?
How do Auth0 read-only and tool filters combine?
Can an integration review alter callback settings?
Which tenant does my authentication assistant control?
Does a setup task require file-write approval?
What evidence supports limiting the connector to logs?
Can an agent publish an Auth0 form?
Where should credential handling appear in a tool review?
Do client tool names prove effective tenant permissions?
WorkOS MCP: Role inheritance, environment and write controls
Does the WorkOS sandbox default prevent production changes?
The default target is sandbox, but production access and writes are separately controlled and initially enabled in the documented team settings. The agent inherits the dashboard user role. Check those settings and the requested environment; the sandbox default alone is not a production-access restriction.
Read the complete tool trust profile
Review scope: Hosted WorkOS management MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Team settings and the buyer role were not inspected.
Not established
Suggested refusal or clarification condition
Confirm production authority before changing the target environment.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Team-control defaults, role inheritance and excluded operations.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the difference between a default target and an enforced production/write restriction.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a sandbox default block production access?
Which role does a WorkOS agent inherit?
Can team admins disable only MCP writes?
Can a user with read-only access gain writes through MCP?
Does the WorkOS connector return existing API secrets?
Can the agent change its own access controls?
Is an agent confirmation proof of human approval?
Which team can the connection reach?
What should procurement request about production access?
Can a connector set a supplied secret without reading it back?
Does successful OAuth prove the intended environment?
Infisical MCP: Tool restrictions and secret-value masking
Does a read-only Infisical tool list keep secret values out of model context?
Read tools can return values. The README documents a separate masking option that defaults off and still returns metadata when enabled. A tool allowlist limits exposed operations, while identity scope limits underlying access. Review all three before claiming that the connector hides secrets.
Read the complete tool trust profile
Review scope: Official local Infisical MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer identity scope and selected host are unverified.
Not established
Suggested refusal or clarification condition
Require explicit value-handling approval before unmasked secret reads.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Masking defaults, allowlist enforcement and new secret tools.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve which control limits operations, which limits identity scope and which masks returned values.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can read-only secret tools reveal secret values?
Is Infisical value masking enabled by default?
What remains visible when secret values are masked?
Does hiding a tool also reject direct calls to it?
Which identity scopes restrict a secrets assistant?
Can the Infisical connector invite project members?
Does a custom host change where secret requests go?
What should a metadata-only secret review verify?
Can a broad token outlive a narrow tool configuration?
Which control prevents unwanted secret writes?
When should unmasked secret retrieval need clarification?
Bitwarden MCP: Vault reads, organisation administration and file access
Does protecting the master-password prompt prevent an agent from reading vault items?
The documented unlock dialog keeps the master password outside MCP, but retrieval tools can still return vault items after unlock. Organisation API credentials enable a separate administrative surface. File-based tools require an allowed-directory setting. Review these distinct authorities rather than treating secure unlock as a complete disclosure boundary.
Read the complete tool trust profile
Review scope: Official local MCP with vault CLI and organisation API capabilities
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer vault scope, organisation rights and file boundaries are unknown.
Not established
Suggested refusal or clarification condition
Confirm permitted item disclosure and administration separately.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Unlock flow, file allowlist and organisation API tools.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the separate decisions for unlocking, reading items, changing organisation resources and accessing files.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a password-manager agent read items after secure unlock?
Does protecting the master password hide every vault secret?
Which credentials enable Bitwarden organisation administration?
Can a vault assistant invite organisation members?
Are local file operations enabled without directory approval?
Can an agent create a file-sharing Send?
Which permissions should a vault review distinguish?
Does a locked vault affect organisation API access in the same way?
What data can leave through item retrieval?
Can a headless client use the interactive unlock dialog?
When should vault disclosure require clarification?
Can I preserve a password-manager connector review?
Doppler MCP: Read-only tools and token enforcement
Do Doppler MCP scope flags enforce access beyond the connector?
The documentation distinguishes tool filtering from token-enforced API access. Read-only mode hides write tools, but does not stop other ways an agent might attempt writes. Project/config flags also are not a substitute for scoped credentials. Secret reads remain part of the advertised capability.
Read the complete tool trust profile
Review scope: Experimental local Doppler MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer token and other agent execution channels are unverified.
Not established
Suggested refusal or clarification condition
Do not claim enforced read-only access from a tool flag alone.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Experimental status, scope flags and token enforcement guidance.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the evidence separating connector filtering from the credential boundary.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a read-only connector flag restrict the underlying token?
Can a secret-reading assistant attempt writes through another tool?
Do Doppler project flags guarantee project isolation?
Which permission boundary does the Doppler API enforce?
Can read-only mode return secret values?
What should procurement request about token scope?
Is the Doppler MCP server described as experimental?
Can a shared workstation reuse cached authentication?
Which configuration identifies the intended secret environment?
Does a hidden write tool mean no write authority exists?
Contentstack MCP: Delivery reads versus management and automation
Does connecting a content delivery tool also enable publishing or deployments?
Contentstack separates delivery, management, automation and deployment tool groups. Delivery retrieves published content, while other groups expose state-changing operations and use different credentials. Review the loaded groups and corresponding credentials; a content-oriented connector name does not establish a read-only surface.
Read the complete tool trust profile
Review scope: Local Contentstack MCP with selectable product groups
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer token scope, region and group selection are unknown.
Not established
Suggested refusal or clarification condition
Confirm publishing, automation and deployment authority separately from reading.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Group membership, authentication methods and endpoint overrides.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the approved product groups and the distinction between content delivery and operational changes.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a CMS lookup connector also publish content?
Which Contentstack group only reads published content?
Does loading all groups add deployment tools?
Do delivery and management use the same credentials?
Can a content assistant trigger an automation?
Which region receives a content request?
What should procurement request about loaded tool groups?
Does OAuth availability establish every product permission?
Can custom endpoints change the data destination?
Which evidence separates drafting from publishing?
When should content-agent actions need clarification?
Can I preserve a content-platform access decision?
Twilio Docs MCP: API discovery without account execution
Can the Twilio documentation MCP send a message or read my account?
This documented variant searches public specifications and retrieves documentation. It requires no account authentication and does not execute Twilio API calls. It also defaults to the latest available API version. Confirm the intended version; do not treat documentation retrieval as proof of an account action.
Read the complete tool trust profile
Review scope: Hosted public documentation MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Search completeness and buyer integration compatibility are untested.
Not established
Suggested refusal or clarification condition
Do not report a message sent or account inspected from a documentation result.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Beta status, version defaults and introduction of authenticated execution variants.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save which API version and documentation supported an integration decision without implying execution.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a Twilio docs connector send SMS?
Does the Twilio documentation server access my account?
Why does API search show a different version?
Which connector only retrieves public specifications?
Does reading an endpoint schema execute it?
What evidence proves a messaging action completed?
Can documentation search replace account authorisation?
Which API version should an agent request?
Is the Twilio docs service documented as beta?
Can a saved schema review prove integration compatibility?
When should an agent distinguish instructions from execution?
Can I save a version-specific Twilio documentation review?
Contentful MCP: Protected environments are an opt-in connector guard
Does the Contentful MCP environment guard block every possible write?
The local server documents an opt-in, case-sensitive environment guard. It blocks environment-scoped write/delete calls but leaves reads and specified organisation-level or generation operations outside that guard. Other clients are unaffected. Review both the guard and underlying permissions before treating an environment as protected.
Read the complete tool trust profile
Review scope: Official local Contentful MCP for the Management API
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Contentful publishes the local Management API server.
Buyer roles and protection settings have not been verified.
Not established
Suggested refusal or clarification condition
Do not claim universal write prevention from the connector guard.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Guard coverage, default environment and organisation-scoped tools.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the exact scope and exceptions of a protected-environment approval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a CMS protected-environment setting block all writes?
Is Contentful MCP environment protection enabled by default?
Does environment ID capitalisation matter?
Can another client still change a protected environment?
Are organisation-level concepts covered by the same guard?
Can AI generation run while environment writes are blocked?
Which token governs Contentful management access?
Does the default environment identify the intended target?
Can a content assistant export data locally?
What should a publication permission review record?
When should a protected-environment claim remain qualified?
Does Strapi MCP audit logging prove every content read was recorded?
The documentation describes permission checks for tools, fields, locales and individual documents. It separately states that MCP entry actions require the documented version and Enterprise audit entitlement, and content-only reads are not logged. Permission enforcement and activity-record completeness therefore need separate evidence.
Read the complete tool trust profile
Review scope: Built-in Strapi CMS MCP endpoint
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Strapi provides the endpoint; the buyer operates its CMS deployment.
Buyer entitlement, plugin inventory and actual audit records are unverified.
Not established
Suggested refusal or clarification condition
Do not assert complete read auditing from MCP support.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Audit version/plan conditions, plugin capabilities and schema compatibility.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the separate permission and audit-coverage questions for a CMS procurement review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is every CMS agent read and write recorded in audit logs?
Which Strapi token controls MCP permissions?
Can fields be hidden while other content remains readable?
Can a content token allow one locale but not another?
Are permissions checked only when the tool list is loaded?
Can a plugin expand the Strapi MCP action surface?
Why might an allowed CMS tool disappear in a client?
Does Strapi audit entitlement depend on plan and version?
Can a read-only content task leave no entry-action audit event?
What evidence proves a particular document action was allowed?
When should CMS audit completeness remain unproven?
Can I retain a Strapi permission and audit review?
New Relic MCP: Identity, feature switches and tool availability
Does a working New Relic API key provide all MCP analysis tools?
No. The overview distinguishes OAuth-only tools from API-key access and requires organisation-level permission plus relevant feature switches. Preview and API-key access have separate controls. A successful connection therefore does not establish access to every analysis capability or every account dataset.
Read the complete tool trust profile
Review scope: Hosted Ground Truth MCP access
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Actual data access and the complete deployed tool set are unverified.
Not established
Suggested refusal or clarification condition
Request tool and account evidence before claiming complete analysis access.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. OAuth-only tools, feature defaults and usage entitlement.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save why a successful login did not establish the required analysis or data entitlement.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does an observability API key unlock every agent tool?
Why is a New Relic analysis tool missing after login?
Which MCP capabilities require OAuth?
Does organisation permission prove account data access?
Are preview tools enabled with the main MCP switch?
Can local-client access differ from API-key access?
What should procurement request for a required analysis tool?
Does a connection test prove complete telemetry coverage?
Which client receives returned observability data?
Can a tool list establish that no writes exist?
When should analysis entitlement remain unverified?
Can I save a New Relic connector eligibility review?
CircleCI MCP: Diagnostic reads and workflow actions
Can a CircleCI troubleshooting connector rerun or cancel builds?
The hosted tool list includes rerunning and cancelling workflows as well as diagnostic reads. The CLI MCP exposes a broader command surface, so it needs a separate review. Identify the variant, project and intended action before treating a troubleshooting request as permission to alter CI state.
Read the complete tool trust profile
Review scope: Hosted CircleCI MCP compared with CLI MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer project permissions and local CLI command surface are unverified.
Not established
Suggested refusal or clarification condition
Clarify rerun or cancellation authority before changing shared CI state.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Hosted tool list, CLI command changes and deprecated client guidance.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the boundary between diagnosing a failed run and authorising its rerun or cancellation.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a CI troubleshooting assistant rerun jobs?
Does CircleCI MCP only read build logs?
How does hosted CircleCI MCP differ from CLI MCP?
Which identity controls the accessible project?
Can cancelling a workflow affect another developer?
Does a failed-test listing include passing tests by default?
Which workflow should a rerun request identify?
Does connecting a CI tool authorise deployments indirectly?
What should a diagnostic-only approval record?
Can stale tool definitions hide a newly added action?
Buildkite MCP: Version control and incomplete failure evidence
Does a Buildkite MCP failure summary mean the job is finished and evidence is complete?
No. The documentation distinguishes promised failure from a final job result and warns that investigation summaries can be partial. Remote endpoints update automatically; version pinning requires the local server. Confirm final status, missing evidence and write restrictions before relying on a CI review.
Read the complete tool trust profile
Review scope: Remote and local Buildkite MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Buildkite hosts remote MCP and publishes a local server.
Installed version, actual access and evidence completeness are unverified.
Not established
Suggested refusal or clarification condition
Do not report a final outcome until final status and missing evidence are checked.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Remote tool changes, local pinned version and investigation result coverage.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the reviewed distinction between an early failure signal and a completed, sufficiently evidenced result.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a CI failure signal prove a job has finished?
Can a Buildkite summary omit logs or test evidence?
Can the hosted Buildkite MCP version be pinned?
Does connecting Buildkite start a background watcher?
What does a blocked build mean to a waiting tool?
Can read-only toolsets coexist with a write-capable connection?
Which identity authorises a build retry?
Can starting a build indirectly run a deployment?
What evidence should follow an early promised failure?
Does a short monitoring call watch indefinitely?
When should a CI result stay provisional?
Can I preserve a Buildkite evidence-completeness review?
Harness MCP: Default targets are separate from access restrictions
Do Harness MCP default organisation and project settings prevent other targets?
The README describes those settings as defaults used when calls omit identifiers; agents can discover and supply other targets. Read-only mode separately blocks mutating operations and defaults off. Hosted OAuth and local credentials also differ. Review effective permissions rather than treating defaults as an access allowlist.
Read the complete tool trust profile
Review scope: Local/self-hosted MCP and managed hosted alternative
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Harness publishes the server and offers a managed hosted option.
Buyer roles, deployment mode and actual target are unverified.
Not established
Suggested refusal or clarification condition
Confirm effective target permissions before relying on default identifiers.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Mode-specific authentication, read-only defaults and target selection.
Record history: 2026-10-14 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the distinction between convenience defaults, credential authority and write restrictions.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a default project restrict every agent action?
Can a Harness agent discover other organisations?
Is Harness MCP read-only by default?
Which calls remain permitted in read-only mode?
Does a local API token configure hosted Harness MCP?
Can a client change the managed endpoint environment?
Are host-header restrictions the same as authentication?
Which permission evidence supports an approved pipeline target?
Can execute operations run when only inspection was intended?
What changes when an MCP server serves multiple users?
When should a default-target claim remain qualified?
Chrome DevTools MCP: Browser state and optional data sharing
What can a Chrome DevTools agent see or change in my browser session?
The publisher exposes browser inspection and automation, including page interaction and diagnostic capture. Browser content becomes available to the connected agent. Performance features can send trace URLs to the CrUX service, and usage statistics have a documented opt-out. Browser attachment is not a general security sandbox.
Read the complete tool trust profile
Review scope: Publisher local server attached to a Chrome browser instance
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Published by the Chrome DevTools team; the buyer runs the local server and browser.
The buyer browser profile, logged-in sessions, enabled telemetry and client handling are unknown.
Not established
Suggested refusal or clarification condition
Do not attach a privileged browsing session without authority for its contents and intended actions.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Attachment modes, telemetry defaults, output storage and browser permissions.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the browser-session and data-recipient questions needed before authorising browser automation.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a browser tool read my signed-in pages?
Does Chrome DevTools MCP expose network responses?
Can the agent execute code in a page?
Can browser diagnostics write files locally?
Are trace URLs sent to another service?
Can I disable Chrome MCP usage statistics?
Does a target URL check provide a full sandbox?
How should untrusted page text be handled?
Which browser profile should procurement identify?
Does closing the client remove diagnostic files?
What evidence supports isolating a browser session?
Can I save the reviewed browser access boundaries?
Microsoft Learn MCP: Public documentation, not tenant inspection
Can Microsoft Learn MCP verify how my Microsoft tenant is configured?
The public server searches and fetches Microsoft documentation and code samples without authentication. It does not inspect the buyer tenant. Its tool definitions can change, and optional search token budgets can truncate results. A documentation answer is therefore a starting point for a configuration review, not evidence that a control is enabled.
Read the complete tool trust profile
Review scope: Public hosted documentation server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Microsoft publishes the hosted Learn documentation server.
Tenant settings, licensed features and current application behaviour are not observed.
Not established
Suggested refusal or clarification condition
Require tenant evidence before converting a documentation description into an enabled-control claim.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Tool schema, document versions and search-output limits.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the distinction between a published feature and a control demonstrated in the buyer environment.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Learn MCP inspect my Entra tenant?
Which Microsoft documentation tools are exposed?
Does the Learn endpoint require a tenant token?
Can a documentation search change Azure resources?
Does a code sample prove my configuration works?
Can a search token budget truncate evidence?
Should an agent refresh the tool list after a schema error?
Can I fetch the full article behind a search result?
What tenant evidence is still required?
Does public documentation establish feature entitlement?
When is free documentation retrieval sufficient?
Can I preserve the reviewed Learn capability limits?
Hugging Face MCP: Discovery can extend into jobs and third-party tools
Is Hugging Face MCP limited to searching public models and datasets?
The reviewed offering combines discovery with optional repository contributions, jobs, sandboxes and Space tools. Enabled capabilities depend on configuration. A Space introduces its own execution and data-handling context; authorising Hub search does not establish authority for every optional write or compute operation.
Read the complete tool trust profile
Review scope: Hosted Hub MCP with configurable tools and optional Spaces
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Hugging Face publishes the Hub server; selected Spaces may have other operators.
Enabled tools, private-resource access, Space operator and costs are unknown.
Not established
Suggested refusal or clarification condition
Require separate authority for writes, compute and disclosure to an unfamiliar Space.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Enabled tools, Space ownership, credentials and compute terms.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve which optional tools and recipients were authorised for the intended workflow.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Hugging Face MCP write repository files?
Are jobs available through the same MCP offering?
Who operates a selected Hugging Face Space?
Can a search request lead to dynamic Space tool calls?
Which enabled tools consume compute?
Does public model search need private repository access?
Where will a Space tool receive my input?
Which account scopes apply to this configuration?
Can sandbox tools manage files?
Should tool definitions be refreshed after configuration changes?
JFrog MCP: Artifact discovery and administrative operations
Can an agent treat the JFrog MCP server as an artifact search-only integration?
No. The published tool inventory includes repository configuration, access-token operations and other administrative capabilities as well as reads. A Platform Admin enables the integration, and experimental tools require a separate selection. Review the actual available tools and effective identity before authorising a search-only workflow.
Read the complete tool trust profile
Review scope: Platform-enabled server with separately selectable Beta tools
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
JFrog publishes the integration within the JFrog Platform.
Buyer permissions, enabled Beta tools and exact server version are unknown.
Not established
Suggested refusal or clarification condition
Decline token or configuration changes outside the expressly authorised task.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Platform tool inventory, Beta enablement and identity grants.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep a version-bound record of the search-versus-administration boundary.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does JFrog MCP expose token administration?
Can a repository search toolset also change configuration?
Who enables the JFrog MCP integration?
Are Beta tools enabled separately?
Which JFrog identity executes a tool call?
Can an agent inspect security reports without repository writes?
What data is returned to the MCP client?
Does platform activation prove least privilege?
Which operations need separate approval?
How should a buyer review experimental tools?
When should an agent refuse an access-token change?
Can I save the reviewed JFrog permission questions?
GitGuardian MCP: Scanning, identity and planned-capability limits
Does GitGuardian MCP automatically revoke secrets or fix code after detecting an incident?
The Developer profile documents scanning, incident review and guided remediation, with limited honeytoken creation. Broader SecOps actions are described as planned, not established here as available. OAuth and personal-token modes have different credential handling. Publisher statements about secret handling are documentation evidence, not an independent execution test.
Read the complete tool trust profile
Review scope: Documented beta Developer profile; planned SecOps features excluded
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
GitGuardian publishes the beta Developer MCP profile.
Actual scopes, client logs and secret-handling behaviour have not been tested.
Not established
Suggested refusal or clarification condition
Do not promise revocation, code repair or secret non-disclosure without the corresponding current evidence and authority.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Beta release status, secret-handling documentation and permission scopes.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve which remediation claims are supported, planned or still untested.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can GitGuardian MCP revoke a detected secret?
Which SecOps actions are only planned?
Does the Developer profile create honeytokens?
What is the default authentication flow?
Can a non-interactive client use a personal token?
Where is scanning performed?
Has VAREXIS tested whether secret values reach the model?
Which incident permissions should a buyer request?
Does guided remediation mean automatic code repair?
What changes when a beta tool becomes unavailable?
SonarQube MCP: Read-only filtering and deployment variants
Does connecting SonarQube MCP automatically restrict an agent to reading findings?
The self-hosted server documents a read-only setting that disables write operations, but its default is false. Tool-set filters further narrow availability; per-request headers cannot widen server restrictions. Hosted and local variants differ, so a configuration review must bind the variant, identity and enabled tools rather than assume all connections are read-only.
Read the complete tool trust profile
Review scope: Publisher self-hosted server; hosted variants have different tool coverage
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
SonarSource publishes the server; deployment may be local, self-hosted or publisher-hosted.
Buyer configuration, entitlements, source mounts and Results Data usage rights are unverified.
Not established
Suggested refusal or clarification condition
Require explicit authority before changing findings; do not treat internal-use Results Data terms as redistribution clearance.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Default filters, hosted coverage, analysis entitlements and result-use terms.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the exact restrictions needed to keep a review workflow read-only.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is SonarQube MCP read-only by default?
Can an agent mark an issue accepted?
Can per-request headers widen server permissions?
How do tool-set and read-only filters interact?
Which token identity is used by the server?
Do hosted and local Sonar tools expose the same actions?
Can local analysis require source-file access?
Does a quality-gate result certify a release?
Which entitlement controls advanced local tools?
Can a buyer redistribute Sonar Results Data automatically?
When should an agent refuse to change a finding?
Can I save the reviewed Sonar configuration boundaries?
Dynatrace MCP: Query generation is separate from data execution
Does asking Dynatrace MCP to generate DQL authorise it to execute that query?
The documentation separates DQL generation from a data-analysis tool that executes queries and returns results. Execution needs the relevant user and token permissions and remains subject to result limits and capability availability. Generated query text does not establish permission, complete coverage or authority to consume query capacity.
Read the complete tool trust profile
Review scope: Hosted Dynatrace intelligence tools
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer plan, data scope, query charges and enabled capabilities are unverified.
Not established
Suggested refusal or clarification condition
Require authorised query scope and spending context; do not treat a bounded result as a complete incident inventory.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Query limits, platform capabilities and effective data permissions.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the distinction between query text, authorised execution and limited evidence returned.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does DQL generation execute the query?
Which Dynatrace tool returns raw data?
Do user and token permissions both matter?
Can a result limit hide relevant events?
Does an MCP connection prove log access?
Which OAuth flow is documented?
Can platform entitlement affect tool availability?
What query capacity may an agent consume?
Does an empty result prove no incident occurred?
What scope belongs in an observability review?
When should a data query require clarification?
Can I preserve the reviewed Dynatrace query boundary?
Splunk MCP 1.0: Query guardrails and encrypted-token scope
Does a Splunk MCP 1.0 search result establish complete log coverage?
Version 1.0 describes encrypted-token access and constrained SPL query execution. Unsafe commands or excessive execution time can cause rejection. Search and knowledge-object tools remain bounded by identity and query scope. This dated review does not establish newer-version authentication or that a successful query covered every relevant event.
Read the complete tool trust profile
Review scope: Explicitly version 1.0 documentation; newer authentication variants not inferred
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Installed version, role capabilities, index coverage and client handling are unknown.
Not established
Suggested refusal or clarification condition
Do not claim complete incident coverage or apply this version-specific login description to every Splunk deployment.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. MCP version, authentication modes, role capabilities and guardrails.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the dated query and identity limitations used in a log-access decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
AppDynamics MCP: Controller and Events identity are different paths
Does every AppDynamics MCP HTTP call validate the supplied bearer identity with the Controller?
The documented middleware checks bearer syntax, while Controller-backed calls rely on downstream validation. Events-only calls use a separate Events credential and do not contact the Controller. The publisher therefore calls for an independently authenticated shared ingress. A syntactically valid bearer header is not proof of caller authentication for every tool.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
AppDynamics, within Splunk, publishes the documented integration.
Buyer ingress controls, backend scopes and actual logging configuration are unknown.
Not established
Suggested refusal or clarification condition
Do not expose a shared endpoint on the assumption that bearer syntax alone validates every caller.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Middleware validation, Events credential use and ingress guidance.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the identity-path distinction that prevents a false authenticated-endpoint claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does an Events-only MCP call contact the Controller?
Is bearer syntax the same as authentication?
Which credential authorises Events queries?
Why does a shared AppDynamics ingress need its own control?
Are Controller tokens scoped per request?
Do logs identify the authenticated caller for every action?
Can diagnostic errors expose backend context?
Which tools are diagnostic rather than administrative?
What evidence proves the ingress identity boundary?
Does a successful Controller request validate all other tools?
When should shared-endpoint activation be withheld?
Azure DevOps MCP: Remote and local identity are not interchangeable
Can the same Azure DevOps MCP setup be assumed to work for every organisation and action?
The remote offering documents Entra-backed organisations and differs from the locally configured server. The local inventory includes writes such as wiki and work-item changes, not just retrieval. Identify the deployment, organisation identity and effective grants before authorising operations; tool-name changes can also affect an existing client.
Read the complete tool trust profile
Review scope: Remote Entra-backed offering and separately configured local server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Microsoft publishes the Azure DevOps MCP implementations.
Buyer organisation type, identity grants and enabled tool inventory are unknown.
Not established
Suggested refusal or clarification condition
Do not turn a retrieval request into a repository, wiki or work-item change without specific authority.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Remote availability, authentication modes, tool names and project grants.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep the identity and change-authority assumptions behind a project integration decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does remote Azure DevOps MCP support my organisation identity?
How does local authentication differ from remote access?
Can the agent create a wiki page?
Can it update work items rather than only read them?
Which project permissions apply to the caller?
Do local and remote tools have identical coverage?
Can renamed tools break an existing integration?
What repository data reaches the agent client?
Does organisation membership prove change authority?
Which version should a procurement record identify?
Google Developer Knowledge MCP: Documentation access and API identity
Does Google Developer Knowledge MCP inspect or change my Google Cloud resources?
The documented tools search, fetch and answer questions from developer documentation. API keys or OAuth-based credentials support access and project attribution; that is separate from inspecting a buyer Cloud deployment. A documentation answer cannot establish actual resource state or a control being enabled.
Read the complete tool trust profile
Review scope: Google hosted documentation service
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Google publishes the Developer Knowledge MCP endpoint.
Buyer API restrictions, billing project and actual Cloud configuration are not inspected.
Not established
Suggested refusal or clarification condition
Do not substitute documentation retrieval for resource-state evidence or send secrets as search text.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Authentication prerequisites, project attribution and tool definitions.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve which answer came from documentation and which deployment facts remain unverified.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Developer Knowledge MCP inspect my Cloud project?
Which documentation tools are available?
Can I authenticate with an API key?
Can the client use OAuth or application default credentials?
Which project receives API usage attribution?
Does the API key need service restriction?
Can missing service-usage permission stop a request?
Does a generated answer prove a control is enabled?
What input should stay out of a documentation query?
Can the tool change Cloud resources?
When should an agent request configuration evidence?
Can I save the documentation-versus-deployment boundary?
BigQuery MCP: Read-only queries still need data and spending authority
Does selecting a read-only BigQuery MCP tool eliminate cost and permission concerns?
The documented read-only SQL tool excludes specified mutation and execution forms, while a separate execute_sql tool can modify data. IAM still controls calls, and queries remain subject to time and result limits. Read-only execution can consume billable query resources; a tool list or truncated result does not establish authorised access or complete coverage.
Read the complete tool trust profile
Review scope: Google hosted BigQuery MCP tools
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Caller grants, billing mode, dataset sensitivity and query limits are unverified.
Not established
Suggested refusal or clarification condition
Require data and spending authority; reject mutations outside scope and do not infer completeness from a limited result.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. IAM grants, tool restrictions, supported sources and billing controls.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the separate data-access, mutation and query-cost boundaries for an agent workflow.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can BigQuery MCP modify data?
How does execute_sql_readonly differ from execute_sql?
Does listing public tools grant dataset access?
Can a read-only query still cost money?
Which identity authorises the query?
Can result limits hide additional rows?
Are Google Drive external tables supported?
Which SQL forms are excluded from read-only execution?
Salesforce Hosted MCP: User identity and tool authority
Can a Salesforce MCP connection grant an agent unrestricted or unattended access?
The reviewed hosted service uses an External Client App and the connecting user's permissions. The documented flow is user authorization code, not a shared machine identity. Object, field and record permissions still matter; tool annotations depend on client support. Flex Credits and enabled servers need checking separately.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer tool configuration, credits and effective grants are unverified.
Not established
Suggested refusal or clarification condition
Require user and task authority before invoking a changing tool.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Hosted authentication, credit requirements, activated servers and custom tool permissions.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the identity and tool-scope evidence used to approve a Salesforce integration.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can a Salesforce agent act as a shared integration user?
Which OAuth flow does hosted MCP document?
Does the mcp_api scope replace record permissions?
Are field restrictions still relevant?
Can custom tools change records?
Does an annotation force every client to ask approval?
Which servers has the org activated?
Which user appears in activity evidence?
Do I need Flex Credits for hosted MCP?
Does a successful login establish least privilege?
What should procurement request before enabling custom tools?
Can I save the reviewed Salesforce access boundary?
Okta MCP: Scope filtering and administrative identity
Does the Okta MCP server expose only directory reads?
The server loads tools according to configured scopes. Read scopes and manage scopes expose different operations, and manage scopes also cover reads. Device authorization and private-key JWT are documented alternatives; granted API scopes and assigned admin roles must match the intended task.
Read the complete tool trust profile
Review scope: Publisher self-hosted Management API server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Effective roles, token storage and hosted environment are untested.
Not established
Suggested refusal or clarification condition
Do not authorise directory mutations for a read-only question.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Scope-to-tool mapping, tenant support and role assignments.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the distinction between tool filtering and the underlying administrative identity.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does Okta MCP load tools from scopes?
Does a manage scope also permit reads?
Which identity runs Okta admin actions?
Can private-key JWT avoid interactive sign-in?
Is device authorization supported in every tenant type?
Do OAuth scopes alone establish effective permission?
Which admin roles are assigned?
Can the client change users or policies?
Where are directory results exposed?
Does hiding a tool prove the credential is narrow?
What evidence is needed for a read-only deployment?
Confluent MCP: Regional access and client-controlled confirmation
Can an agent assume Confluent MCP cannot change streaming resources?
Most documented operations read data, but connector restart/configuration and Flink statement changes are available. Global and regional endpoints accept different key types. Mutation confirmation is presented through the client, whose auto-approval may bypass a visible prompt. Credential permissions remain decisive.
Read the complete tool trust profile
Review scope: Global and regional hosted servers
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer RBAC, network topology and client approval policy are unknown.
Not established
Suggested refusal or clarification condition
Require exact change authority; do not rely on a prompt alone.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Endpoint support, mutating tools, confirmation behaviour and private connectivity.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the exact streaming operation, credential boundary and approval evidence.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Confluent MCP restart a connector?
Can it create or delete Flink statements?
Which tools are on the regional endpoint?
Will a Cloud API key work on both servers?
Does a global key prove access to every cluster?
Can a client auto-approve the confirmation?
Which organization does the credential belong to?
Can a topic read expose message content?
Does private connectivity enforce every network boundary?
Which audit evidence identifies tool calls?
When should an agent stop before changing a pipeline?
Couchbase MCP: Read-only mode and database credentials
Does Couchbase MCP always allow an agent to modify documents?
The documented configuration defaults to read-only mode, with additional tool disabling. The wider tool inventory includes document mutations and queries, so the effective setting matters. Database authentication supports username/password or client certificates; when both are supplied, the certificate path takes precedence.
Read the complete tool trust profile
Review scope: Self-hosted server for Capella or self-managed clusters
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Couchbase publishes the server; the buyer runs it.
Actual flags, roles, mounts and client retention are not verified.
Not established
Suggested refusal or clarification condition
Require the effective configuration before promising read-only access.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Read-only defaults, authentication precedence, tool list and support terms.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Keep the reviewed configuration conditions behind a read-only approval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is Couchbase MCP read-only by default?
Can it upsert or delete a document?
Can individual tools be disabled?
Which authentication method wins when both are configured?
Does disabling writes remove sensitive reads?
Which cluster is connected?
Are Capella and self-managed deployments supported?
What database role does the server use?
Can diagnostic results contain query information?
Is enterprise support a separate entitlement?
What proves the deployed flags match the intended policy?
Dremio MCP: Deployment mode and mock-result limits
Does a successful Dremio MCP demonstration prove access to real project data?
The guide distinguishes hosted OAuth connections from self-hosted token configuration. Self-hosted modes expose data exploration, introspection or metrics, with optional view creation. Mock mode preserves tool names and schemas but returns placeholders; a successful mock call therefore does not validate data access.
Read the complete tool trust profile
Review scope: Hosted Cloud endpoint and separately configured self-hosted server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Dremio publishes the service and open-source server.
Buyer mode, real data connection and effective permissions are unknown.
Not established
Suggested refusal or clarification condition
Do not present mock responses as production evidence.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Deployment modes, write options, project access and support policy.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save which integration evidence came from a real project versus a client-only demonstration.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Dremio MCP run with no real project connection?
Does mock mode preserve real tool schemas?
Are placeholder responses evidence of data access?
Which server modes expose system metrics?
Can view creation be enabled?
Does the hosted endpoint use the project region?
Does a self-hosted token reach every API path?
Which project is selected?
Is the open-source server covered by standard support?
What should a buyer test outside mock mode?
Does OAuth completion establish a successful query?
Oracle SQLcl MCP: Command restrictions are separate from database grants
Does SQLcl MCP restrict level 4 prove that an Oracle connection is read-only?
SQLcl 26.3 documents level 4 as the MCP default, restricting host commands and scripts. Its database tools still execute SQL and PL/SQL under the connected identity. A command restriction is not evidence that database privileges exclude changes; saved connection selection and grants need separate review.
Read the complete tool trust profile
Review scope: Version 26.3 documented tools and restrict levels
Oracle SQLcl 26.3 documentation; installed version not inspected. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Oracle publishes SQLcl; the buyer runs the local process.
Installed version, saved identities and effective grants are unverified.
Not established
Suggested refusal or clarification condition
Require database-level read constraints before claiming read-only use.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. SQLcl version, command restrictions and connection grants.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve separate local-command and database-authority checks.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does SQLcl level 4 enforce read-only SQL?
Which commands does the default restrict?
Can the agent execute PL/SQL?
Which saved connections can it discover?
Does a restrictive command mode remove database grants?
Langfuse MCP: Project keys expose more than documentation
Is the Langfuse MCP connection a public documentation-only tool?
The data-platform endpoint is authenticated and project-scoped. Read and write tools are available by default; the guide recommends a client allowlist for read-only workflows. It is separate from the public documentation server. Endpoint region, key scope and permitted operations must be identified.
Read the complete tool trust profile
Review scope: Authenticated project endpoint, distinct from public docs MCP
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer allowlist, key ownership and data retention are untested.
Not established
Suggested refusal or clarification condition
Require project disclosure and write authority separately.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Tool set, project key scope, endpoint region and client enforcement.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the project-data disclosure and write-authority conditions for an observability integration.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is Langfuse docs MCP the same as project MCP?
Are write tools enabled by default?
Which project does the API key select?
Can a client allowlist limit tool use?
Does an allowlist change the underlying key rights?
Can prompt content reach the model client?
Which regional endpoint is configured?
Can self-hosted proxy host checks reject a request?
Does listing prompts authorise changing them?
Which data is included in observation results?
What should procurement inspect before connecting production traces?
LangSmith MCP: Trace reads, prompt writes and experiments
Can a LangSmith MCP agent inspect traces without also being authorised to run evaluations?
The remote tool surface includes trace reads alongside prompt publishing, dataset changes and experiment execution. OAuth and API-key access are documented. Self-hosted availability also depends on version and signing configuration. Connection success does not grant task authority for every exposed operation.
Read the complete tool trust profile
Review scope: Hosted service or supported self-hosted deployment
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
LangChain operates Cloud; buyers can self-host LangSmith.
Buyer scope, evaluation cost and client compatibility are unverified.
Not established
Suggested refusal or clarification condition
Require separate authority for writes and experiment execution.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Tool surface, authentication support, self-hosted prerequisites and experiment scope.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve why trace inspection did or did not authorise a later evaluation or change.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does LangSmith MCP include write tools?
Can it publish a prompt?
Can an agent run an experiment?
Which trace and thread content is returned?
Can an API key replace OAuth for a supported client?
Does self-hosted MCP require signing configuration?
Which deployment version applies?
Can a read request justify dataset changes?
Who authorises evaluation cost?
Does successful authentication prove every client is compatible?
Which result pagination limits should a reviewer inspect?
Port MCP: Read-only selection and connected-tool scope
Is Port MCP automatically read-only when added from an IDE?
The documented read-only header defaults to off, allowing tools according to the user's permissions. Turning it on hides write tools. Enabled external connectors introduce their own identities and operations, so a Port login alone does not establish the scope of every upstream action.
Read the complete tool trust profile
Review scope: Hosted platform server with optional external connectors
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Port operates the platform server; upstream connectors have separate operators.
Buyer connectors, credentials and approval controls are unknown.
Not established
Suggested refusal or clarification condition
Review the exact upstream action before extending catalog discovery.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Read-only mode, connector authentication and exposed action set.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the platform and upstream authority checks behind an integration decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is Port MCP read-only by default?
What does x-read-only-mode change?
Does hiding write tools revoke upstream credentials?
Which region hosts my Port endpoint?
Which external connectors are enabled?
Who operates an upstream tool?
Can a user trigger a self-service action?
Which identity does a connector use?
Can platform permissions and upstream permissions differ?
Does OAuth login approve every action?
What should an agent check before sending data upstream?
Kong Konnect MCP: Diagnostics and portal publication
Is Kong Konnect MCP limited to reading gateway configuration?
The documented service combines configuration queries and diagnostics with Dev Portal content creation, editing and publication. PAT and system-account access follow the associated permissions. Optional KAi knowledge search uses additional model processing, so selected tools and data recipients need explicit review.
Read the complete tool trust profile
Review scope: Publisher-hosted Konnect server
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer roles, KAi availability and data-recipient settings are untested.
Not established
Suggested refusal or clarification condition
Require explicit authority before publishing content or opening diagnostics.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Tools, role mapping, regional endpoint and optional model processing.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the scope and recipient decisions for API operations.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Kong MCP publish a portal page?
Can it create a debug session?
Which identity does a system-account token use?
Does a PAT grant only the user's permissions?
Which regional endpoint is selected?
Can administrators disable MCP access?
Does optional KAi search process queries with another model?
Are analytics results safe to share with every client?
Does reading routes authorise editing portal content?
What should procurement capture about token permissions?
Zoom MCP: Meeting reads and content creation use different scopes
Does connecting Zoom MCP give an agent only meeting search?
The publisher lists default meeting, recording and content tools, including file creation. Dedicated product endpoints expose different tool sets and granular scopes. Authentication mode alone does not establish parity across tools or tokens; requested content and write operations must match the granted scope.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer token, consent, retention and actual tool inventory are unverified.
Not established
Suggested refusal or clarification condition
Do not infer content-write or collaborator authority from meeting access.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Product endpoint tool sets, scope requirements and token support.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the exact product and content permissions behind a Zoom integration.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Zoom MCP create content as well as search?
Which scopes expose recordings?
Are Canvas and default Zoom tools identical?
Does one token type work for every product tool?
Can a file read reveal meeting content?
Which server endpoint is connected?
Are collaborator changes a separate operation?
Does meeting search authorise a new document?
What consent covers the returned assets?
Which scopes should procurement record?
What should an agent do when a tool is unavailable?
Does Turso MCP OAuth mean an agent can only query a database?
The publisher describes organization, database and group management as well as SQL. Dashboard consent selects organization, group and scopes; the scoped token is forwarded to the Turso API for enforcement. OAuth removes manual token copying, but does not by itself make the operation read-only.
Read the complete tool trust profile
Review scope: Publisher hosted server and client plugin configuration
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Actual consent, grants, SQL rights and usage costs are unverified.
Not established
Suggested refusal or clarification condition
Require action and spending authority before changing cloud data.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Consent model, API enforcement and exposed operations.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the scoped-identity evidence used for cloud database approval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does Turso MCP expose database management?
Can it run SQL that changes data?
Which organization is bound by consent?
Can group selection narrow access?
Does the MCP layer hold extra privilege?
Where are role and scope checks enforced?
Do I need to paste a long-lived API token?
Which client plugin changes the server capability?
Does an Airbyte agent read upstream data as the signed-in person?
Pipeline operations use the signed-in Airbyte user, or the user who created an application credential. Direct source reads instead use credentials stored in the selected connector. The open-beta server can also change pipelines and start syncs. A successful sign-in does not establish row-level user impersonation in the upstream system.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Context-layer enablement and actual connector grants are unverified.
Not established
Suggested refusal or clarification condition
Require the connector identity and permitted data scope before reading business records.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Context-layer settings, connector grants, default workspace and open-beta tool changes.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the distinction between pipeline access and upstream data identity for an integration approval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Which identity reads a source through Airbyte MCP?
Does Airbyte OAuth impersonate me in the warehouse?
Can a connector credential expose more rows than my upstream account?
Is the context layer enabled?
Which workspace is selected by default?
Can the agent start a replication job?
Can it change connection schedules?
Are destructive tools disabled in this deployment?
Does local demo mode protect the hosted server?
Which user created the application credential?
What pipeline and source permissions should procurement request?
Can I retain the reviewed Airbyte identity boundary?
Fivetran management MCP: Scope and approval enforcement
Does a Fivetran MCP confirmation warning enforce approval?
The publisher repository separates read, write and delete tool scopes and supports explicit action exclusions. Its confirmation wording is advisory, not a server-enforced approval step. Credential-related endpoints also need review. The documented HTTP OAuth resource-server mode is unfinished; it must not be represented as verified token authentication.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Installed revision, effective denylist and credential privileges are untested.
Not established
Suggested refusal or clarification condition
Require enforced authority and a supported authentication mode before management changes.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. HTTP authentication implementation, credential endpoints and scope filtering.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the source version that distinguishes advisory approval language from enforced control.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Are Fivetran write confirmations enforced on the server?
What does the read scope actually expose?
Are credential endpoints excluded?
Can a tool delete a connection?
Which API key identity is used?
Does a tool list prove the underlying key is narrow?
Is the HTTP OAuth mode implemented?
Does the package name establish publisher identity?
Which repository revision was installed?
Can discovery schemas include service-specific fields?
What evidence should a buyer retain before enabling writes?
Does Fivetran Agent Context query with each user's warehouse permissions?
This hosted public-preview interface exposes context-layer SQL reads and feedback submission. Setup selects a warehouse query role or credential; it is not evidence of per-user warehouse impersonation. Dedicated read-only options differ by warehouse, and the reviewed setup says role-based query access is not yet supported for Databricks.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Actual grants, selected schemas and warehouse-specific support are unverified.
Not established
Suggested refusal or clarification condition
Require the query identity and allowed datasets before disclosing results.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Preview capabilities, warehouse-specific role support and schema grants.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the warehouse identity and feature-support boundary behind a procurement decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Which warehouse role does Agent Context use?
Is it the same as Fivetran management MCP?
Can the tool modify warehouse tables?
Is feedback submission a write operation?
Can a custom agent use a system key?
Who grants context-layer access?
Are dedicated query credentials available for this warehouse?
Does Databricks have the same role-selection support?
Do new schemas require grant updates?
What reaches the external model?
Does a successful query establish per-user row isolation?
Can I preserve the reviewed warehouse access basis?
Prefect MCP: Read-only tools and wider agent authority
Does read-only Prefect MCP make the whole agent read-only?
The documented MCP tools inspect runs, logs and infrastructure without mutations. A local server can inherit the active Prefect profile, while the hosted connection uses selected Cloud workspaces. An agent with separate terminal or SDK access can still change Prefect resources; the MCP tool boundary does not restrict those other capabilities.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Prefect publishes the server and offers a hosted Cloud connection.
Actual workspace selection, log content and other agent capabilities are unverified.
Not established
Suggested refusal or clarification condition
Confirm the target and separate write capabilities before authorizing diagnostics.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Beta tool surface, profile selection and independent CLI or SDK grants.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve a diagnostic-access review without confusing a read-only connector with a restricted agent.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is Prefect MCP read-only?
Can the same agent still run a destructive CLI command?
Which profile does a local Prefect server inherit?
Does hosted OAuth use my local profile?
Which Cloud workspaces were selected?
Can a service account be restricted to reads?
Will execution logs be sent to the model?
Is the server still described as beta?
How do I identify the active Prefect target?
Does documentation search prove deployment access?
What should a diagnostic pilot exclude?
Can I save the reviewed Prefect read-only boundary?
The preview Core endpoint manages resources, including workspace and item changes and workspace role assignments. It uses the authenticated Entra identity's Fabric permissions. These resource-management tools are not general-purpose lakehouse table-query tools. Supported-operation audit records and client approval settings must be assessed separately.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Tenant grants, client safeguards and operation-level audit coverage are unverified.
Not established
Suggested refusal or clarification condition
Require the exact resource-management action and executing identity before changes.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Preview tool list, role grants, audit coverage and client approval handling.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the distinction between resource administration and analytical access when selecting an agent connection.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Fabric Core MCP delete a workspace?
Can it grant workspace roles?
Does connecting grant extra Fabric permissions?
Is Core the same as Fabric IQ?
Can Core run arbitrary lakehouse SQL?
Which Entra identity appears in audit evidence?
Are all operations guaranteed to be audited?
Does every client enforce destructive-action approval?
Does data remain inside Fabric after a tool response?
Which transport and OAuth support are required?
What is the current preview limitation?
Can I save the reviewed Fabric management boundary?
Kestra flow MCP: Caller and workflow execution scope
Do read-only annotations prevent a Kestra flow from changing systems?
Flow tools invoke registered Kestra workflows; their effects depend on the flow. The trigger's annotations are informational and do not change execution. Private and public server modes differ materially: a public server admits unauthenticated callers. Authentication choices and flow-scoped permissions depend on edition and configuration.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Kestra publishes the workflow platform; deployment ownership varies.
Actual flow effects, secret use, edition and effective permissions are unverified.
Not established
Suggested refusal or clarification condition
Review the flow and caller authority before invoking a changing workflow.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Server visibility, authentication support, trigger registrations and changed flow effects.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the distinction between tool descriptions and the actual workflow authority being approved.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does a Kestra readOnly hint enforce read-only execution?
Can a public flow server be called without authentication?
Which flows are registered on this server?
Do flow outputs expose confidential data?
Is OAuth supported by the installed edition?
Which identity can execute the namespace?
Is the default server private?
Does the public documentation MCP run my flows?
Can a system prompt replace an execution restriction?
Are input schemas and flow effects reviewed together?
Which execution labels identify MCP-triggered runs?
Can I preserve the reviewed workflow exposure boundary?
Retool MCP: Building, query and administration scope
Does connecting Retool MCP only expose app previews?
Retool's inbound MCP can inspect apps, build or change them, execute resource queries and perform selected administrative tasks according to authorized scopes. It differs from a Retool resource that connects outward to another MCP server. App-building uses both the external development agent and Retool's building service; credit usage remains a separate commercial prerequisite.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Retool provides the server on the selected instance.
Effective resource access, self-hosted version and credit entitlement are unverified.
Not established
Suggested refusal or clarification condition
Require authority for query effects and app changes rather than inferring it from a preview request.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Scope definitions, supported self-hosted versions, query tools and credit terms.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve a scoped app-building and data-access decision without purchasing additional assurance.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Retool MCP execute resource queries?
What does write scope add to read scope?
Who can grant admin scope?
Is this an inbound server or an outbound MCP resource?
Which Retool instance receives the request?
Can the agent create a new resource?
Does app building consume Retool credits?
Is the installed self-hosted version supported?
Does a preview request authorize deployment?
Which app and resource data reaches the coding agent?
What should procurement check before enabling administration?
Does installing the Dagster plugin establish the correct deployment access?
The plugin bundles guidance with a separately authenticated Dagster+ MCP connection. Publisher documentation describes both information access and actions. Region selection matters, and deployment roles govern access; Pro overrides can add permissions rather than subtract the deployment role. Plugin installation alone does not prove the selected identity, region or effective grants.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Dagster Labs provides the Dagster+ service and plugin.
Current tool inventory, authenticated identity and effective grants are unverified.
Not established
Suggested refusal or clarification condition
Require the selected deployment and action scope before allowing operational changes.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Plugin endpoint defaults, exposed operations and deployment-role assignments.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the region and effective-role evidence needed before operational agent access.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is installing the Dagster skill enough to authenticate MCP?
Which region does the plugin endpoint use?
How is an EU organization selected?
Can the MCP connection take actions?
Which deployment role applies?
Can a code-location override remove deployment permissions?
Falcon MCP: Tool filtering and HTTP authentication
Does selecting Falcon MCP modules prove the connection is read-only and authenticated?
Modules select a tool surface, while the read-only filter removes mutations and explicit tool additions can extend module selection. HTTP transport has no authentication by default and normally binds to loopback. A network-accessible deployment needs its separate authentication reviewed; Falcon API credentials alone do not authenticate incoming MCP callers.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
CrowdStrike publishes Falcon MCP; the deployment operator hosts it.
Installed revision, enabled tools, network reachability and grants were not tested.
Not established
Suggested refusal or clarification condition
Require effective tool and caller-authentication evidence before tenant access.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Tool selection precedence, remote authentication and customer-ID configuration.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the exact access-control questions used to review a security-operations connection.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Is Falcon MCP read-only by default?
Does an explicit tool list narrow enabled modules?
Can tool additions cross module boundaries?
Does the read-only filter override additions?
Are excluded tools callable in dynamic mode?
Which Falcon customer ID is selected?
Which API scopes back the connector?
Is HTTP caller authentication configured?
Does a remote bind refuse unauthenticated startup?
Can a three-tool dynamic interface still expose many actions?
Does Checkmarx MCP access authorize every scanner and remediation operation?
The connector follows the authenticated tenant identity and licensed capabilities. It can trigger scans and retrieve findings; absence of project-deletion tools does not make it read-only. Local-directory scanning also needs the Checkmarx CLI and matching credentials. Supported authentication methods differ between clients.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Buyer edition, client, tenant permissions and actual data transfer were not inspected.
Not established
Suggested refusal or clarification condition
Confirm tenant, licensed operation and authority before starting a scan.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Client support, tenant registration limits, scanner licensing and tool expansion.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the licensed capability and authority boundary behind a scanner integration decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Can Checkmarx MCP trigger scans?
Does no project deletion mean no writes?
Are all scanners licensed for this account?
Why is a remediation tool missing?
Which tenant identity is used?
Does this client support predefined OAuth?
Is dynamic client registration available for this client?
Does a Socket MCP dependency score establish that my application is safe to deploy?
The documented connector retrieves package security and quality information. Hosted access uses OAuth; the local deployment requires a token with packages:list. A score concerns the supplied dependency identity, not an independently tested application. Client rules can request checks but do not establish that every dependency was checked or a deployment was blocked.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Socket publishes the MCP integration and operates its hosted endpoint.
Installed server revision, dependency completeness and buyer application behaviour are unknown.
Not established
Suggested refusal or clarification condition
Require exact package coordinates and separate application evidence for a deployment decision.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Scoring tools, authentication and package coverage.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save a source-bound interpretation of dependency scores for a purchase or integration review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does Socket MCP test my running application?
Which package ecosystem and version were submitted?
Does a local Endor Labs MCP process keep analysis offline or prove reachability?
The stdio process runs locally but calls the Endor Labs cloud for security context. Its documented MCP findings are not function-level reachability or action-policy-filtered results. Tools can run scans and code-diff reviews; the latter needs Enterprise enablement and a namespace. A documentation-only connector is a separate interface.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Endor Labs publishes the local integration and operates the cloud platform.
Exact installed revision, transmitted payload and buyer configuration were not inspected.
Not established
Suggested refusal or clarification condition
Confirm code-disclosure authority and analysis scope before scanning private work.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Edition features, cloud calls, binary selection and reachability support.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Retain the analysis scope and data-flow basis without treating a dependency finding as an application verdict.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Practical agent questions
Does local stdio mean Endor analysis is offline?
Which cloud platform receives the request?
Is this the documentation connector or scanning connector?
Are MCP findings filtered by function reachability?
Do action policies filter the returned findings?
Can a tool inspect uncommitted changes?
Which edition enables AI code review?
Has the namespace feature been enabled?
Does npx use the separately installed binary?
Which namespace and user are active?
What permission is needed before scanning private code?
Tenable Hexa AI: Scan authority and external clients
Does Tenable Hexa AI MCP only read vulnerability findings?
Tenable documents both retrieval and state-changing operations, including tagging assets, creating dashboards and launching scans. The hosted connector uses Tenable API keys and requires an eligible Tenable One licence and enabled access. The buyer supplies the AI client; its handling of returned exposure data needs a separate review.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Effective tenant grants, selected client and tool execution have not been inspected.
Not established
Suggested refusal or clarification condition
Confirm target assets, scan authority and client data handling before allowing actions.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Licence eligibility, account access controls and tool mutations.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Preserve the permission and disclosure basis used before admitting a security connector.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.
Does connecting Aikido MCP prove all generated code and repository issues were checked?
Tools distinguish files on disk, supplied code content, dependency manifests and scoped issue retrieval. Issue filters and pagination affect the returned subset. The Copilot cloud-agent integration uses a personal access token because browser login is unavailable there. An installed connector or prompt instruction does not prove a scan ran on every change.
Dated rolling documentation snapshot; no installed or hosted runtime version independently verified. Buyer plan, entitlement and effective configuration are not verified.
Publisher and operator
Aikido publishes the MCP integration and operates the associated service.
Actual token grants, scan execution, client configuration and transmitted payload remain untested.
Not established
Suggested refusal or clarification condition
Require approved code scope and a matching completed result before relying on coverage.
Suggested VAREXIS review condition
Suggested VAREXIS review gates; apply the buyer's authorized task and policy. These conditions do not execute or enforce controls.
A source-linked review aid, not a vendor certification, security clearance or deployment assessment. Unknown does not mean false or unsafe.
Recheck: Recheck when permissions, deployment, authentication, source guidance or intended use changes; a purchase does not trigger revalidation. Changing tools, issue filters, client authentication and input handling.
Record history: 2026-10-16 - v1: Initial documentation review; no earlier vendor assessment claimed.
Optional saved record: Save the input and coverage questions behind an AI-assisted code review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. Original publisher pages may change; full copies of those pages are not sold or republished here.