switch-trust-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SWITCH_TRUST_API_KEY | Yes | Switch Trust API key (sk_...). | |
| SWITCH_TRUST_INSTANCE | Yes | Switch Trust instance base URL, e.g. https://app.flintai.dev. | |
| SWITCH_TRUST_REMEDIATION_DIR | No | For offline development or tests, set to a local directory laid out like the assets; the loader then reads from disk and never touches the network. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_contextA | Show the resolved backend scope (instance, tenant, workspace). Useful to confirm the API key maps to the workspace you expect before querying issues. |
| list_issuesA | List AI-SPM issues for the workspace. Filters: severity (CRITICAL/HIGH/MEDIUM/LOW/INFORMATIONAL), rule_id, category (vulnerability_category), and search (substring match on rule name). Results are paginated: pass the returned cursor to fetch the next page. page_size is capped at 100. Use get_issue for full detail and remediation guidance on a specific issue. |
| get_issueA | Get full detail for one issue plus rule-level remediation guidance. Returns the issue record, the assembled remediation guidance markdown for the issue's rule (when available), and a page of affected objects (assets). The objects list is paginated the same way as list_issues: page_size is capped at 100, and objects.cursor carries forward to fetch the next page. Use get_finding_detail for the code location of a specific occurrence. |
| get_finding_detailA | Get per-finding detail: file path, code snippet, evidence, and remediation. Provide the issue_id and object_id (from get_issue's objects). Omit detail_id to list all findings for that object, or pass one to fetch a single finding. |
| find_issues_for_fileA | Find issues whose findings reference a given working-tree file. Convenience for the edit loop: scans up to max_issues issues and returns the
findings whose file path matches The scan is bounded: max_issues is capped at 500 and the whole call at 300
backend requests. Check the returned |
| get_remediation_guidanceA | Get the rule-level remediation guidance markdown for a rule name. The rule_name matches the value shown on issues (see get_issue). Returns None guidance for rules without docs — use the per-finding remediation from get_finding_detail in that case. The guidance is wrapped in the procedure for choosing and applying a remediation; get_issue returns the same docs unwrapped, for browsing. |
| list_modelsB | List inventoried AI models. Filters: name, severity, supplier, library. page_size is capped at 100; page with the returned cursor for more. |
| list_agentsB | List inventoried AI agents. Filters: name, severity, supplier, library. page_size is capped at 100; page with the returned cursor for more. |
| list_toolsB | List inventoried agent tools. Filters: name, severity, supplier, library. page_size is capped at 100; page with the returned cursor for more. |
| list_mcp_serversB | List inventoried MCP servers. Filters: name, severity, supplier, library. page_size is capped at 100; page with the returned cursor for more. |
| get_modelB | Get a model's detail plus its attached issues and code locations. |
| get_agentB | Get an agent's detail plus its issues, MCP servers, and code locations. |
| get_toolB | Get a tool's detail plus its agents, issues, and code locations. |
| get_mcp_serverB | Get an MCP server's detail plus its issues and code locations. Agents using this server are embedded in |
| list_guardrail_policiesA | List guardrail policies (input/output detector configurations). Filters: search (substring match on policy name). Page-numbered, not cursor-based — pass the next page number to page through results. page_size is capped at 100. Use get_guardrail_policy for full detail. |
| get_guardrail_policyB | Get one guardrail policy's detail: name, description, and the user/assistant detector configuration. |
| get_guardrail_interaction_countsB | Guardrail-decision counts (ok/blocked/redacted/alerted/errored) across LLM interactions, optionally scoped to one agent. |
| get_guardrail_outcomesA | Guardrail outcome totals across LLM interactions, optionally scoped to one agent. Same underlying data as get_guardrail_interaction_counts, without the per-category breakdown. |
| get_guardrail_categoriesC | Guardrail-detector-category counts across LLM interactions, optionally scoped to one agent. |
| list_llm_interactionsA | List LLM interactions (prompt/response pairs) with guardrail outcomes. Filters: search (substring match on prompt text), agent_id. Cursor-paginated: pass the returned cursor to fetch the next page. Rows are trimmed (long prompt/response text truncated, per-turn events omitted) to protect context budget — use get_interaction for full detail on a specific interaction. page_size is capped at 100. |
| get_interactionC | Get one LLM interaction's full detail (prompt, response, guardrail events). |
| list_llm_sessionsA | List LLM sessions (grouped conversation turns) for one agent (required). Cursor-paginated; page_size is capped at 100. Use get_llm_session for a session's aggregate cost/tokens/turns plus the full per-turn list. |
| get_llm_sessionB | Get one LLM session's detail: aggregate cost/tokens/turns and the full per-turn list. |
| list_roi_agentsB | List agents' LLM activity summaries (latest_interaction_time, interaction_count) for the workspace. Drives ROI/cost-optimization analysis: an agent with no recent activity has nothing new to analyze. page_size is capped at 100. |
| list_roi_interactionsA | List one agent's raw LLM interaction rows (with computed cost_usd) — the source data the ROI cost-optimization analyses read. agent_id is required. since/until are optional RFC3339 timestamps bounding interaction_time. page_size is capped at 100. |
| list_roi_analysesA | List ROI/cost-optimization analysis results (findings + estimated $ savings), latest first. Filters: agent_id, analysis_type (tool_bloat, model_optimizer, verbosity, context_cache_waste, retry_loop_waste). page_size is capped at 100. Use get_latest_roi_analyses for just the current recommendation per type, or get_roi_analysis for one result's full detail. |
| get_latest_roi_analysesA | Get the latest finished ROI analysis result per type for one agent — the agent's current cost-optimization recommendations. Both agent_id and analysis_types are required. Returns a dict keyed by analysis_type; a type with no finished run yet is simply absent from the result rather than erroring. |
| get_roi_analysisA | Get one ROI analysis result by ID (findings, estimated $ savings, status, timestamps). |
| list_evaluationsA | List evaluation definitions (probes/metrics), including red-teaming adversarial probes. Filters: search (substring match on name), approach ('probe' or 'metric'). Attack-technique/goal detail for adversarial_probe evaluations lives in each item's config. Page-numbered; page_size is capped at 100. Use get_evaluation for full config detail. |
| get_evaluationB | Get one evaluation definition's full detail, including its config (attack_techniques/adversarial_goals/num_prompts/max_turns for adversarial_probe evaluations). |
| list_agent_evaluationsA | List agent<->evaluation assignments with their latest-run status. Filters: agent_id, evaluation_id, search (substring match on name). Each row includes evaluation_name, latest_run_status/progress/summary, and a score_trend (last 5 scores). Page-numbered; page_size is capped at 100. Use get_agent_evaluation for full detail, get_agent_evaluation_summary for the OWASP-coverage/health rollup across all of one agent's evaluations. |
| get_agent_evaluationC | Get one agent<->evaluation assignment's full detail. |
| get_agent_evaluation_summaryB | Get one agent's evaluation health rollup: health (score/previous_score), coverage (per-category pass/at-risk/not-run counts), and score trend over time. agent_id is required. |
| list_evaluation_runsA | List evaluation runs. Filters: evaluation_id, agent_evaluation_id. status is one of queued/running/finished/error. Page-numbered; page_size is capped at 100. Use get_evaluation_run for one run's full detail and list_evaluation_run_results for its per-prompt results. |
| get_evaluation_runB | Get one evaluation run's detail: status, progress, summary, timestamps. |
| list_evaluation_run_resultsA | List one run's per-prompt results (score, status, conversation transcript). status is one of passed/failed/error/scored. There is no separate detail endpoint for a single result, so conversation turns are trimmed here for context budget rather than dropped: every turn is kept (turn sequence matters for multi-turn attacks) but each turn's text is truncated to 300 chars. For full-fidelity transcript review, use the product UI. Page-numbered; page_size is capped at 100. |
| get_agent_endpointA | Get one agent's target-endpoint config for red-teaming (endpoint_url, endpoint_auth_type, model_type, config). Secrets (endpoint_credential, endpoint_headers) are redacted server-side and always come back empty. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 37 tools
Tools are mostly well-separated by resource and action (list vs get vs summary). The clearest overlap is get_guardrail_interaction_counts vs get_guardrail_outcomes, which the description admits share the same underlying data, and get_remediation_guidance overlaps with the remediation embedded in get_issue. These are minor and the descriptions largely disambiguate.
Overwhelmingly consistent verb_noun pattern (list_*/get_*) with predictable suffixes like _detail, _summary, _runs, _results. A few deviations: find_issues_for_file breaks the list_ convention, and get_context/get_model are vaguer than their peers. Overall readable and consistent.
37 tools is heavy, but the server spans many genuinely distinct domains (guardrails, AI-SPM issues, model/agent/tool/MCP inventory, LLM interactions, ROI, evaluations, red-team endpoints), each with roughly 3-6 tools. It is justified but sits well above the comfortable 3-15 band and risks context bloat.
The surface is broad and largely complete for a read/analytics security platform: list+get coverage for guardrails, issues, inventory, interactions, sessions, ROI, and evaluations, plus aggregation/summary endpoints. Gaps are minor (no per-result detail endpoint for evaluation results, acknowledged trimming) and agents can work around them.