BriefGate

Check intake progress

get_intake_status

Read-onlyIdempotent

Check the completion status of a client intake — which items are submitted, pending, or need revision; the history of automated chase emails sent; and when the client last opened the portal.

Use this to decide whether to send a manual reminder (send_chase), request a revision (request_revision), or fetch results (get_intake_results). Returns per-item status and chase history.

This is also the call a scheduled check should make when no webhook is registered — see follow_up in the define_intake response for the cadence. When status becomes "completed", fetch the results with get_intake_results and carry on with the work that was waiting on them.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`intake_id`	Yes	Intake ID returned by define_intake (e.g. "in_8f3k").

Output Schema

TableJSON Schema

Name	Required	Description
`items`	Yes
`chases`	Yes
`status`	Yes
`due_date`	No
`progress`	Yes
`intake_id`	No
`client_brief`	No	The brief shown to the client above the requested items, if one is set.
`client_last_seen`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedSep 16, 2026

removedOutput schema / additionalProperties
```
Removed value: -false
```
removedOutput schema / properties / chases / items / additionalProperties
```
Removed value: -false
```
changedOutput schema / properties / chases / items / properties / sent_at / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```

changedOutput schema / properties / chases / items / required

Previous value: -[
-  "channel",
-  "sent_at",
-  "status",
-  "attempt_no"
-]New value: +[
+  "channel",
+  "status",
+  "attempt_no"
+]

changedOutput schema / properties / client_last_seen / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / due_date / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

removedOutput schema / properties / items / items / additionalProperties
```
Removed value: -false
```
changedOutput schema / properties / items / items / properties / submitted_at / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
removedOutput schema / properties / progress / additionalProperties
```
Removed value: -false
```

changedOutput schema / required

Previous value: -[
-  "intake_id",
-  "status",
-  "progress",
-  "items",
-  "chases"
-]New value: +[
+  "status",
+  "progress",
+  "items",
+  "chases"
+]

Changed1 schema field changedSep 16, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "chases": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "attempt_no": {
+            "type": "number"
+          },
+          "channel": {
+            "type": "string"
+          },
+          "sent_at": {
+            "type": "string"
+          },
+          "status": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "channel",
+          "sent_at",
+          "status",
+          "attempt_no"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "client_brief": {
+      "description": "The brief shown to the client above the requested items, if one is set.",
+      "type": "string"
+    },
+    "client_last_seen": {
+      "type": "string"
+    },
+    "due_date": {
+      "type": "string"
+    },
+    "intake_id": {
+      "type": "string"
+    },
+    "items": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "key": {
+            "type": "string"
+          },
+          "label": {
+            "type": "string"
+          },
+          "status": {
+            "enum": [
+              "pending",
+              "submitted",
+              "needs_revision",
+              "approved"
+            ],
+            "type": "string"
+          },
+          "submitted_at": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "key",
+          "status",
+          "label"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "progress": {
+      "additionalProperties": false,
+      "properties": {
+        "submitted": {
+          "type": "number"
+        },
+        "total": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "submitted",
+        "total"
+      ],
+      "type": "object"
+    },
+    "status": {
+      "enum": [
+        "draft",
+        "sent",
+        "in_progress",
+        "completed",
+        "archived"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "intake_id",
+    "status",
+    "progress",
+    "items",
+    "chases"
+  ],
+  "type": "object"
+}

First observedSep 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that: it mentions the tool returns chase history and last-open time, and it specifies the scheduled-check behavior ('This is also the call a scheduled check should make when no webhook is registered'). This enriches the agent's understanding without contradicting annotations.

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?

The description is efficiently written, with the core purpose in the first sentence and usage guidance following. It is front-loaded and each sentence earns its place, though there is slight redundancy in restating 'Returns per-item status and chase history' after already listing those items. Overall, it is compact and well-organized.

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?

For a tool with a single parameter and an output schema, the description covers purpose, usage scenarios, and the scheduled-check exception. It references the defining tool (define_intake) and the result tool (get_intake_results), giving the agent a clear workflow. The only minor gap is that it doesn't describe pagination or volume limits, but that is likely covered by the output schema and the tool's simplicity.

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?

Schema description coverage is 100%, and the description does not add new parameter information. It only restates that intake_id comes from define_intake, which is already in the schema. The baseline of 3 for high coverage applies, as the description does not need to compensate for missing schema documentation.

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 opens with a specific verb ('Check the completion status of a client intake') and enumerates the exact information returned (submitted/pending/revision status, chase email history, last portal open). It also names sibling tools to route selection, distinguishing it from get_intake_results, send_chase, and request_revision.

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

Usage Guidelines5/5

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

Explicitly states when to use this tool versus alternatives: 'Use this to decide whether to send a manual reminder (send_chase), request a revision (request_revision), or fetch results (get_intake_results).' It also provides a specific scheduled-check scenario with the cadence source ('follow_up in the define_intake response') and the follow-up action when status completes. No ambiguity.

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

All BriefGate tools Inspect

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

Need Help?