Skip to main content
Glama
hidenorigoto

Sakura Cloud MCP Server

by hidenorigoto

get_router_list

Retrieve a list of routers from Sakura Cloud infrastructure to manage network configurations and connectivity.

Instructions

Get list of routers

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • src/server.ts:932-939 (registration)
    Registration of the 'get_router_list' tool in the ListToolsRequestSchema handler, including its name, description, and empty input schema.
      name: 'get_router_list',
      description: 'Get list of routers',
      inputSchema: {
        type: 'object',
        properties: {
        },
      }
    },
  • Input schema for the 'get_router_list' tool, which takes no required parameters.
        type: 'object',
        properties: {
        },
      }
    },
  • The handler logic within CallToolRequestSchema that executes the tool by calling Sakura Cloud API endpoint '/internet' via fetchFromSakuraCloud helper and returns the JSON response.
    } else if (request.params.name === 'get_router_list') {
      try {
        validateCredentials();
        
        const routerList = await fetchFromSakuraCloud(`/internet`);
        
        return {
          content: [
            {
              type: 'text',
              text: JSON.stringify(routerList, null, 2)
            }
          ]
        };
      } catch (error) {
        console.error('Error calling tool:', error);
        throw error;
      }
  • Helper function fetchFromSakuraCloud used by the tool handler to make authenticated HTTPS requests to Sakura Cloud API.
    async function fetchFromSakuraCloud(path: string, isPublicAPI: boolean = false, zone: string = DEFAULT_ZONE, method: string = 'GET', bodyData?: any): Promise<any> {
      return new Promise((resolve, reject) => {
        const basePath = isPublicAPI ? '/cloud/api/cloud/1.1' : `/cloud/zone/${zone}/api/cloud/1.1`;
        
        const options = {
          hostname: 'secure.sakura.ad.jp',
          port: 443,
          path: `${basePath}${path}`,
          method: method,
          headers: {
            'Accept': 'application/json',
            'Authorization': '',
            'Content-Type': 'application/json'
          }
        };
        
        // Add authorization for non-public APIs
        if (!isPublicAPI) {
          options.headers['Authorization'] = `Basic ${Buffer.from(`${SACLOUD_API_TOKEN}:${SACLOUD_API_SECRET}`).toString('base64')}`;
        }
    
        const req = https.request(options, (res) => {
          let data = '';
          
          res.on('data', (chunk) => {
            data += chunk;
          });
          
          res.on('end', () => {
            try {
              if (data) {
                const parsedData = JSON.parse(data);
                resolve(parsedData);
              } else {
                resolve({});
              }
            } catch (err) {
              reject(new Error(`Failed to parse response: ${err}`));
            }
          });
        });
        
        req.on('error', (error) => {
          reject(error);
        });
        
        if (bodyData && (method === 'POST' || method === 'PUT')) {
          req.write(JSON.stringify(bodyData));
        }
        
        req.end();
      });
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get list of routers', implying a read-only operation, but does not cover aspects like whether it requires authentication, if there are rate limits, what the return format is (e.g., JSON array), or if it supports pagination. This leaves significant gaps for an agent to understand how to invoke it effectively.

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 extremely concise ('Get list of routers'), consisting of a single, clear sentence that front-loads the essential action and resource. There is no wasted verbiage or redundancy, making it efficient for quick understanding.

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

Completeness2/5

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

Given the tool has no parameters and no output schema, the description is minimal. It states the purpose but lacks context on behavior (e.g., read-only nature, return format, any constraints) and does not relate to sibling tools. For a tool in a server with many similar list operations, more guidance on usage and output would improve completeness, but the description does not provide this.

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 input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not mention any parameters, which is appropriate since there are none. It adds no semantic detail beyond the schema, but with zero parameters, the baseline is 4 as the description does not need to compensate for missing parameter info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get list of routers' clearly states the verb ('Get') and resource ('routers'), making the purpose understandable. However, it lacks specificity about what 'list' entails (e.g., all routers, filtered by some criteria) and does not differentiate from sibling tools like 'get_router_info', which might retrieve details about a single router versus this list operation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. For example, it does not specify if this should be used for listing all routers versus using 'get_router_info' for details on a specific router, or how it relates to other list tools like 'get_appliance_list'. No exclusions or prerequisites are mentioned.

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/hidenorigoto/sacloud-mcp'

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