systems-thinking-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DISABLE_THOUGHT_LOGGING | No | Set to 'true' to suppress stderr logging. | false |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_analysisA | Begin a systems thinking analysis session. Returns model clusters organized by category for you to review and select from. BEFORE calling this, consider whether a predefined strategy fits your use case. Call get_strategy (with no arguments) to see available strategies. THE EXPECTED WORKFLOW IS:
The value is in COMPOSING multiple perspectives. Apply at least 2-3 lenses before synthesizing. |
| expand_selectionA | Get full details for selected models plus their graph neighbors and counterbalances. Call after start_analysis with the model IDs you've chosen. Returns:
Use this to review your selection before committing to apply_lens calls. |
| apply_lensA | Apply a systems thinking model to the current problem. IMPORTANT: The "analysis" parameter is your narrative analysis text. The "findings" parameter is a JSON object where keys are the model's required field names and values are your findings for each. Do NOT pass finding fields as top-level parameters — they must be nested inside the "findings" object. Example call structure: { "sessionId": "abc123", "modelId": "stock-and-flow", "analysis": "Your narrative analysis through this lens...", "findings": { "stocks": "Your finding about stocks...", "inflows": "Your finding about inflows...", "outflows": "Your finding about outflows...", "equilibrium_analysis": "Your finding about equilibrium..." } } Available models: blast-radius (Blast Radius), contract-boundaries (Contract Boundaries), conways-law (Conway's Law), coupling-cohesion (Coupling & Cohesion), data-transformation-fidelity (Data Transformation Fidelity), error-propagation (Error Propagation), failure-modes (Failure Modes), idempotency (Idempotency), kiss (KISS), modularity (Modularity), separation-of-concerns (Separation of Concerns), state-ownership (State Ownership), causal-loop-diagrams (Causal Loop Diagrams), feedback-loops (Feedback & Feedforward Loops), local-vs-global (Local vs Global Optimization), source-sink (Source & Sink), stock-and-flow (Stock & Flow), system-dynamics (System Dynamics), buffers (Buffers & Buffer Sizing), constraints (Constraint Analysis), leverage-points (Leverage Points), migration (Migration), queuing-theory (Queuing Theory), domain-modeling (Domain Modeling Lens), event-driven (Event-Driven Lens), functional (Functional Lens), adversarial (Adversarial Analysis), build-vs-buy (Build vs. Buy), circle-of-competence (Circle of Competence), dependency-risk (Dependency Risk), goodharts-law (Goodhart's Law), hanlons-razor (Hanlon's Razor), inversion (Inversion), map-vs-territory (Map vs Territory), margin-of-safety (Margin of Safety), occams-razor (Occam's Razor), reversibility (Reversibility), second-order-thinking (Second-Order Thinking), back-pressure (Back Pressure), error-budgets (Error Budgets), graceful-degradation (Graceful Degradation), observability-gaps (Observability Gaps), operational-complexity (Operational Complexity), denormalization (Denormalization), normalization (Normalization), attack-surface (Attack Surface), cia-triad (CIA Triad), defense-in-depth (Defense in Depth), least-privilege (Principle of Least Privilege), trust-boundaries (Trust Boundaries), binary-search (Binary Search), bottom-up (Bottom-Up), caches (Caches), parallelism (Parallelism), top-down (Top-Down), whats-changed (What's Changed) IMPORTANT: Do NOT stop after one lens. Apply 2-4 lenses per session to get genuine multi-perspective insight. The response includes prior findings from earlier lenses — use these to identify connections and build on previous analysis. When you've built enough perspective, call synthesize to integrate across lenses. Can be called multiple times per session. Allowed after synthesize. |
| synthesizeA | Synthesize findings across all applied lenses into a unified view. This is the payoff — where cross-lens connections become actionable insight. Call after applying 2+ lenses. Your synthesis should integrate findings across lenses: where did different perspectives agree (reinforcing confidence), where did they contradict (revealing tension), and what gaps remain? The best syntheses surface connections that no single lens would have found. Provide concrete, actionable recommendations grounded in the multi-lens evidence. Note contradictions explicitly — they often point to the most important design tensions. Note gaps — they suggest which lenses to apply next if deeper analysis is needed. The session stays open after synthesis. If the synthesis reveals gaps, apply more lenses and synthesize again. |
| get_strategyA | Get a predefined analysis strategy. Strategies define which concerns to cover and how to approach them, without prescribing specific models. Available strategies: capacity-planning (Capacity Planning), code-review (Code Review), codebase-understanding (Codebase Understanding), incident-investigation (Incident Investigation), post-mortem (Post-Mortem), security-audit (Security Audit), system-design (System Design), technical-decision (Technical Decision) Call without strategyId to list all strategies. Call with a strategyId to get the concern map. Strategies work for any system — code, infrastructure, pipelines, platforms, or design documents. For example, system-design applies equally to a Kubernetes migration plan as to a code architecture spec. USAGE: Get a strategy, then for each concern: evaluate relevance to your specific problem, use expand_selection with models from that concern's domain, pick appropriate lenses, and apply them. Concerns marked "required" should always be evaluated. "Conditional" concerns depend on the scale and nature of the change. Each concern can be run in parallel as an independent analysis track. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidpanter/systems-thinking'
If you have feedback or need assistance with the MCP directory API, please join our Discord server