Cirra AI Salesforce Admin MCP Server

run_tests

Run Apex tests and native Flow Tests asynchronously and return the job ID used to poll for results. Use tests to run specific classes or methods, or testLevel to run tests org-wide

Input Schema

Name	Required	Description
`tests`	No	Specific tests to run. For a native Flow Test, className is 'FlowTesting.{flowApiName}' and each test method is '{flowTestApiName}' -- the FlowTest developer name (metadata fullName), used exactly as it appears on the record. Do not prepend the flow name. Method names are sent verbatim and are verified before the run is enqueued, so a name that matches no FlowTest fails immediately with an error. Omit testMethods to run every test in the class. Cannot be combined with a testLevel of RunLocalTests or RunAllTestsInOrg
`sf_user`	No	(optional) Salesforce username to identify the connection to use. Omit this to use the current default connection.
`category`	No	Limit an org-wide run to Apex tests, Flow tests, or both. Only applies when using testLevel; ignored when naming tests explicitly
`classids`	No	Comma-separated Apex class IDs to run. Only applies when using testLevel
`suiteids`	No	Comma-separated Apex test suite IDs to run. Only applies when using testLevel
`testLevel`	No	Which tests to run when not naming them explicitly via tests. RunLocalTests and RunAllTestsInOrg select tests org-wide and cannot be combined with tests
`classNames`	No	Comma-separated Apex class names to run. Only applies when using testLevel
`suiteNames`	No	Comma-separated Apex test suite names to run. Only applies when using testLevel
`cirra_ai_team`	No	(optional) Cirra team ID or name that owns the Salesforce connection to use for this call. Must be provided together with 'sf_user'. Use it to run against a specific team's connection without changing your default team — e.g. to keep separate chats on Salesforce orgs in different teams. Omit it when this call carries the context_handle from cirra_ai_init, which names the team for the conversation. A user with more than one place to work (several teams, or a team and a personal account) must pass either the context_handle or 'cirra_ai_team' + 'sf_user'.
`context_handle`	No	(recommended) The conversation context handle returned by cirra_ai_init in this conversation. Pass the exact context_handle value from the most recent cirra_ai_init result so this call runs against the team and Salesforce connection selected for this conversation. A user with more than one place to work (several Cirra AI teams, or a team and a personal account) must pass either this handle or 'cirra_ai_team' + 'sf_user'; a call with neither is refused.
`maxFailedTests`	No	Abort the run after this many failures. Use '0' to stop at the first failure or '-1' to never abort. Does not apply to Flow tests
`skipCodeCoverage`	No	Set to 'true' to skip code coverage collection, which makes the run faster. Recommended when running Flow tests

Output Schema

Name	Required	Description
`jobId`	No	The AsyncApexJob ID of the enqueued run (often 15-char). Poll ApexTestRunResult by AsyncApexJobId until Completed/Failed/Aborted, then ApexTestResult and FlowTestResult. Prefer the 18-char AsyncApexJobId from ApexTestRunResult when querying ApexTestResult. Status=Failed with MethodsCompleted=0 means nothing ran (bad class/method name or FlowTest discovery lag), not an assertion failure
`message`	Yes
`success`	Yes
`warning`	No	Non-blocking advisory about this run. Present it to the user and take it into account; it does not mean the run failed
`errorCode`	No
`testCount`	No	Number of tests requested. When testMethods are named this is the method count (same quantity as ApexTestRunResult.MethodsEnqueued). A class listed without testMethods counts as 1 because the method count is not known until the run finishes. Omitted for org-wide testLevel runs.
`testLevel`	No
`artifactType`	No
`artifactCategory`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare non-readonly, non-destructive, non-idempotent, open-world. The description adds the crucial behavioral facts annotations can't convey: execution is asynchronous and the call returns a job ID for polling rather than results. It falls short of naming the polling mechanism or noting prerequisites such as deployed code.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, and the most decision-relevant fact (async, returns a job ID) leads. The mode selection rule follows immediately and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Explains the async execution model, the returned job ID, and the two selection modes, and an output schema exists so return values need not be described. The remaining gap is what the agent should do with the job ID — the description never points to the polling path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented, including enum values and the tests/testLevel incompatibility. The description only restates that same split at a high level without adding format or syntax detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Run Apex tests and native Flow Tests'), plus the key behavioral trait (asynchronously, returns a job ID). No sibling in the list does test execution, so the tool is unambiguously distinguishable without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames the two mutually exclusive modes: 'tests' to name specific classes/methods, or 'testLevel' to run org-wide. It does not name any alternative tool (e.g. which tool polls the returned job ID), but within the tool the selection guidance is clear.

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

All Cirra AI Salesforce Admin MCP Server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?