Skip to main content
Glama
Sign In

Mark

by com.use-mark.app
OverviewDiscussionsAdmin

Get Setup Status

get_setup_status
Read-onlyIdempotent

The workspace's setup checklist, the same rows in the same order as the setup card on Home and the setup email: website, market, brand voice, web analytics, content sources, social accounts, buyer questions, posting times, connect an agent. Each row has state done, todo or skipped and an in-app action URL. gaps lists the todo rows, each fix naming the tool to call or the page to open. The social row is done once a social account is connected; if Social publishing then needs attention, gaps adds one social entry with the reason and when it was last checked. ready is true once every row is done or skipped and no such entry is open, so it does not promise that drafting or research will work: a skipped market still blocks keyword research. Does not change anything. Related: skip_setup_step, set_up_market, save_site, get_connect_link, update_posting_slots.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_setup_status"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
gapsYes
rowsYes
readyYes
appUrlYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / properties / gaps / items / properties / area / enum
      Previous value: -[
-  "market",
-  "site",
-  "brand",
-  "slots",
-  "connections"
-]New value: +[
+  "website",
+  "market",
+  "brand_voice",
+  "web_analytics",
+  "content_sources",
+  "social",
+  "buyer_questions",
+  "posting_times",
+  "connect_agent"
+]
    • addedOutput schema / properties / rows
      Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "action": {
+        "additionalProperties": false,
+        "properties": {
+          "label": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "label",
+          "url"
+        ],
+        "type": "object"
+      },
+      "detail": {
+        "type": "string"
+      },
+      "key": {
+        "enum": [
+          "website",
+          "market",
+          "brand_voice",
+          "web_analytics",
+          "content_sources",
+          "social",
+          "buyer_questions",
+          "posting_times",
+          "connect_agent"
+        ],
+        "type": "string"
+      },
+      "state": {
+        "enum": [
+          "done",
+          "todo",
+          "skipped"
+        ],
+        "type": "string"
+      },
+      "title": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "action",
+      "detail",
+      "key",
+      "state",
+      "title"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • changedOutput schema / required
      Previous value: -[
-  "appUrl",
-  "gaps",
-  "ready"
-]New value: +[
+  "appUrl",
+  "gaps",
+  "ready",
+  "rows"
+]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations it discloses non-obvious semantics: gaps contains only todo rows, each naming the tool or page to use, and a social entry appears with a reason and last-checked timestamp when publishing needs attention. The caveat that ready=true does not guarantee drafting or research (a skipped market still blocks keyword research) is exactly the kind of behavioral trap an agent would otherwise fall into.

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

Conciseness4/5

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

Front-loaded with the resource and row inventory, and every clause carries real information about states or edge cases. The social-row sentence is denser than it needs to be, and the middle section reads as one long run-on, costing a point.

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

Completeness5/5

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

For a no-argument read tool with annotations and an output schema, this covers everything an agent needs: what each row means, how gaps is populated, what promotes ready to true, and the explicit warning about what ready does not imply.

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?

Zero parameters, so the baseline applies; there is no input to disambiguate. The description instead pre-explains the response fields (row states, gaps entries, ready) rather than leaving them to the output schema, which adds moderate value.

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 names the exact resource (the workspace setup checklist) and enumerates its rows in order, plus what each row carries (state done/todo/skipped, action URL). It also anchors the object to concrete artifacts ('the same rows in the same order as the setup card on Home and the setup email'), which pins down identity in a way a name alone cannot.

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

Usage Guidelines4/5

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

'Does not change anything' plus a Related list of the mutating siblings (skip_setup_step, set_up_market, save_site, get_connect_link, update_posting_slots) makes the read-vs-fix split clear. What's missing is an explicit trigger condition — it never says 'call this first to decide which setup fix to run' — so the when-to-use is strongly implied rather than stated.

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

All Mark toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources