Skip to main content
Glama
sekera-radim

@briefgate/mcp

by sekera-radim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List intakes

list_intakes
Read-onlyIdempotent

List all client intakes with filters for status, email, folder, or text search to find projects, check progress, or review folder contents.

Instructions

List all intakes in your account, optionally filtered by status, client email, folder, or a text search.

Use this to get an overview of active projects, find a specific intake by the client's email when you have lost the intake_id, check how many intakes are currently in progress, or see what's in a folder from list_folders.

Returns { intakes: [...], total } where each intake includes intake_id, project_name, status, created_at, due_date, folder_id, and portal_url.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree-text search: matches a substring of project name, client name, or client email.
limitNoMaximum number of results (1–100). Default: 20.
offsetNoPagination offset. Default: 0.
statusNoFilter by intake status. Omit to return all.
folder_idNoFilter by folder, using an id from list_folders. Pass the literal string "none" to see only intakes that are not in any folder.
client_emailNoFilter by client email address.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.9.0
    • addedInput schema / properties / folder_id
      Added value: +{
+  "description": "Filter by folder, using an id from list_folders. Pass the literal string \"none\" to see only intakes that are not in any folder.",
+  "type": "string"
+}
    • addedInput schema / properties / q
      Added value: +{
+  "description": "Free-text search: matches a substring of project name, client name, or client email.",
+  "type": "string"
+}
  2. First observedv0.2.1

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already carry readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is fully covered. The description adds the response shape and the folder 'none' convention, but pagination, ordering, and other runtime behaviors are not disclosed beyond what the schema already states. With annotations covering safety, this is adequate but not rich.

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?

Three paragraphs with no waste: purpose, use cases, and return format. The core verb and scope are front-loaded in the first sentence. Each paragraph serves a distinct function, and the description remains compact despite covering multiple optional filters.

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?

Although there is no output schema, the description explicitly states the response shape and the fields each intake includes. With 100% parameter schema coverage, rich read-only annotations, and sibling context, an agent has everything needed to invoke the tool correctly. No critical gap is evident.

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%, with each of the 6 parameters already fully described. The description's filter summary (status, client email, folder, text search) merely restates schema dimensions without adding new semantics, constraints, or usage nuances. The baseline of 3 applies because the schema carries the parameter documentation burden.

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 begins with 'List all intakes in your account, optionally filtered by status, client email, folder, or a text search,' which states a specific verb, resource, scope, and filtering options. It clearly distinguishes this multi-intake listing tool from siblings like get_intake_status, which presumably targets a single intake.

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?

The second paragraph gives concrete use cases: overview of active projects, finding an intake by client email when intake_id is lost, counting in-progress intakes, and viewing folder contents. It references list_folders as the source for folder_id, which helps route preparation steps. It does not explicitly state when not to use this tool or name alternatives to avoid, so it stops short of full exclusion guidance.

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

Deploy Server

Other Tools