LAHZE - Persian AI Memory Platform

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

With no annotations, the description carries the full disclosure burden. It does valuable work by revealing that the result is a non-published draft identified by a draft_id requiring user confirmation, plus a hard language restriction and a data-integrity rule. It omits side effects an agent would want: that is_public defaults to true, whether drafts expire, idempotency behavior, and media/size limits.

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?

Four short sentences, front-loaded with the action, followed by the hard constraints and the handoff to publish_memory. No sentence is redundant and nothing important is buried.

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?

This is a mutation tool with 12 parameters, no annotations, and no output schema, so the description should carry most of the load. It covers language, integrity, and the confirm-then-publish flow, but leaves most parameter meaning and all visibility/privacy consequences unexplained.

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 description coverage is only 25% across 12 parameters, so the description must compensate. It only gestures at place and date ("ask the user for the real place/date"), leaving text, media, category, category_custom, is_public, is_anonymous, lat/lng, and idempotency_key undocumented in both schema and description.

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?

"Create a memory draft" gives a specific verb and resource, and the closing sentence names publish_memory as the distinct next step, so the agent can separate drafting from publishing. It does not contrast with the other creation-adjacent siblings (search_places, get_memory_categories), but the core action is unambiguous.

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?

The description sets explicit constraints and a precondition flow: Persian only, no English, never invent place/date, and the draft must be confirmed by the user before publish_memory. What it does not say is when to skip this tool entirely (e.g., whether a draft is mandatory before publishing, or which sibling supplies a verified location_id), which keeps it below a 5.

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

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

With no annotations, the description carries the full burden. It does disclose the key effect (access tokens are revoked, i.e. a destructive/auth-affecting operation), which is more than nothing. But it omits reversibility, whether stored data is preserved, whether re-authorization is required afterward, and behavior when not connected.

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?

A single front-loaded sentence with the destructive action as the first word and no filler. Nothing could be removed without losing meaning.

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 zero-parameter, no-output tool this is close to sufficient: the agent knows exactly what the call does. Minor gaps remain around post-revocation state and error conditions, which matter for an agent deciding whether to re-authenticate.

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?

Zero parameters, so the baseline of 4 applies. There is nothing parameter-related for the description to compensate for, and the schema is empty and self-explanatory.

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?

Specific verb ("Revoke") plus a precise resource ("this agent's access tokens for the connected Lahze account"). This is clearly distinct from read-oriented siblings like get_connection_status or get_authorization_url, though it never names them explicitly.

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?

Usage is implied — call it when you want to sever the Lahze connection — but there is no explicit when-to-use/when-not statement, no mention of checking get_connection_status first, and no note about what to do if no connection exists.

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

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

With no annotations, the description must carry the behavioral burden. 'Short, cacheable' adds useful context about response size and caching, but it does not explicitly state that the tool is read-only, side-effect free, or safe to call repeatedly.

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?

The description is a single front-loaded sentence followed by a compact behavioral note. Every phrase contributes content or caching context without waste.

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 zero-parameter discovery tool with no output schema, the description adequately states what information the tool provides. It could be slightly stronger by clarifying the return format or how it relates to overlapping sibling tools, but it is otherwise complete enough to call correctly.

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?

There are zero parameters, so there is nothing for the description to clarify beyond the schema. The baseline for a parameterless tool is 4.

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?

The description names the resource (Lahze) and enumerates the content covered: what it is, its rules, account connection, and Persian memory creation. It is clear enough to distinguish this as an onboarding/discovery tool, but it does not explicitly differentiate itself from siblings like get_lahze_capabilities or get_authorization_url.

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?

The description explains what the tool covers but gives no explicit guidance on when to use it versus alternatives such as get_lahze_capabilities, get_authorization_url, or get_connection_status. Usage is only implied by the 'Discover' framing.

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

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

