Skip to main content
Glama

lookup_subdocument

Read-only

Fetch specific fields, check existence, or count elements inside a Couchbase document without retrieving the whole document, using sub-document operations when you already know the exact paths.

Instructions

Look up parts of a document without fetching the whole thing, using Couchbase sub-document operations. Use this instead of get_document_by_id when you only need a few fields, a presence check, or the size of an array/object inside a document — AND you already know the exact field path(s) to look up (e.g. from a prior get_document_by_id call on this same document, from the user explicitly naming the field, or from a known/confirmed schema for this collection).

IMPORTANT: Do NOT guess field paths. If you don't already know the document's exact field names/structure, call get_document_by_id first (or instead) — a guessed path that doesn't exist returns a per-path error here rather than the real data, and reporting "not found" for a wrong guess is worse than just fetching the whole document and reading the right field.

Provide one or more of the following. Each is a list of sub-document paths using Couchbase's dot/bracket path syntax (e.g. "address.city", "tags[0]", "tags[-1]" for the last array element):

  • get_paths: fetch the VALUE at each path.

  • exists_paths: check whether each path exists, without fetching its value (cheaper than get_paths — no payload transfer — when you only need a yes/no answer).

  • count_paths: get the number of elements in the array or object at each path (fails per-path if the path isn't an array/object).

At least one of get_paths, exists_paths, or count_paths must be provided. As a rule of thumb, keep the combined number of paths across all three to 16 or fewer — Couchbase limits subdocument operations per call, though the exact limit is server-side and may change. If the server rejects the call (too many paths, or another constraint like path length or nesting depth), the whole call fails with {"error": "..."}.

A path that doesn't exist (or otherwise fails, e.g. count on a non-array/object) does NOT fail the whole call — it is reported individually as {"error": ...} in the returned dict so the other requested paths can still be resolved.

Returns a dict with a key for each category that was requested (only requested categories are included): { "get": {"": {"value": } | {"error": "..."}}, "exists": {"": {"value": true | false} | {"error": "..."}}, "count": {"": {"value": } | {"error": "..."}}, } On a connection/lookup failure, or an invalid request (no paths / too many paths), returns {"error": ""} instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
get_pathsNo
scope_nameYes
bucket_nameYes
count_pathsNo
document_idYes
exists_pathsNo
collection_nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv1.0.1

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses important runtime behavior: per-path errors do not fail the whole call, failed paths are reported individually as {"error": ...}, too many paths can cause a whole-call failure, and guessing wrong paths returns misleading 'not found' results. It also documents the exact response shape for success and failure, giving the agent a faithful model of how the tool behaves.

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?

The description is long but every section earns its place: purpose, usage rules, parameter semantics, path-syntax examples, failure modes, and return format. It is front-loaded with the most decision-relevant information (when to use vs get_document_by_id) and uses clear structural signposts like the IMPORTANT warning and per-category bullet lists, making it easy for an agent to scan.

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?

Given the tool's complexity — multiple path categories, per-path failures, server-side limits, and a non-trivial response format — the description is exceptionally complete. It even includes the return dict shape and error behaviors despite an output schema being present, and it covers the only real prerequisite (known field paths) along with how to handle uncertainty. An agent has everything needed to invoke it correctly.

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?

With schema description coverage at 0%, the description carries the burden and largely delivers: get_paths, exists_paths, and count_paths are each explained with semantics, examples of path syntax, and guidance on limits and minimum requirements. The required identifiers bucket_name, scope_name, collection_name, and document_id are not individually elaborated, but their roles are strongly implied by their names and the tool's Couchbase context.

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 and resource ('Look up parts of a document without fetching the whole thing, using Couchbase sub-document operations') and immediately differentiates itself from the sibling get_document_by_id by stating exactly when to prefer it. The name and purpose align clearly, so an agent can identify the tool's role without reading the schema.

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?

It explicitly says 'Use this instead of get_document_by_id when...' and gives concrete conditions: needing only a few fields, a presence check, or an array/object size, while already knowing exact field paths. It also provides a clear 'when not to use' instruction — do not guess paths, call get_document_by_id first — which is strong routing guidance with an explicit alternative.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/couchbase/mcp-server-couchbase'

If you have feedback or need assistance with the MCP directory API, please join our Discord server