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

With no annotations, the description carries the full burden and does disclose two real behaviors: the private-token requirement and the mutual-consent gating ('contact appears once both agree'). It omits whether the operation is read-only, how matches are represented, and any rate or auth limits beyond the token.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with no padding, and the core purpose is front-loaded. The parenthetical role explanation is compact and earns its place by clarifying the token parameter.

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

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

For a simple one-parameter tool with no output schema, the description covers the credential and the mutual-match rule, which is reasonably complete. It still leaves unclear what a 'match' result contains and when in the flow the agent should call this versus approve/matchmaking siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single 'token' param is undocumented there, so the description meaningfully compensates by explaining that the token is a private credential whose role differs by side (token_kelola for seller, token_pembeli for buyer). This adds genuine semantics beyond the bare string field.

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

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

States a specific verb and resource ('check your matches') tied to the tool name cek_jodoh, and clarifies the token's dual role. It is distinguishable from setujui_jodoh (approve) and minta_dipertemukan (request to be matched), though it never names those siblings to reinforce the distinction.

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

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

It implies usage by telling the agent to pass token_kelola as seller or token_pembeli as buyer, giving some role context. However, it never states when to use this tool versus alternatives like setujui_jodoh or minta_dipertemukan, and gives no prerequisites or exclusions.

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