Skip to main content
Glama
ry-ops

Cloudflare MCP Server

by ry-ops

list_kv_namespaces

Retrieve a paginated list of all Workers KV namespaces in your Cloudflare account for managing key-value storage.

Instructions

List all Workers KV namespaces in the account. KV is Cloudflare's key-value storage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_idNoAccount ID (uses default from config if not provided)
pageNoPage number for pagination
per_pageNoNumber of namespaces per page

Implementation Reference

  • The _list_kv_namespaces method that executes the actual KV namespace listing logic. It extracts account_id, page, and per_page from args, and makes a GET request to /accounts/{account_id}/storage/kv/namespaces on the Cloudflare API.
    async def _list_kv_namespaces(self, args: dict) -> Any:
        """List KV namespaces."""
        account_id = args.get("account_id") or self.account_id
        if not account_id:
            raise ValueError("Account ID is required. Provide it in args or config.")
    
        params = {}
        if args.get("page"):
            params["page"] = args["page"]
        if args.get("per_page"):
            params["per_page"] = args["per_page"]
    
        return await self._make_request(
            f"/accounts/{account_id}/storage/kv/namespaces", params=params
        )
  • The Tool registration with input schema defining the 'list_kv_namespaces' tool, including optional properties: account_id (string), page (number), per_page (number).
    Tool(
        name="list_kv_namespaces",
        description="List all Workers KV namespaces in the account. KV is Cloudflare's key-value storage.",
        inputSchema={
            "type": "object",
            "properties": {
                "account_id": {
                    "type": "string",
                    "description": "Account ID (uses default from config if not provided)",
                },
                "page": {
                    "type": "number",
                    "description": "Page number for pagination",
                },
                "per_page": {
                    "type": "number",
                    "description": "Number of namespaces per page",
                },
            },
        },
    ),
  • The tool dispatch/registration routing: when the tool name is 'list_kv_namespaces', it calls self._list_kv_namespaces(arguments).
    elif name == "list_kv_namespaces":
        result = await self._list_kv_namespaces(arguments)
Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits. It only states the basic list action, omitting details like pagination behavior (page and per_page parameters), authentication requirements, rate limits, or whether the result is flat or nested.

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 at two short sentences, immediately stating the purpose. Every word earns its place; there is no fluff or redundancy.

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?

Given the low complexity of listing namespaces and full schema coverage, the description is largely complete. However, since there is no output schema, a brief note on the shape of the returned data would be beneficial for full completeness.

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?

Input schema provides 100% coverage with descriptions for all parameters (account_id, page, per_page). The description adds no additional semantic meaning beyond what the schema already conveys, so it meets the baseline.

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

Purpose4/5

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

The description uses a clear verb and resource ('List all Workers KV namespaces'), establishing a specific purpose. However, it does not differentiate from sibling tools like list_kv_keys, which is a missed opportunity for clarity.

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?

No guidance is given on when to use this tool versus alternatives such as list_kv_keys or list_dns_records. The context of usage is implied but not explicit, and 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/ry-ops/cloudflare-mcp-server'

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