No annotations exist, so the description carries the full burden; it does add meaningful protocol detail (OAuth 2.1 with PKCE S256) that tells the agent what security posture is expected. However, it omits whether a client must be pre-registered via another tool, whether the generated URL expires, whether calling it has side effects, and whether it actually performs any registration.

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?

A single front-loaded sentence with no filler; the protocol qualifier is packed into the noun phrase rather than spilling into a second sentence.

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?

With zero annotation coverage, no output schema, and four undocumented parameters, the description leaves too much unspecified: which parameters are genuinely required in practice, what the returned string looks like (bare URL vs. JSON field), and how this fits with the other connection tools. Brevity here crosses into under-specification.

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 description coverage is 0% and the description never mentions state, client_id, redirect_uri, or code_challenge. It only alludes obliquely to "a registered client." For a PKCE flow where code_challenge and client_id are effectively mandatory despite the schema marking all four optional, this omission is a real gap.

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 ("Return the ... authorization URL") and pins down the protocol variant (OAuth 2.1, PKCE S256), which is more informative than a generic "get URL". Sibling tools are all memory/connection related, so no differentiation is needed here, but the description also doesn't say what kind of client or system this belongs to.

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?

There is no indication of when an agent should call this versus the sibling connection tools (discover_lahze, get_connection_status, disconnect_lahze), nor whether it must follow or precede an auth flow step. No prerequisites, no sequencing, no exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: not what 'connected' means (token validity vs. account link vs. capability grant), not whether it is read-only, and not whether it triggers or caches any state. For a zero-annotation tool, this is a significant gap.

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?

A single front-loaded sentence with zero filler; the key noun phrase ('connected to a Lahze account') arrives immediately. Nothing is padded or restated.

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 zero-parameter tool with no output schema, the response shape is the entire value proposition, yet the description never says what a check returns (boolean? account identity? expiry?) or what to do on false. The scope statement is adequate, but the missing return semantics leave a real gap.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies no inputs are required.

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 (check) and resource (connection status) scoped to 'this agent' and a Lahze account, which is enough to distinguish it from write-oriented siblings like disconnect_lahze or publish_memory. It stops short of differentiating itself from discover_lahze or get_lahze_capabilities, which plausibly also reveal connection state.

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?

No explicit when-to-use or when-not-to-use guidance, and no mention of the closest alternatives (discover_lahze, get_authorization_url). The usage is inferable from the tool's name and purpose, but the agent gets no routing help among the Lahze-related siblings.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the response is short and cacheable, but it does not explicitly state that the operation is read-only, what permissions are needed, or what the response shape is beyond high-level categories.

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 compact fragments, front-loaded with the returned content categories and followed by a useful caching note. No sentence is wasted, though the terseness is only acceptable because the tool is simple and parameterless.

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 zero-parameter tool with no output schema, the description names the categories of data returned and characterizes the response as structured, short, and cacheable. That is enough to set expectations, even if it does not describe the exact return structure.

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?

The tool has zero parameters, so there are no parameter semantics for the description to explain. The baseline score for a parameterless tool applies.

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?

The description enumerates the resource returned: capabilities, limits, scopes, languages, and available tools. That makes the tool's purpose clear, though it is a noun phrase without an explicit verb and does not distinguish it from siblings such as discover_lahze.

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?

There is no explicit when-to-use guidance and no alternatives are named. 'Short and cacheable' hints at repeated or cached use, but it does not tell an agent when to choose this over discover_lahze or get_connection_status.

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

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

With no annotations, the description carries the full burden; it does disclose one genuinely useful behavioral constraint — that parallel upload from MCP is not supported — which is exactly the kind of context an agent could not get from schema. However, it doesn't say whether the tool is read-only (implicit from 'requirements' but unstated) or what it returns.

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?

