Skip to main content
Glama

maasy_scan_brand

Scan brand health across DNA completeness, campaigns, content, CRM, SEO, and alerts. Receive traffic-light status for each area to quickly identify issues and optimize marketing.

Instructions

Deep health scan: DNA completeness, campaigns, content, CRM, SEO, alerts. Returns traffic-light status per area.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idNoBrand UUID (uses default if omitted)

Implementation Reference

  • src/index.ts:69-74 (registration)
    Registration of the 'maasy_scan_brand' MCP tool using server.tool(). It accepts an optional project_id and delegates to toolHandler('scan_brand').
    server.tool(
      "maasy_scan_brand",
      "Deep health scan: DNA completeness, campaigns, content, CRM, SEO, alerts. Returns traffic-light status per area.",
      { project_id: z.string().optional().describe("Brand UUID (uses default if omitted)") },
      toolHandler("scan_brand")
    );
  • Generic toolHandler wrapper that calls callGateway(toolName, gatewayArgs) on the Supabase edge function 'mcp-gateway'. This is the handler invoked when 'maasy_scan_brand' is called – it passes 'scan_brand' as the tool name.
    function toolHandler(toolName: string, argsFn?: (args: Record<string, unknown>) => Record<string, unknown>) {
      return async (args: Record<string, unknown>) => {
        try {
          const gatewayArgs = argsFn ? argsFn(args) : args;
          // Auto-inject default project_id if not provided
          if (DEFAULT_PROJECT_ID && !gatewayArgs.project_id) {
            gatewayArgs.project_id = DEFAULT_PROJECT_ID;
          }
          const result = await callGateway(toolName, gatewayArgs);
          return { content: [{ type: "text" as const, text: JSON.stringify(result, null, 2) }] };
        } catch (e: unknown) {
          return {
            content: [{ type: "text" as const, text: `Error: ${e instanceof Error ? e.message : String(e)}` }],
            isError: true,
          };
        }
      };
    }
  • Input schema for maasy_scan_brand: optional project_id string validated by Zod.
    { project_id: z.string().optional().describe("Brand UUID (uses default if omitted)") },
  • The callGateway function that sends the tool name ('scan_brand') and args to the Supabase edge function gateway, which executes the actual brand scan logic server-side.
    export async function callGateway(tool: string, args: Record<string, unknown> = {}): Promise<unknown> {
      const res = await fetch(gatewayUrl, {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
          [authHeader.name]: authHeader.value,
        },
        body: JSON.stringify({ tool, args }),
      });
    
      const data = await res.json();
    
      if (!res.ok) {
        throw new Error(data.error || `Gateway error (${res.status})`);
      }
    
      return data.result;
    }

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.1

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal the output format ('traffic-light status per area'), but it does not explicitly state whether the scan is read-only, whether it triggers side effects, or if any permissions are needed. The term 'scan' suggests non-destructive behavior, but that is not explicit.

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 a single well-structured sentence that front-loads the core purpose ('Deep health scan'), uses a colon to introduce the list of areas, and ends with the output specification. No redundant or filler words.

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?

Without an output schema, the description sufficiently explains the return value ('traffic-light status per area') and enumerates all scanned areas. However, it could be more explicit about what 'traffic-light status' means (e.g., red/yellow/green) or how to interpret the results, and it does not hint at how to drill down for details via other tools. Overall, it is largely complete for a holistic health scan tool.

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?

The input schema provides 100% coverage for the sole parameter 'project_id' with a clear description ('Brand UUID (uses default if omitted)'). The tool description adds no parameter information. Given the high schema coverage, a baseline score of 3 is appropriate.

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 a specific action ('deep health scan'), the resource ('brand'), and enumerates the areas covered (DNA completeness, campaigns, content, CRM, SEO, alerts). It also specifies the output ('traffic-light status per area'), which distinguishes it from sibling tools that focus on individual areas like maasy_get_seo_status or maasy_get_alerts.

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 a holistic overview use case by listing multiple areas to scan, but it does not explicitly state when to use this tool versus the more specific sibling tools, nor does it mention when not to use it. No alternatives are referenced, so the guidance is only implicit.

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