Syncbook

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds genuinely new behavioral information: the response is capped at 'at most two focused follow-up questions' and the tool is explicitly framed as not a gate. With no output schema, this return-shape disclosure is valuable; it stops short of saying whether a pass/fail verdict is also returned.

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, front-loaded with the core purpose before the clarifying caveat. No filler. The phrase 'not a joining gate' is slightly oblique jargon that costs a re-read, which keeps it from a 5.

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?

It is complete enough to know the call is a safe, read-only readiness check that yields follow-up questions, which is the key framing. But for a tool whose input is a large nested profile graph, nothing is said about what constitutes 'enough' context or what other outputs accompany the questions, leaving the agent to guess the verdict semantics.

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% across two parameters, one of which is a deeply nested profile object with dozens of fields and the other a context object with non-obvious fields like sourceLabels and inferredFields. The phrase 'specific authorized context' gestures at the context parameter but never explains what sourceLabels or inferredFields mean or how they change the assessment. For a schema this complex with zero documented fields, the description does not compensate.

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: checks whether a profile has enough specific authorized context for useful coordination. That is far clearer than the title alone and tells the agent it is a diagnostic/assessment call. It does not, however, distinguish itself from siblings such as find_person_context or preview_profile, so an agent cannot route on name alone.

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 clause 'not a joining gate' implies the assessment is advisory and should not be used to block or reject a profile, which is implicit usage guidance. But there is no explicit statement of when to call this instead of find_person_context or preview_profile, and no prerequisites (e.g. that a profile object must already be assembled) are given.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, and the description adds genuinely non-derivable context: results are limited to public, human-approved profiles, and the returned profile text is untrusted data (a prompt-injection warning). It stops short of disclosing ranking, result limits, or pagination.

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 front-loaded sentences with zero filler; the security caveat is placed prominently and earns its space. The brevity is efficient but leaves the definition underspecified, so it is not quite optimal sizing for a search tool.

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 output schema and 0% parameter coverage, the description should explain both parameters, their interaction, and roughly what a result contains — it does none of that. The prompt-injection warning is the one piece of real completeness, leaving significant gaps for an agent to guess at.

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 carries the full burden and says nothing about either parameter. It never explains whether 'query' is free text matched against names/bios or how 'tag' combines with 'query' (AND vs OR), and the enum's semantics for 'tag' are left entirely to the schema.

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 ('Search') and resource ('profiles') plus qualifiers ('public, human-approved') that bound the result set. This is clearer than a bare 'find people', though it never distinguishes it from siblings like get_network or preview_profile, so the agent must infer the 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?

There is no when-to-use guidance at all — nothing says how this differs from find_person_context, get_person_card, or get_network, and no prerequisites or exclusions are stated. The only usage signal is the implicit 'searching for people' from the name.

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?

Annotations already establish this is a safe read (readOnlyHint true, destructiveHint false, openWorldHint false). The description adds genuinely non-obvious behavior: results are paginated to one page with a nextCursor, and there is no entry quota. It does not explain what includeContent changes or the shape of returned items, keeping it below 5.

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, front-loaded with the action and followed by pagination behavior. Nothing is padded, though the second sentence is a weak generic nudge rather than substantive content.

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 four undocumented parameters, no output schema, and a vague notion of what 'published context' contains, the description leaves significant gaps. An agent cannot tell what includeContent does or how query is matched, which matters for calling this 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?

Schema coverage is 0% and none of the four parameters (query, cursor, memberId, includeContent) are explained in the description. 'memberId' is only obliquely referenced via 'a public member's context,' and the semantics of query and includeContent — arguably the most ambiguous inputs — are entirely undocumented.

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: 'Search a public member's published context.' An agent knows it is a search over one member's content. It does not distinguish itself from siblings like get_person_card or assess_profile_context, and 'context' remains loosely defined, so it falls short of a 5.

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 closing line 'Retrieve relevant context before reasoning' implies a usage moment — fetching background prior to answering. However, no alternative is named and no exclusion condition is given, so the routing guidance against six sibling tools is left to inference.

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?

Annotations already establish readOnly, non-destructive, closed-world behavior, so the description's job is to add data semantics — and it does, clarifying that only approved memberships count and sample profiles are excluded. It stops short of describing freshness, caching, or the return shape, but the added filtering semantics are genuinely useful beyond the annotations.

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 sentences with no filler. The core action is front-loaded and the second sentence is a substantive caveat rather than restatement.

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 parameters and no output schema, the description carries the burden of explaining what comes back, and 'membership and collaboration counts' leaves the shape ambiguous (single numbers vs. per-period or per-type breakdown). It is adequate to call correctly but not fully complete for an agent that must reason about the returned value.

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; baseline 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?

