Skip to main content
Glama

design_system_architecture

Design a complete system architecture based on requirements: includes component breakdown, data flow patterns, technology recommendations, and deployment strategies.

Instructions

Design a complete system architecture based on requirements using GLM-4.6. Provides component breakdown, data flow patterns, technology recommendations, and deployment strategies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requirementsYesDetailed system requirements, constraints, and objectives

Implementation Reference

  • Tool schema definition for 'design_system_architecture' including name, description, and inputSchema (requires 'requirements' string).
    {
      name: 'design_system_architecture',
      description: 'Design a complete system architecture based on requirements using GLM-4.6. Provides component breakdown, data flow patterns, technology recommendations, and deployment strategies.',
      inputSchema: {
        type: 'object',
        properties: {
          requirements: {
            type: 'string',
            description: 'Detailed system requirements, constraints, and objectives',
          },
        },
        required: ['requirements'],
      },
    },
  • Tool call handler for 'design_system_architecture' - extracts 'requirements' from args and delegates to glmClient.designSystemArchitecture().
    case 'design_system_architecture': {
      const { requirements } = args as { requirements: string };
      const response = await glmClient.designSystemArchitecture(requirements);
      return {
        content: [
          {
            type: 'text',
            text: response,
          },
        ],
      };
    }
  • src/index.ts:24-119 (registration)
    All tools are registered via the 'tools' array (line 24) passed to ListToolsRequestSchema handler (line 134). The 'design_system_architecture' tool is entry at index 2 in this array.
    const tools: Tool[] = [
      {
        name: 'consult_architecture',
        description: 'Consult GLM-4.6 for expert software architecture guidance, system design patterns, scalability strategies, and technical decision-making. Use this for high-level architectural questions requiring deep technical expertise.',
        inputSchema: {
          type: 'object',
          properties: {
            query: {
              type: 'string',
              description: 'The architectural question or problem requiring expert consultation',
            },
            context: {
              type: 'string',
              description: 'Optional additional context about the system, requirements, or constraints',
            },
          },
          required: ['query'],
        },
      },
      {
        name: 'analyze_code_architecture',
        description: 'Analyze code from an architectural perspective using GLM-4.6. Evaluates design patterns, SOLID principles, scalability, security implications, and provides improvement recommendations.',
        inputSchema: {
          type: 'object',
          properties: {
            code: {
              type: 'string',
              description: 'The source code to analyze',
            },
            language: {
              type: 'string',
              description: 'Programming language of the code (e.g., typescript, python, go, java)',
            },
            question: {
              type: 'string',
              description: 'Specific architectural question about the code',
            },
          },
          required: ['code', 'language', 'question'],
        },
      },
      {
        name: 'design_system_architecture',
        description: 'Design a complete system architecture based on requirements using GLM-4.6. Provides component breakdown, data flow patterns, technology recommendations, and deployment strategies.',
        inputSchema: {
          type: 'object',
          properties: {
            requirements: {
              type: 'string',
              description: 'Detailed system requirements, constraints, and objectives',
            },
          },
          required: ['requirements'],
        },
      },
      {
        name: 'review_technical_decision',
        description: 'Review and evaluate a technical decision using GLM-4.6 architectural expertise. Assesses impact, trade-offs, alternatives, risks, and provides recommendations.',
        inputSchema: {
          type: 'object',
          properties: {
            decision: {
              type: 'string',
              description: 'The technical decision to review',
            },
            context: {
              type: 'string',
              description: 'Context including current architecture, constraints, and objectives',
            },
          },
          required: ['decision', 'context'],
        },
      },
      {
        name: 'advanced_reasoning',
        description: 'Consult GLM-4.6 for advanced mathematical, algorithmic, and scientific reasoning tasks. Delivers world-class innovative solutions with rigorous methodology, optimal algorithms, and enterprise-grade quality. Use for: complex algorithms, mathematical proofs, performance optimization, advanced data structures, computational problems, scientific analysis. Response optimized for Claude 4.5 Sonnet with XML structure.',
        inputSchema: {
          type: 'object',
          properties: {
            task: {
              type: 'string',
              description: 'The specific mathematical, algorithmic, or scientific task requiring advanced reasoning',
            },
            context: {
              type: 'string',
              description: 'Comprehensive context including: problem domain, constraints, requirements, current approach (if any), performance requirements, business logic',
            },
            expected_outcome: {
              type: 'string',
              description: 'Detailed description of expected outcome: solution characteristics, performance targets, quality metrics, innovation requirements',
            },
          },
          required: ['task', 'context', 'expected_outcome'],
        },
      },
    ];
  • The designSystemArchitecture method in GLMClient which constructs a structured query prompt from the requirements and delegates to consultArchitecture() for the actual LLM call.
      async designSystemArchitecture(requirements: string): Promise<string> {
        const query = `Design a system architecture based on the following requirements:
    
    ${requirements}
    
    Provide:
    1. High-level architecture diagram description
    2. Component breakdown and responsibilities
    3. Data flow and communication patterns
    4. Technology stack recommendations
    5. Scalability and deployment strategy
    6. Security architecture considerations`;
    
        return this.consultArchitecture(query);
      }
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It states the tool 'designs' but does not mention side effects (e.g., whether it creates any permanent state), authorization needs, rate limits, or response characteristics. The mention of 'GLM-4.6' is a technical note, not a behavioral disclosure.

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

Conciseness4/5

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

The description is a single sentence that front-loads the action ('Design a complete system architecture') and then enumerates outputs. It is efficient with no wasted words. However, it could be restructured to improve readability (e.g., list outputs separately).

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

Completeness3/5

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

Given the tool's complexity (architecture design) and lack of output schema, the description is somewhat sufficient by listing expected outputs. However, it omits any indication of output format, depth, or constraints (e.g., size limits). With no annotations and no output schema, additional context would help agents understand what to expect.

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% for the single parameter 'requirements', which is described as 'Detailed system requirements, constraints, and objectives'. The tool description adds minimal extra meaning beyond noting it is 'based on requirements'. Baseline 3 is appropriate as the schema already carries the parameter semantics.

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 clearly states the tool's function: designing system architecture. It lists specific deliverables (component breakdown, data flow patterns, technology recommendations, deployment strategies), making the purpose concrete. While it doesn't explicitly differentiate from siblings, the verb 'design' and outputs distinguish it from analysis, consultation, or review tools.

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

Usage Guidelines3/5

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

The description implies use when requirements are available ('based on requirements'), but it provides no explicit guidance on when to use this tool versus siblings, nor any exclusion criteria. Without context on prerequisites or alternatives, agents must infer appropriate usage.

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

Install Server

Other Tools

Latest Blog Posts

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/bobvasic/glm-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server