Skip to main content
Glama

Apply a Solution Configuration

apply_solution_config
Destructive

Applies and activates a proposed layer, namespace-exclusion, and test configuration for a solution, saving it to the config database and git-tracked sidecar for repo-wide consistency.

Instructions

Apply a proposed Layer Profile + Exclude-Namespaces + Test Profile configuration for a solution. Creates a new custom layer profile / exclusion list / test profile (tagged with the source solution for provenance), activates them, and marks each touched slot initialized. proposalJson is a JSON object {"layerRules":[{"pattern":".Application.","matchType":"Contains","layer":"Application"}],"exclusions":[{"pattern":"System.","matchType":"StartsWith"},{"pattern":"System","matchType":"Exact"}]}; the test axis is given via testProposalJson {"testProjectRules":[{"pattern":".Tests","matchType":"EndsWith"}],"testAttributeNames":["Fact","Theory"]} (rules match PROJECT names) OR via testPreset = xunit|nunit|mstest|default. At least one axis must be non-empty (empty arrays/slots are skipped). matchType is Contains|StartsWith|EndsWith|Exact (an invalid matchType is rejected, not silently defaulted). An exclusion with "keep":true is a keep rule: a namespace it matches is never excluded; exclusions that are all keep rules leave the built-in list in force; the sidecar stores keep rules under "keepNamespaces". Writes to the config/master DB (the given dbPath, or the server's default - the GUI's - if omitted; created if missing) AND to the git-tracked .aicb.json sidecar next to the .sln (returned as sidecarPath - commit it so the config travels with the repo). An axis this call does not name keeps what the existing sidecar holds for it, and keys it does not know stay as they are. An existing sidecar that cannot be read (malformed, locked) is never rewritten: the call is refused before anything is written, and a file that becomes unreadable while the DB is written is left as it is too (the DB keeps the configuration, a warning says so); a keep rule the file puts inside 'exclusions' is moved to 'keepNamespaces'. A keep flag that is not a JSON boolean is rejected.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sessionId": "<sessionId>"
    },
    "name": "apply_solution_config"
  }
}

Input Schema

NameRequiredDescriptionDefault
dbPathNoAbsolute path to the aicb config/master SQLite DB to write the configuration into (created if missing). Omit to use the server's default config DB (the same one the GUI uses), if the server resolved one.
sessionIdYesThe session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use.
testPresetNoOptional shortcut: clone a built-in test profile (xunit|nunit|mstest|default) into a custom per-solution profile. Mutually exclusive with testProposalJson.
proposalJsonNoOptional layer/exclusion proposal as a JSON object with 'layerRules' and/or 'exclusions' arrays (see tool description). Omit for a test-only apply.
layeringPolicyNoLayer-mapping policy for the new profile: 'Advisory' (default) or 'Strict'.
testProfileNameNoOptional display name for the created test profile. Omit for an auto-generated name.
layerProfileNameNoOptional display name for the created layer profile. Omit for an auto-generated name.
testProposalJsonNoOptional test-axis proposal as a JSON object {"testProjectRules":[{"pattern":".Tests","matchType":"EndsWith"}],"testAttributeNames":["Fact","Theory"]}. testProjectRules match PROJECT names. Mutually exclusive with testPreset.
exclusionListNameNoOptional display name for the created exclusion list. Omit for an auto-generated name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.46513
    • changedInput schema / properties / sessionId / description
      Previous value: -"The session_id returned by analyze_solution."New value: +"The session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Far exceeds the annotations: it discloses dual persistence (config/master DB plus the git-tracked <SolutionName>.aicb.json sidecar), names the returned sidecarPath and advises committing it, explains merge semantics for unnamed axes, and specifies refusal-before-write behavior for unreadable/locked sidecars plus the warning path when the file becomes unreadable mid-write. Validation rules (invalid matchType rejected not defaulted, non-boolean keep rejected, misplaced keep rules relocated to keepNamespaces) are also spelled out.

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

Conciseness3/5

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

The lead sentence is well front-loaded and every topic is relevant, but almost all of it is delivered as one enormous run-on sentence stringing together JSON examples, keep-rule semantics, DB/sidecar duality and failure modes. Splitting into bullets or short sentences would make the same content far easier to scan; some dbPath default detail also duplicates the schema.

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?

For a destructive, non-idempotent, 9-parameter write with no output schema, the description covers write targets, merge behavior, validation failures, partial-failure warnings and the returned sidecarPath. The main residual gap is that the return payload beyond sidecarPath (e.g. created profile IDs) is never characterized, and there is no guidance on re-running against an already-initialized slot.

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

Parameters5/5

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

Schema coverage is 100% (baseline 3), but the description still adds meaning the schema does not carry: full literal JSON shapes for proposalJson and testProposalJson, the matchType enumerated values and that they are validated, the "keep":true keep-rule semantics and the keepNamespaces sidecar key, and the clarification that testProjectRules match PROJECT names. This is substantive semantics, not restatement.

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?

Opens with a specific verb ("Apply") and a precisely enumerated resource (Layer Profile + Exclude-Namespaces + Test Profile for a solution), then states what it materializes (custom layer profile / exclusion list / test profile) and that they are activated and marked initialized. An agent can tell this apart from check_solution_config_drift, solution_config_status and init_solution_config without opening any 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?

Gives concrete selection rules: at least one axis must be non-empty, empty arrays/slots are skipped, testPreset is mutually exclusive with testProposalJson, and "Omit for a test-only apply" is implicit from the schema text. It never names a sibling tool as an alternative (e.g. check_solution_config_drift for verification or init_solution_config for first-time setup), so routing against alternatives is left to inference.

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