Skip to main content
Glama
chzkyy

mcp-mongodb

by chzkyy

find_one

Read-only

Ambil SATU dokumen pertama yang cocok dengan filter.

Instructions

Ambil SATU dokumen pertama yang cocok dengan filter.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filterNoQuery filter MongoDB. Contoh: {"status": "aktif", "umur": {"$gt": 25}}. Kirim sebagai objek atau string JSON. Gunakan {} untuk semua dokumen.
databaseNoNama database tujuan. Opsional jika MONGODB_DB sudah diatur.
collectionYesNama koleksi.
projectionNoProyeksi field yang dikembalikan. Contoh: {"nama": 1, "email": 1, "_id": 0}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.3/5.0
Behavior3/5

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

The readOnlyHint annotation already tells the agent this is a safe read operation, and the description's 'Ambil' is consistent with that. The description adds the 'pertama' (first) qualifier, which is a useful behavioral trait, but it does not clarify what defines 'first' (e.g., natural order) or what happens when no document matches.

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 a single short sentence with no filler, front-loading the core action and object. It is as concise as possible while still conveying the primary function.

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

Completeness3/5

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

For a simple read-only tool with full schema coverage, the description is adequate but not complete: it omits ordering semantics, return value/null behavior, and any hint about which sibling tools to prefer. Given there is no output schema, a bit more context would improve agent confidence.

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?

The input schema covers all four parameters with detailed descriptions (100% coverage), so the schema carries the burden of parameter semantics. The description itself adds no parameter-specific detail beyond what the schema already provides.

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?

The description uses a specific verb 'Ambil' and a specific resource 'SATU dokumen pertama yang cocok dengan filter,' clearly indicating it retrieves a single matching document. This distinguishes it from sibling find (which would return multiple documents) and get_by_id (which targets by ID), though it does not explicitly name those alternatives.

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?

The description provides no explicit guidance on when to use this tool versus alternatives such as find or get_by_id. The intended use case of retrieving one document is implied, but no exclusions, conditions, or alternative tool names are mentioned.

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