SAS MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Create Business Rule

create_business_rule

Add a rule to an existing SAS Business Rules rule set by specifying conditions, actions, and conditional logic. Ensure expressions include variable names and use =0/=1 for boolean comparisons to generate valid DS2 code.

Instructions

Create a new rule inside an existing SAS Business Rules rule set.

A rule set can hold multiple rules, each evaluated per its conditional type. Condition/action expressions must include the variable name directly (e.g. "credit_score < 650", not just "< 650") — the API accepts the latter as valid but generates DS2 code with a missing left-hand operand. Boolean signature variables must be compared with = 0/= 1 in expressions, not = false/= true.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Rule name (max 30 chars).
`actions`	Yes	List of actions, each ``{"type": "assignment"\|"return", "term": {"name", "dataType", "direction"}, "expression"}``.
`conditions`	Yes	List of conditions (multiple conditions AND together), each ``{"type": "complex", "expression", "term": {"name", "dataType", "direction"}}``.
`ruleset_id`	Yes	The rule set UUID to add the rule to (not its name — list_business_rulesets returns both).
`conditional`	Yes	"if" starts a new independent rule chain, "elseif" continues the previous rule's chain, "or" ORs into it.
`rule_fired_tracking_enabled`	Yes	Whether to record when this rule fires.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.7.0Aug 7, 2026

changedInput schema / properties / ruleset_id / description

Previous value: -"The rule set UUID to add the rule to."New value: +"The rule set UUID to add the rule to (not its name — list_business_rulesets returns both)."

Addedv1.5.0Jul 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations only signal readOnlyHint=false, so the description carries the burden of explaining important behavior. It warns that the API accepts malformed expressions that generate broken DS2 code and specifies how boolean variables must be compared, giving the agent actionable knowledge beyond the annotations.

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?

The description is compact and front-loaded with the core operation. The following sentences each add valuable prerequisite or expression-format information without repeating schema content or including filler.

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?

Given a fully described input schema and the presence of an output schema, the description covers the key prerequisites, conditional evaluation context, and the non-obvious expression pitfalls. It could mention revision locking or side effects, but this is a minor gap for a create tool with rich structured metadata.

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

Parameters4/5

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

The schema already documents all 6 parameters, so the baseline is 3. The description adds expression-level constraints not present in the schema property descriptions: variable names must be included as left operands, and boolean values must use = 0/= 1. This directly improves the agent's ability to construct valid conditions and actions.

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?

The description opens with 'Create a new rule inside an existing SAS Business Rules rule set,' which clearly identifies the verb, resource, and container. It effectively distinguishes this tool from the sibling create_business_ruleset tool and from the update/get/delete business rule tools.

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?

The phrase 'inside an existing ... rule set' establishes a clear prerequisite and tells the agent this tool is for adding to an existing rule set rather than creating one. It does not explicitly name an alternative like create_business_ruleset, but the context is sufficient for correct routing.

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

Deploy Server