One compact sentence, front-loaded with the primary resource (media limits) and followed by the constraint. It's short to the point of being cryptic — the telegraphic phrasing and missing verb cost it a point — but there is no filler.

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 no-parameter, no-output-schema informational tool, the description should convey roughly what information comes back. 'Media limits and the supported way to attach photos' hints at the content but doesn't specify the shape (sizes, formats, counts) or whether it must be re-checked per session.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies.

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?

The description names a specific resource (media limits) and a specific bit of knowledge (the supported way to attach photos), so the agent knows this is an informational lookup rather than an action. It's distinct from the sibling tools (memories, places, connection status), though the verb is implicit and the phrasing is somewhat telegraphic.

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?

The parenthetical '(no parallel upload from MCP)' implies this should be consulted before attempting to attach photos, but it never states explicitly when to call it or what to do with the result. The usage context is inferable rather than stated.

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

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

With no annotations, the description carries the burden, and it does signal the "active" filter, implying inactive categories are excluded. It says nothing about return shape, ordering, caching or whether the list is stable, so behavioural disclosure is adequate but thin.

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 short sentences, zero filler, and the purpose is front-loaded ahead of the usage hint. Nothing could be removed without losing information.

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 parameterless read-only list tool with no output schema, the description supplies what an agent needs: what is listed (active categories), the source system, and where the ids go next.

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?

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. The description correctly focuses on the meaning of the returned ids instead.

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 ("List active memory categories") scoped to a named source, Lahze. It also names the downstream consumer, create_memory_draft, which distinguishes it from the other get_* catalogue/profile tools in the sibling list.

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?

"Use one of these ids in create_memory_draft" gives a concrete call-ordering rule: run this before creating a draft when a category id is needed. It stops short of naming when-not conditions or alternatives, so it falls short of a 5.

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

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 one important behavioral trait: cross-account access is rejected, implying an authorization boundary. It says nothing about whether the memory must be published vs. draft, what error behavior looks like, or what 'details' includes, so significant transparency gaps remain.

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 short sentences with the core purpose front-loaded and the access constraint second — nothing wasted. It is arguably too terse for the information an agent needs, but there is no filler or redundancy.

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?

A simple single-parameter read tool with no output schema, so the description needn't explain return values. However, with no annotations and no schema descriptions, the definition leaves the agent without guidance on where memory_id comes from or what happens on a rejected cross-account request.

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 memory_id parameter is an undocumented string. The description adds only indirect meaning by implying the ID must refer to a memory owned by the connected account; it gives no format, example, or sourcing guidance (e.g., obtain from get_my_memories).

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?

The description gives a specific verb and resource ('Get details of one memory'), which is clearly distinct from the listing sibling get_my_memories and the mutation siblings like publish_memory. It stops short of naming any sibling explicitly, so an agent must infer the distinction from the singular 'one memory' phrasing.

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?

Usage context is implied by 'owned by the connected account' and 'Cross-account access is rejected', which tells the agent this only works for its own memories. There is no explicit statement of when to prefer this over get_my_memories or search, and no prerequisite guidance beyond the ownership constraint.

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

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

With no annotations, the description does carry some behavioral load: it discloses ordering (newest first), pagination, and a hard page cap of 20, and "connected account's" hints at an auth-scoped read. It omits what a memory record contains, the default page size, and how to detect the end of the list.

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?

A single sentence that front-loads the verb and resource, with ordering and pagination constraints appended in parentheses. No filler, no repetition.

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 two-parameter read tool with no annotations and no output schema, the essentials (scope, ordering, page cap) are covered. Gaps remain around default limit, end-of-pagination detection, and returned fields, which the description must carry since nothing structured covers them.

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 50%: `before` is documented in the schema as a created_at cursor, while `limit` has no schema description. The description's "max 20" merely restates the schema's maximum and says nothing about a default page size, so it only partially compensates for the undocumented parameter.

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 ("List ... memories") plus scope ("the connected account's") and ordering ("newest first"), so an agent knows exactly what it returns. It does not explicitly name how it differs from siblings like get_memory_details, leaving that inference to the agent.

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?

