Skip to main content
Glama

searchJams

Read-onlyIdempotent

Search the connected team's Jams. text matches every term against a Jam's title, description, comments, linked issue titles, the reporter's email or external id, and its transcript; a term made of only one or two letters or digits is matched against comments only through the whole text: a comment that contains the text as typed matches when another term has three or more letters or digits, or punctuation next to them (such as cool or #12). Terms like #12 or v1.2 also match comments on their own. textIn limits which of those places a term may match in. where is a list of { field, op, value } filter leaves, all ANDed; the where description lists every field, its operators and what it means. window bounds created_at, sort orders the page, and page carries the limit and the opaque cursor the previous page returned. The team is the one the token was issued for and no argument can name another. Each returned Jam carries a url, the share link to hand back to the user unchanged.

Input Schema

NameRequiredDescriptionDefault
vYesQuery contract version. Always 1 for this schema.
pageNoPaging. limit is between 1 and 250 and defaults to 20; cursor is the opaque value the previous page returned.
sortNonewest (created_at descending, the default), oldest (created_at ascending), updated (updated_at descending).
textNoFree text. Split on whitespace into at most 8 terms; a jam matches only when every term matches somewhere (title, description, a comment, a linked issue title, the reporter's email or external id, or the transcript). A term made of only one or two letters or digits is matched against comments only through the whole text: a comment that contains the text as typed matches when another term has three or more letters or digits, or punctuation next to them (such as "cool" or "#12"). Terms like "#12" or "v1.2" also match comments on their own.
whereNoFilters, all ANDed. Each entry is { field, op, value }. Negation is ne / notIn on a leaf; there is no or and no not node. id (eq|ne|in|notIn): The jam itself, as a UUID or a jam.dev link. author (eq|ne|in|notIn): Who recorded the jam, as a user UUID or the literal 'me' for the signed-in viewer. folder (eq|ne|in|notIn): The folder the jam sits in, as a folder UUID or short id. 'eq null' is the team root; 'ne' and 'notIn' count root jams as matching, since a jam with no folder is not in the named one. type (eq|ne|in|notIn): What was captured. origin (eq|ne|in|notIn): The capture surface. extension_chrome is the browser extension, native_macos the macOS app and native_cli its command line, recording_link a shareable recorder link, web_recorder the recorder opened directly, mobile_ios and mobile_android the phone apps, csup_intercom the Intercom support widget, dashboard a jam created in the app. Some are no longer produced but still sit on older jams, so every member stays filterable. capturedUrl (contains): Substring of the page URL the jam was captured on, matched case-insensitively. recordingLink (eq|ne|in|notIn): The recording link the jam was submitted through, as its id or the public id its URL carries. recordingLink.reference (eq|ne|in|notIn|contains): The free-form label on the recording link the jam came through, the one that records where the link was handed out. integration.name (eq|ne|in|notIn): The provider of an issue created from the jam. Only entities attached to the jam itself count, never one attached to a comment on it. integration.id (eq|ne|in|notIn): The provider's own key for an issue created from the jam, such as 'JIRA-123'. Matches the provider id or its alias. country (eq|ne|in|notIn): Where the jam was recorded, as an uppercase ISO 3166-1 alpha-2 code (US, DE, PL). browser (eq|ne|in|notIn): Browser name from the recorded system info, matched exactly against the name the user agent reported, so 'Mobile Safari' and 'Safari' are different values. Any value is accepted; the listed ones are what most rows carry. os (eq|ne|in|notIn): Operating system, matched exactly. The CPU architecture some browsers append to the name is ignored, so macOS matches a jam recorded on 'macOS (arm)'. Any value is accepted; use in to cover several spellings at once. isIncognito (eq|ne): Whether the jam was recorded in a private browsing window. isCharging (eq|ne): Whether the device was plugged in while the jam was recorded. Jams that recorded no battery reading match neither value. connection (eq|ne|in|notIn): Effective network type from the recorded system info, matched exactly. Any value is accepted.
intentNoIn 15-30 English words, your larger task and why this call helps it. People by role ("a customer"); no argument values or secrets.
textInNoWhich places text may match in: title, description, comment, integration, transcript. Omit to search every one.
windowNoCreated-at bounds. from is inclusive, to is exclusive. Accepts an ISO date, an ISO datetime with at most millisecond precision, or a negative ISO 8601 duration such as -P7D.
optionsNocount: none skips the count query (default); exact returns the total match count, at about the cost of a second search.
llm_modelNoYour exact model id from your system prompt, or "unknown". Never guess.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / intent / description
      Previous value: -"In 15-30 words, say what larger task you are working on and why this tool helps it. Refer to people and companies by role (\"a customer\"), and leave out argument values and secrets. Use English. Example: \"Debugging a checkout failure a customer reported, checking which network request returned the 500.\""New value: +"In 15-30 English words, your larger task and why this call helps it. People by role (\"a customer\"); no argument values or secrets."
    • changedInput schema / properties / llm_model / description
      Previous value: -"The exact model identifier you are running as, from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Pass \"unknown\" if you are not certain; never guess."New value: +"Your exact model id from your system prompt, or \"unknown\". Never guess."
  2. First observed

TDQS

B3.1/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds genuinely non-schema behavior: the team is fixed by the issued token and 'no argument can name another', and each returned Jam carries a `url` share link to hand back unchanged — the latter is important given there is no output schema. It still omits result-shape detail beyond the url and any rate-limit/large-result behavior.

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 scope and team statements are front-loaded and earn their place, but the long single-clause sentence reproducing the short-term comment-matching rule duplicates the `text` schema text almost verbatim and crowds out what an agent actually needs (routing versus siblings).

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

Completeness1/5

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

For a 10-parameter, nested, unannotated-output search tool, the description never addresses the two auxiliary parameters `intent` and `llm_model`, nor result size/pagination behavior beyond 'opaque cursor the previous page returned'. Most consequentially, with `search` and `listJams` as siblings, the missing differentiation leaves the agent without enough to call the right 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?

Schema description coverage is 100%, so `text`, `textIn`, `where`, `window`, `sort`, `page` and `options` are already fully documented. The description largely re-narrates those same clauses rather than adding new meaning; it adds only the framing that all `where` leaves are ANDed and a pointer that the schema lists each field and operator.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource and scope: 'Search the connected team's Jams', and the closing sentence clarifies the search cover surfaces (title, description, comments, linked issues, reporter, transcript). It never names the obvious siblings `search` or `listJams`, so an agent cannot tell from this text alone which of the three to pick.

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?

No when-to-use guidance at all: nothing says when to prefer this over `listJams` (browse without query) or `search` (the other search tool in the sibling list). The only guidance-like content is the token-scoped team constraint, which is a restriction rather than a selection rule.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.