Skip to main content
Glama
jamesbrink

MCP Server for Coroot

update_db_instrumentation

Configure database monitoring settings in Coroot to instrument and track performance metrics for MySQL, PostgreSQL, Redis, MongoDB, or Memcached databases.

Instructions

Update database instrumentation configuration.

Configures how Coroot instruments and monitors a specific database.

Args: project_id: Project ID app_id: Application ID (format: namespace/kind/name) db_type: Database type (mysql, postgres, redis, mongodb, memcached) config: Instrumentation configuration

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYes
app_idYes
db_typeYes
configYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • MCP tool handler function decorated with @mcp.tool(). This is the entry point for the 'update_db_instrumentation' tool, which delegates to an internal implementation.
    @mcp.tool()
    async def update_db_instrumentation(
        project_id: str, app_id: str, db_type: str, config: dict[str, Any]
    ) -> dict[str, Any]:
        """Update database instrumentation configuration.
    
        Configures how Coroot instruments and monitors a specific database.
    
        Args:
            project_id: Project ID
            app_id: Application ID (format: namespace/kind/name)
            db_type: Database type (mysql, postgres, redis, mongodb, memcached)
            config: Instrumentation configuration
        """
        return await update_db_instrumentation_impl(  # type: ignore[no-any-return]
            project_id, app_id, db_type, config
        )
  • Internal helper implementation that calls the CorootClient.update_db_instrumentation method and formats the response.
    @handle_errors
    async def update_db_instrumentation_impl(
        project_id: str, app_id: str, db_type: str, config: dict[str, Any]
    ) -> dict[str, Any]:
        """Update database instrumentation config."""
        client = get_client()
        result = await client.update_db_instrumentation(project_id, app_id, db_type, config)
        return {
            "success": True,
            "message": f"{db_type} instrumentation updated successfully",
            "config": result,
        }
  • CorootClient method that performs the actual HTTP POST request to the Coroot API to update database instrumentation configuration.
    async def update_db_instrumentation(
        self, project_id: str, app_id: str, db_type: str, config: dict[str, Any]
    ) -> dict[str, Any]:
        """Update database instrumentation configuration.
    
        Args:
            project_id: Project ID.
            app_id: Application ID.
            db_type: Database type (mysql, postgres, redis, mongodb, memcached).
            config: Instrumentation configuration.
    
        Returns:
            Updated instrumentation configuration.
        """
        # URL encode the app_id since it contains slashes
        from urllib.parse import quote
    
        encoded_app_id = quote(app_id, safe="")
    
        response = await self._request(
            "POST",
            f"/api/project/{project_id}/app/{encoded_app_id}/instrumentation/{db_type}",
            json=config,
        )
        data: dict[str, Any] = response.json()
        return data
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 this is an update/configuration tool, implying a mutation operation, but doesn't describe what 'update' entails (e.g., whether it overwrites or merges settings, permission requirements, side effects, or response format). The mention of 'instrumentation and monitors' hints at monitoring setup, but lacks critical details like whether changes are immediate, reversible, or have dependencies.

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 well-structured and front-loaded: the first sentence states the core purpose, the second elaborates, and the Args section efficiently lists parameters with brief clarifications. Every sentence adds value without redundancy, making it easy to scan and understand quickly.

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 (4 parameters, nested 'config' object, no annotations, but has an output schema), the description is moderately complete. It covers the purpose and parameters adequately, but lacks behavioral context (e.g., mutation effects, error handling) and doesn't leverage the output schema to explain return values. For a configuration tool with potential side effects, more guidance would be helpful.

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?

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all 4 parameters: 'project_id' and 'app_id' are identified with their roles, 'db_type' is clarified with specific database options (mysql, postgres, etc.), and 'config' is described as 'Instrumentation configuration.' This goes beyond the schema's minimal titles, though it doesn't detail the structure or content of the 'config' object.

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 clearly states the tool's purpose: 'Update database instrumentation configuration' and 'Configures how Coroot instruments and monitors a specific database.' It specifies the verb ('update/configure') and resource ('database instrumentation configuration'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'configure_integration' or 'configure_profiling' beyond the 'database' focus.

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. It doesn't mention prerequisites, exclusions, or compare it to related tools like 'get_db_instrumentation' (which appears to be a read counterpart) or other 'configure_' siblings. The agent must infer usage from the tool name and context alone.

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/jamesbrink/mcp-coroot'

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