Usage is implied: browse the current account's memories without needing an id, which distinguishes it from get_memory_details by construction. However, there is no explicit "use this when / use X instead" guidance and no mention of when a paged crawl is preferable to fetching a single memory.

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

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

No annotations are provided, so the description must carry behavioral context. It adds a useful privacy note that passwords and private secrets are never exposed, but it does not state authentication prerequisites, error behavior, or confirm that the operation is strictly read-only beyond the verb 'Get'.

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?

The description is a single front-loaded sentence with no wasted text. The privacy clarification is relevant and compact.

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 zero-parameter getter, the description is minimally adequate: it says what is fetched and gives a privacy guarantee. However, with no output schema and no annotations, it could do more to clarify what profile data is returned and whether a Lahze connection is required.

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?

The tool has zero parameters, so parameter semantics are not a meaningful burden. The empty schema is self-explanatory and the description does not need to add parameter details.

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?

The description states a clear verb and resource: get the connected Lahze profile. It is specific enough to distinguish from sibling tools like get_connection_status or get_my_memories, though it does not explicitly name an alternative or scope boundary.

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 does not explain when to use this tool versus siblings such as get_connection_status, get_lahze_capabilities, or get_my_memories. The intended usage is only implied by the tool name and description.

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

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

With no annotations, the description carries the behavioral burden well by disclosing rejection conditions and clarifying that suspicious memories are saved for review rather than deleted. It does not cover permissions, idempotency behavior, or what a successful publish returns, but the core side effects and constraints are stated.

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?

The core rule is front-loaded in the first sentence, and each following sentence adds a distinct constraint or edge-case behavior. There is no wasted text.

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?

The description covers the business rules well, but for a three-parameter mutation with no annotations and no output schema, it leaves gaps around parameter meaning, idempotency, and response behavior. It is adequate but not fully complete for reliable invocation.

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 only 33%, with user_confirmed documented but draft_id and idempotency_key unexplained. The description does not clarify what draft_id identifies or how idempotency_key should be used, leaving important parameter meaning to inference.

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?

The description states a specific verb and resource: publishing a draft, with the key prerequisite of explicit user confirmation. It is distinguishable from create_memory_draft by focusing on publishing an existing draft, though it does not name the sibling explicitly.

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 gives explicit when-to-use guidance (only after user confirmation) and clear when-not conditions: no English or non-Persian memories, no other users’ drafts, no expired drafts, and no duplicates. It also explains the special case for suspicious memories.

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

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

No annotations exist, so the description carries the full burden. It discloses that results come from a curated 'verified' catalog and warns against fabricating coordinates, which is useful behavioral context. It says nothing about auth requirements, result ordering, pagination, or what happens when query and lat/lng are both supplied or neither is.

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?

Three short sentences, front-loaded with the purpose, then the safety constraint, then the invocation rule. Nothing wasted and nothing buried mid-paragraph.

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 5-parameter, zero-annotation, no-output-schema search tool, the definition covers purpose, a safety rule, and invocation modes. It leaves out `limit` behavior, expected return shape, and any auth or prerequisite context, which an agent would need to call this confidently in edge cases.

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 description coverage is 0%, so the description must compensate. It does add real semantics by pairing lat+lng and presenting query/city as an alternative mode, but it never mentions the `limit` parameter and gives no format hints beyond the obvious. That is partial compensation, not full.

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+resource with a named data source: 'Search verified places in the Lahze catalog.' An agent immediately knows this is a place lookup against the catalog rather than a mutation or memory tool. It stops short of naming a sibling alternative, but none of the listed siblings compete for this job.

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?

'Pass query/city, or user coordinates as lat+lng' gives an explicit two-mode invocation rule, which is real guidance rather than description of behavior. 'Never invent coordinates' adds a firm prohibition. Missing is any statement of when to prefer one mode over the other or any prerequisite (e.g., auth, catalog availability).

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