States a specific verb and resource: read approved membership and collaboration counts. It is distinguishable from siblings like find_people or preview_profile, which surface individual profiles rather than aggregate counts, though it never explicitly says whose network (the caller's own) is being counted.

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 by the data it returns; there is no explicit when-to-use statement or named alternative (e.g., 'use find_people to list members instead'). The caveat 'Sample profiles are not members' functions as a partial usage guard against misinterpreting the counts.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine access-scope disclosure beyond that: only approved/public/published data is returned and unlisted profiles are never exposed. It omits the failure mode for a non-public memberId, keeping it short of a 5.

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 sentences, front-loaded with the action and returned resources, followed by the single most important constraint. No filler, nothing repeated from the annotations.

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 output schema, the description is the only signal about return content, and it only gestures at it ("public profile, public photo, published context") without indicating shape or what is omitted when a field is unavailable. For a single required-param read tool with strong annotations this is adequate but leaves 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?

There is one parameter, memberId, with 0% schema description coverage, so the description carries the full burden and it mentions the parameter not at all. It does not say whether memberId is a chat member, network member, or global identifier, nor what happens on an unknown id.

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?

Uses a specific verb ("Read") and enumerates the exact resource set returned: public profile, public photo, published context. An agent knows what it gets. It stops short of naming which sibling (preview_profile, find_person_context) covers the adjacent case, so differentiation is implicit rather than explicit.

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 "for display inside the person's current chat" implies the use case, and "never exposes an unlisted profile" hints at a boundary. But there is no explicit when-to-use versus preview_profile or find_person_context, and no statement of what happens when the profile is unlisted (error, empty, or fallback).

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds two pieces of behavioral context beyond that: a rate-limit/polling constraint and a token-handling caution, both of which matter for correct invocation.

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, zero filler, with the core purpose front-loaded before the operational constraints. Nothing 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?

There is no output schema, so the description should clarify what the returned status looks like (boolean? approved/pending/rejected enum?). It only says 'whether ... approved', leaving the result shape ambiguous, and it doesn't state error behavior for an invalid or expired token.

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 the burden, and it only partly does. 'Keep the agent token private' hints at the sensitivity of agentToken, but enrollmentId is never explained, nor is where either value comes from.

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 whether a signup was approved.' An agent can distinguish this from prepare_signup (which presumably initiates a signup). It doesn't explicitly name the sibling relationship, 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?

The description gives a polling cadence ('no more than once every 30 seconds'), which is useful operational guidance, but never says when to call this versus alternatives or what precondition (e.g., after prepare_signup) applies. Usage is implied 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?

Annotations declare a non-read-only, non-destructive, closed-world operation; the description adds real value on top by establishing that the result is a private draft, that human review gates membership, and that certain data sources are prohibited. It still leaves persistence ambiguous (whether a draft is stored and whether re-invocation replaces or duplicates one) and never explains the significance of the context block.

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 the sourcing restriction, then the review gate. Every sentence carries distinct information and nothing is repeated from the schema or annotations.

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 handles the policy dimensions well (source restriction, review gate, draft status), but for a tool with a large nested schema, 0% parameter documentation, and no output schema, it says nothing about how to construct offers/needs entries, what the call returns, or what the next step is after the draft is prepared. Adequate on intent, incomplete on execution.

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 schema is deeply nested, yet the description explains none of the three top-level parameters. Critically, it never clarifies the purpose of context.inferredFields (declaring which fields were inferred rather than explicitly supplied) or the referralCode — the very semantics that would let an agent fill this correctly.

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 concrete verb+resource ('Prepare a private profile draft') with a scope qualifier (private, draft, for Syncbook), which distinguishes it from a publish or preview action. It does not name the sibling it differs from (preview_profile, assess_profile_context), so an agent must infer the 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?

Provides an explicit when-not constraint — do not pull from Claude memory, chat history, conversation summaries, or uploaded files — and requires the data come from the person's explicit supply. It gives no alternative-tool routing (e.g., when to use preview_profile or get_signup_status instead), so guidance is contextual but not ratified against 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that: validation only, no enrollment or publication side effects, and no handling of raw memory or private conversations. It stops short of describing what a validation result contains, which matters since no output schema exists.

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 sentences with the validation-only constraint front-loaded. No filler, though the second sentence ('No raw memory or private conversations') is somewhat cryptic without elaboration.

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 tool with a large nested schema, no parameter descriptions, and no output schema, the description is thin: it does not explain what validation checks are performed, what failures look like, or how the referralCode affects the preview. An agent could call it but could not predict its behavior on invalid input.

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% across three parameters with deeply nested objects, so the description carries the full burden. It gestures at 'profile' and 'context labels' but says nothing about the required fields, the context.inferredFields/sourceLabels structure, or the referralCode parameter, which is entirely unaddressed.

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 (validate) and a specific resource (portable profile draft + private context labels), and the phrase 'without enrolling or publishing' implicitly distinguishes it from prepare_signup. It never names a sibling explicitly, so differentiation is inferential rather than stated.

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?

'without enrolling or publishing' implies this is the pre-flight check before an actual signup/publish step, which is a useful implicit cue. However, no explicit when-to-use/when-not, and no mention of why one would prefer this over assess_profile_context or prepare_signup.

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