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

With no annotations, the description carries the full burden. It usefully discloses that the operation is idempotent and writes to the user's account, which signals a state-changing operation. However, it omits auth requirements, error behavior, and what happens if the business id is invalid or already bookmarked beyond idempotency.

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 action, then idempotency, then the write side effect. No wasted words and the most important constraint is stated last for emphasis.

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 single-parameter mutation tool with no annotations and no output schema, the description covers purpose, idempotency, the write scope, and the parameter meaning. It could mention login/auth requirements or success response, but otherwise it is sufficient for correct 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 description coverage is 0%, so the description must compensate. It clarifies that the parameter is a Beli business id, which is valuable beyond the raw integer schema. It still does not give format examples or explain where to obtain the id, so compensation is partial.

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: 'Bookmark a restaurant by its Beli business id.' This clearly distinguishes the action from read-only siblings like get_bookmarks or bookmark_status, though it does not explicitly name a sibling alternative.

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 gives no when-to-use guidance, no prerequisites, and no alternatives (e.g., when to use this versus bookmark_status). It only states the action, leaving the agent to infer usage context.

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 safety profile, and it does declare 'read-only,' which is the most important signal here. It says nothing about auth handling, error behavior for invalid paths, rate limits, or what the response looks like — gaps that matter for a free-form HTTP passthrough.

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, the read-only safety signal and scope are front-loaded, and nothing is wasted. The external spec pointer is the right way to handle an open-ended path space rather than enumerating endpoints inline.

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 free-form, no-annotation, no-output-schema passthrough, the definition covers the essentials an agent needs to attempt a call (read-only, path templating, spec reference) but leaves the params shape and failure modes unspecified. Adequate, not complete.

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%, so the description must compensate. It adds genuinely non-obvious semantics for `path` (template substitution with {user} for the caller's user id, plus delegation to beli-api-spec for the path catalogue), but the free-form `params` object is left entirely unexplained.

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 concrete verb (GET) and resource (any /api/ path in the Beli spec) and frames it as an escape hatch, which distinguishes it from the specific endpoint siblings like list_my_guides and search_restaurants. It is inherently a broad passthrough tool, but the purpose 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?

'Escape hatch' implies this is a fallback when no dedicated tool covers the endpoint, but the description never says so explicitly or names a preferred sibling such as search_restaurants. The pointer to beli-api-spec gives context but no when-not-to-use rule.

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 burden and largely fails: it does not say what is returned (a boolean, an object, or nothing for un-bookmarked restaurants), whether the call requires a logged-in user, or how a missing business_id behaves. Only the read-only nature is loosely implied by 'Check'.

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 or redundancy. It is efficient, though the brevity edges into under-specification rather than deliberate conciseness.

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 one-parameter lookup tool the description adequately conveys the action, and no output schema exists so return values are not strictly required. However, with no annotations and no schema descriptions, the missing return semantics and relationship to sibling bookmark tools leave real gaps.

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 business_id, so it adds no meaning about what the integer identifies or where to obtain it. The schema alone supplies the name and type, leaving the description with zero compensating value.

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 (check) and resource (bookmark status for a restaurant), so the agent knows this is an existence/lookup operation rather than a listing or mutation. It is distinguishable from siblings like get_bookmarks or add_bookmark by implication, but never names those alternatives 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?

There is no guidance on when to use this versus get_bookmarks (list all bookmarks) or add_bookmark, nor on prerequisites such as authentication. The read-only intent is only inferable from the word 'Check'.

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 behavioral burden and does not meet it. "List" weakly implies a read-only call, but there is nothing about pagination, ordering, whether unauthenticated calls fail, or whether the category filter is exhaustive.

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 purpose front-loaded and zero filler. The second sentence is terse to the point of being cryptic, but nothing is wasted.

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 no annotations, no output schema, and 0% parameter coverage, the description would need to carry much more. It omits accepted category values, result shape, and pagination, leaving an agent unable to call this confidently beyond the default case.

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%, so the description must compensate and it only partially does. "Category RES is restaurants" gives meaning to the default value, but never states what other category values are accepted or what happens on an unknown value.

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?

Clear verb+resource ("List the signed-in user's bookmarks") with an explicit scope of the authenticated user. It does not distinguish itself from siblings like bookmark_status or list_my_guides, so an agent cannot tell from the description alone which listing tool applies when.

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 when-to-use or when-not-to-use guidance, and no alternative named. The sibling set contains several closely related listing tools (bookmark_status, list_my_guides, get_my_guide_items) that the description never addresses.

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 disclosure burden. 'Read' signals a non-mutating operation and 'in full' implies complete content is returned, but it says nothing about access requirements (private vs. public guides), behavior on an unknown id, or response shape.

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 short, front-loaded sentence with no filler. It is efficient, though the terseness edges toward under-specification rather than optimal brevity.

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 one-parameter read tool with no output schema and no annotations, the description covers the basic contract but leaves gaps an agent would care about: error behavior on a missing/inaccessible id and whether the returned 'full' guide includes items versus metadata only.

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% — the single guide_id parameter is documented only as an integer titled 'Guide Id'. The description repeats 'by id' without adding format, source (where to obtain the id), or validity constraints, so it does not compensate for the coverage 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 (Read) and resource (one guide) with a clear scope qualifier ('in full by id'), so the agent can tell it apart from list-style tools like list_my_guides. It does not, however, distinguish itself from get_my_guide_items, which plausibly returns related data for the same guide.

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?

'In full by id' implies the tool is for fetching a single complete guide when an id is already known, contrasted implicitly with listing tools. There is no explicit when-to-use or when-not-to-use statement, and no mention of when to prefer get_my_guide_items or list_my_guides instead.

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 discloses that the operation covers all guides for the signed-in user and that each item names its guide id, but it omits pagination, ordering, duplicate handling, and the full shape of returned places.

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?

It is a single front-loaded sentence with no wasted clauses. The scope and the guide-id detail are both stated efficiently.

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 list tool with no output schema and no annotations, the description should say more about what each item contains beyond the guide id. It is adequate for invocation but leaves meaningful gaps around return shape and pagination.

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 or compensate for. The baseline for zero-parameter tools 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 uses a specific verb and resource: it lists places across all of the signed-in user's guides. That distinguishes it reasonably well from list_my_guides, which lists the guides themselves, though it does not explicitly name or contrast the sibling.

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 phrase 'all of the signed-in user's guides' implies the tool is for cross-guide place retrieval rather than looking at a single guide. However, there is no explicit guidance on when to use this versus list_my_guides, get_guide, or get_bookmarks.

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 must carry the load. 'List' implies a non-destructive read and the sentence discloses the fields returned, but it says nothing about ordering, pagination, or whether guides are private/public — gaps that matter for a zero-annotation tool.

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 sentence, front-loaded with the verb and scope, with zero filler. Every clause (signed-in user, guide titles, audience, place counts) adds 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 simple parameterless read with no output schema, the description covers what is returned (titles, audience, place counts) and whose data it is. Only minor details like ordering or result size are absent, which is a small 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, which is the baseline-4 case; there is no parameter semantics to explain and the description correctly implies no input is needed beyond the signed-in identity.

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 ('List') and resource ('signed-in user's Beli guides') and even names the returned fields (titles, audience, place counts). It distinguishes itself from get_guide/get_my_guide_items by scoping to the signed-in user's guide collection, though it never names a 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?

The phrase 'signed-in user's' implies when this applies (own guides, no ID needed), which implicitly separates it from get_guide or get_my_guide_items. But there is no explicit when-to-use/when-not guidance or named alternative.

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 disclose the key behavioral fact that the link is scoped to the signed-in user rather than a parameterizable account. It says nothing about return format (a URL string vs. an object), failure behavior when unauthenticated, or whether the link can be rotated — meaningful gaps for an unannotated tool.

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 short sentence with the resource and scope front-loaded and no filler. For a zero-parameter lookup, this is appropriately sized.

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 trivial zero-param read with no output schema, the description conveys enough to select and call it correctly. The only shortfall is that the return value's shape must be discovered empirically, which a brief phrase like "returns a URL" would have closed.

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 schema has zero parameters, so the baseline is 4. The description reinforces this by stating the user is implicitly the signed-in one, confirming there is nothing to supply.

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 ("Get") and a specific resource ("the signed-in user's referral link"), so the agent knows exactly what comes back conceptually. It does not name or differentiate itself from any sibling, though none of the listed siblings (whoami, get_bookmarks, beli_get) overlaps with referral links.

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 guidance on when to call this versus alternatives, nor any prerequisites. The phrase "signed-in user's" only implicitly signals that authentication is required and that no other user can be targeted.

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 real work: it discloses the return shape (business id + address) and a genuine caveat that top hits may be in the wrong city. It omits auth requirements, result limits, and ranking behavior, which keeps it from a 5, but it is well above baseline for an annotated-free tool.

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 purpose, then return value, then the pitfall to watch for. No filler and nothing that could be cut 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 simple two-parameter search with no output schema this is nearly sufficient, but the agent is left guessing what `term` accepts (name, cuisine, dish?) and unaware that city defaults to Tokyo. Those gaps matter for calling it correctly the first time.

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 carry parameter meaning, and it does not — neither `term` nor `city` is explained, and the schema's notable default of 'Tokyo, Japan' for city is never mentioned. The 'wrong city' note is only an oblique hint about the city 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 ('Search Beli for restaurants') and even names what comes back ('candidates with a `business` id and address'). The sibling tools are bookmark/guide/auth utilities, so this read search is unmistakable.

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 only implied: you search to obtain a `business` id, and you should verify the address before acting. There is no explicit when-to-use or when-not-to-use guidance and no named alternative among the 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?

No annotations are provided, so the description carries the full burden. It implicitly conveys that a signed-in session is required and that the call only reads data, but says nothing about behavior on an unauthenticated/expired session or whether the result can differ from a user-supplied identifier.

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 short sentence, front-loaded with the action and resource, and the parenthetical return fields earn their place by substituting for a missing output schema.

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-argument identity tool with no output schema and no annotations, naming the three returned fields (id, username, name) supplies exactly the missing return-value context. Nothing further is needed to invoke it 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?

The tool takes zero parameters, so there is nothing for the schema to describe; baseline is 4. Nothing in the description contradicts or confuses the empty argument object.

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 ('Return') plus a precisely scoped resource ('the signed-in Beli user'), with the returned fields enumerated. It is unambiguously distinct from every listed sibling (bookmarks, guides, restaurants, referral), though it doesn't explicitly contrast itself with them.

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 only implied: an agent can infer this is the identity/context call, but the description never says when to call it (e.g. first, to resolve 'me' for other calls) or that there are no alternatives for the same information. For a trivial zero-arg tool that omission is tolerable but still a gap.

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