Maasy MCP

maasy_get_seo_status

Retrieve SEO/GEO scores, keyword rankings, visibility trends, and top queries for a brand by providing its UUID.

Instructions

SEO/GEO scores, keyword rankings, visibility trends, top queries.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`project_id`	No	Brand UUID

Implementation Reference

src/index.ts:241-246 (registration)

The tool 'maasy_get_seo_status' is registered with the MCP server, with a Zod schema accepting an optional project_id string.

server.tool(
  "maasy_get_seo_status",
  "SEO/GEO scores, keyword rankings, visibility trends, top queries.",
  { project_id: z.string().optional().describe("Brand UUID") },
  toolHandler("get_seo_status")
);

src/index.ts:26-43 (handler)

The generic toolHandler function creates an async handler for each tool. For 'maasy_get_seo_status', it calls callGateway('get_seo_status', args) which sends the request to the remote mcp-gateway edge function.

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,
      };
    }
  };
}

src/supabase.ts:42-59 (helper)

The callGateway function sends a POST request with the tool name and args to a remote Supabase edge function (mcp-gateway), which contains the actual business logic for 'get_seo_status'.

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;
}

src/index.ts:244-244 (schema)
Input schema for 'maasy_get_seo_status': optional project_id (string, described as 'Brand UUID').
```
{ project_id: z.string().optional().describe("Brand UUID") },
```

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.3.1Apr 29, 2026

TDQS

C2.5/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of disclosing behavioral traits, but it only lists output categories without explicitly stating that this is a read-only operation, any side effects, or access requirements. The lack of a verb or behavioral context leaves important aspects undisclosed.

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

Conciseness3/5

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

The description is very short and front-loads key terms, but it is a sentence fragment without a verb. It sacrifices structural clarity for brevity, making it less useful than a complete sentence that states the action and resource.

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 absence of annotations and an output schema, the description is the only source of behavioral context. It lists metrics but does not explain their meaning, the return format, or how project_id affects the results. This is insufficient for an agent to fully understand the tool's behavior.

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 already provides 100% coverage for the single parameter 'project_id' with the description 'Brand UUID'. The tool description does not mention this parameter or add any additional semantics, so it adds no value beyond the schema. Baseline of 3 is appropriate.

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 is a noun phrase listing data categories ('SEO/GEO scores, keyword rankings, visibility trends, top queries') rather than a sentence with an explicit verb or resource. The tool name 'get_seo_status' implies retrieval, and the listed terms distinguish it from sibling tools, but the description itself does not clearly state what it does.

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 like maasy_get_campaign_metrics or maasy_get_content_pipeline. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and metric list.

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