Noemic

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

Without annotations, the description carries the burden of behavioral disclosure. It adds one key behavior: 'endsAt defaults to one hour after startsAt'. However, it does not specify that this is a mutation, whether slots are appended or replaced, or any side effects. The default behavior is helpful but incomplete.

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 fluff. The first sentence states the purpose, and the second provides a critical default. Every word earns its place.

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 core action and a key default but lacks context on return values, overwrite behavior, limits, or prerequisites. For a simple tool, it is minimally adequate but leaves gaps that an agent might need to infer.

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 already describes all parameters and their formats. The description adds semantic value by stating the default for endsAt (one hour after startsAt), which is not in the schema. This clarifies a common ambiguity, raising the score above the baseline of 3.

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 clearly states the action ('Add open session slots') and the target ('to the user's profile'). It distinguishes from sibling tools like 'get_availability' (read-only) and 'become_available' (status toggle), as it specifically adds time slots.

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 guidance on when to use this tool versus alternatives (e.g., 'become_available', 'set_available_now'). The description does not mention prerequisites, such as requiring a signed-in session, nor does it explain when adding slots is appropriate vs. other availability management actions.

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 full burden. It discloses that the operation is append-only and date-stamped, and requires consent. However, it does not mention limits (size, rate) or whether duplicates are handled. Overall, it provides good behavioral context for a simple append operation.

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 action and resource. Every sentence conveys essential information with no redundancy or fluff. Highly concise and well-structured.

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 append with only two parameters and no output schema, the description covers purpose, content guidelines, and behavioral constraints. Minor gap: does not indicate what the tool returns upon success (e.g., confirmation). Still, fairly complete for its complexity.

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 50% (sessionToken described, text not). The description compensates by explaining the text parameter's intended content ('Anything that would help future matching...'), adding value beyond 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?

The description clearly states the action ('Append text') and the resource ('user's agent-readable corpus'). It also specifies the type of content (experiences, boundaries, wins) and the constraint of consent, distinguishing it from siblings like 'port_context' or 'send_message'.

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 lists examples of appropriate content but does not explicitly state when to use this tool versus alternatives like 'create_artifact' or 'artifact_library'. It implies usage for storing personal context but lacks explicit when-not-to-use or alternative guidance.

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 provided, so description must disclose all behavioral traits. Mentions ranking by adoption, but does not describe pagination, read-only vs. mutation (assignment is a side effect), or any limitations. Insufficient for a tool with no 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 that front-load key information (public, ranked, searchable, assignable). Examples are embedded efficiently, no extraneous 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?

Simple tool with one parameter and no output schema; description covers main use cases. Missing details on result count, pagination, or whether results are filtered by something. Adequate but not exhaustive.

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?

Single 'search' parameter with 0% schema coverage; description adds examples of natural language queries, providing some semantics. However, it lacks details like search behavior (fuzzy, exact match) or allowed length.

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?

Clearly states it provides public artifacts from all pros, ranked by adoption, and supports natural language search and assignment. Distinguishes from siblings like 'my_artifacts' (personal) and 'create_artifact' (creation).

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 concrete examples of search terms ('procrastination', 'reframing') and explains the value of assigning artifacts. Lacks explicit when-not-to-use or alternatives, but context implies this is for browsing public content.

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 fully carry the burden. It discloses that the artifact is assigned with an optional note, the client's agent administers it, and the result returns to the connection. However, it does not describe side effects (e.g., state changes), error conditions, or required permissions beyond the session token.

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

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

The description is concise with three sentences. The first sentence states the core action, the second gives timing, and the third describes the flow. No redundant or vague phrases.

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?

Given no output schema and medium complexity (4 params), the description covers the tool's purpose, timing, and expected outcome (result returns). It lacks error handling details or prerequisites beyond the session token, but is otherwise adequate.

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 25% (only 'sessionToken' described). The description adds meaning to 'artifactId' (yours or from library) and implies 'connectionId' is the client, but does not clarify the format or purpose of the 'note' parameter beyond 'optional'. It partially compensates for missing schema descriptions.

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 clearly states the action ('assign an artifact'), the resource ('artifact, yours or from the library'), and the recipient ('to a client'). It distinguishes from sibling tools like 'create_artifact' and 'complete_assignment' by specifying 'Pro-side' and that it's done one at a time during a session.

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 provides explicit timing guidance ('Best moment: as a session lands') and limits usage to 'one artifact at a time'. However, it does not say when not to use this tool or mention alternative tools for similar tasks.

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 provided, the description fully discloses behavioral traits: the tool creates a profile (mutation), requires a sessionToken that must never be shown to the user, supports preview mode (publish: false), has no review queue, and allows self-set rates (including zero for free/credits-only). It also notes that availability is optional and that endsAt defaults to one hour after startsAt.

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 concise (about 4 sentences) and front-loaded with the core action. Every sentence earns its place, covering the main purpose, usage guidelines, parameter behavior, and context. No redundant or vague phrasing.

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?

Given the complex tool (9 parameters, 4 required, no output schema, no annotations), the description covers purpose, usage, behavioral traits, and parameter semantics comprehensively. It even hints at return value ('returns the rendered profile + quality notes') in the publish description. No gaps remain for an agent to misuse the tool.

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 description adds significant meaning beyond the input schema. It explains that `story` should be in first person, `corpus` is for agent consumption, `headline` should be specific and human (not a job title), `publish` default false means preview only, `createdVia` enum values are explained, `availability` defaults to one-hour slots, and `hourlyRateDollars` of 0 means free/credits-only. This greatly aids correct parameter usage.

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 clearly states the tool's function: 'Create the user's profile so others can book them.' It uses a specific verb ('Create') and resource ('user's profile'), and distinguishes it from siblings like 'set_available_now' or 'update_my_profile' by emphasizing that this is a profile creation action, not just a toggle or update.

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 provides explicit when-to-use guidance: 'Draft everything from your conversation... confirm with them before calling.' It explains prerequisites (no credentials needed, no review queue, only qualification is being human) and clarifies that setting `publish` to true should only happen after user approval. However, it lacks explicit comparison to sibling tools, which would elevate it to 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 discloses that the tool returns a URL, requires privacy of requestId and pollSecret, and prohibits asking for credentials in chat. It lacks details on side effects, but the core behavior is transparent.

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 concise (4 sentences), front-loaded with the condition, and every sentence adds value without 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?

Given zero parameters and no output schema, the description covers the essential use case and privacy constraints. It is sufficient for an agent to invoke correctly, though it could mention the follow-up with finish_sign_in.

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 input schema has 0 parameters and 100% coverage, so no additional parameter info is needed. The baseline of 4 is appropriate as the description adds no redundant 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 clearly states the tool initiates sign-in and returns a URL. It specifies the resource (noemic.app URL) and the verb (begin sign-in), and distinguishes from siblings like finish_sign_in.

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 explicitly says 'Call only when the user is ready for an identity-bearing action' and provides handling instructions (show only signInUrl, keep others private). It does not explicitly name alternatives but implies when not to use (not for chat credentials).

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?

The description discloses key behaviors: pricing details, default 30 minutes, result includes roomUrl, and requirement for availableNow=true. However, it is ambiguous whether the tool selects an available person automatically or requires the profileId param. No annotations are provided, so the description carries full burden, yet it omits potential error conditions or authentication needs beyond sessionToken.

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 convey the core purpose and pricing information efficiently. The second sentence is slightly dense but still readable. Minimal waste, though restructuring could improve clarity.

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?

Given no output schema or annotations, the description covers purpose, pricing, and output hint (roomUrl). However, it lacks details on required profileId semantics, error handling (e.g., user not available), and prerequisites beyond sessionToken. Incomplete for a booking tool with three parameters.

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% (only sessionToken described). The description adds 'Default 30 minutes' for minutes but doesn't explain the min/max range (10-120) from schema. profileId is not described at all, leaving its role unclear. The description fails to compensate for low schema coverage.

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 explicitly states 'instant session' and 'the booking starts immediately' with a clear outcome (roomUrl). It distinguishes from book_session by specifying it's for availableNow users, making the purpose specific and distinct.

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 mentions 'Same pricing as book_session' and 'Default 30 minutes', providing some guidance on pricing and duration. However, it does not explicitly state when to use this tool versus alternatives like book_session or become_available, nor does it outline when not to use it.

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 transparently explains the pricing logic (free first session, credit redemption, self-set rate) and instructs the agent to tell the user the payment result. This is good but could mention if the operation is destructive or has side effects.

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: first states purpose, second explains pricing and result guidance. No unnecessary words; each sentence adds value.

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?

No output schema, but the description covers what the result contains ('what was paid') and instructs the agent to communicate it. It doesn't address potential error cases or confirmations, but is sufficient for a booking tool.

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 33% (only sessionToken has a description). The description adds minimal meaning: 'slot' and 'profile' are implied by the purpose, but no explicit details or constraints are given for slotId and profileId.

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 clearly states the action ('Book an open slot with a person'), which is specific and distinguishes it from siblings like 'book_now'. The addition of pricing details further clarifies the tool's function.

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 implies usage by mentioning pricing rules, but it does not explicitly state when to use this tool versus alternatives such as 'book_now'. No exclusions or context-dependent guidance is provided.

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 provided, the description clearly discloses behavioral traits: refund, credit return, and slot reopening. It does not mention potential side effects like notifications or cancellation limits, but it adequately covers the primary effects.

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 that efficiently conveys the tool's purpose and effects without unnecessary words.

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 main effects but lacks explanation of the return value, prerequisites (e.g., booking must be confirmed), and does not address the undocumented bookingId parameter. It is adequate for a simple cancel action but has 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 coverage is 50% (only sessionToken has a description). The tool description adds no additional meaning to the parameters; bookingId remains undocumented. This fails to compensate for the missing schema descriptions.

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 clearly states the action 'Cancel a confirmed booking' and specifies the results: charge refunded, credit returned, slot reopens. It distinguishes from sibling tools like 'book_now' and 'book_session'.

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 implies use for cancellation but provides no explicit guidance on when to use this tool versus alternatives, such as when a booking cannot be cancelled or if other tools exist for modifying bookings.

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, so description carries full burden. Discloses that messages are marked delivered upon retrieval. Shows it is a read-only 'heartbeat' operation. Adequate for a simple 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?

Two sentences. Front-loaded with purpose and usage. No filler; every word earns its place.

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?

Tool is simple with one parameter and no output schema. Description covers what it does, when to call, how output should be used, and side effect (marking delivered). Nothing missing.

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?

Only one parameter (sessionToken) with 100% schema coverage. Description adds critical security guidance: 'private', 'never show it to the user', and explains origin (finish_sign_in). Greatly enhances 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?

Clear verb and resource: check messages. States it returns unread messages from all connections. Distinguishes from siblings like send_message by being a read operation.

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?

Explicit when to use: 'call whenever your user shows up.' Provides context that messages are marked delivered and should be relayed verbatim. Does not explicitly list alternatives, but context is sufficient.

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 provided; description only says 'close an open brief', implying a state change but not disclosing side effects, reversibility, or required permissions. Minimal behavioral info.

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?

Extremely concise single sentence, no unnecessary words. However, could benefit from a brief note on parameters or effects.

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?

Given no annotations, no output schema, and low schema coverage, the description lacks details about return values, side effects, or prerequisites. Adequate only for the simplest 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 50%: the description does not explain 'briefId' beyond its name, and 'sessionToken' has schema-level documentation. The description adds no additional semantic meaning to parameters.

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?

Description clearly states the action: closing an open brief, with explicit reasons (found someone or need passed). It distinguishes from siblings like 'open_briefs' and 'file_brief' by specifying the context.

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 guidance on when to use versus alternatives like 'file_brief'. The description implies usage for closing a brief when a person is found or need is gone, but lacks exclusion criteria.

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 disclose behavior. It mentions what happens with no topic (returns index) but does not describe what happens for a valid topic (return type, side effects, permissions). Minimal disclosure.

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 two sentences, fairly concise. However, the list of topics is run-on and could be better formatted. Every sentence serves a purpose, but structure is suboptimal.

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?

Given no output schema and only one parameter with no description, the description should provide comprehensive context. It gives a partial list of topics and a special case for no topic, but it does not explain the return behavior for valid topics or the exact output format. Incomplete.

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 no description for the 'topic' parameter. The description lists possible values (active_listening, etc.), adding implicit enumeration. However, it does not explain the parameter's purpose or format.

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 it is a curriculum for coaching, listing topics, but does not explicitly state what the tool does (e.g., retrieve information about a topic or list all topics). The verb is implied rather than stated. It is somewhat vague.

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 suggests using the tool to ground cues, debriefs, and artifacts, which implies when to use it. However, it does not compare with sibling tools or specify exclusions. Context is implicit.

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 provided, and the description only says the result is visible to the person and their agent. Does not disclose if the action is idempotent, side effects, authorization needs, or error conditions. Very limited behavioral context.

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 very short (two sentences), which is concise but at the expense of necessary detail. It front-loads the purpose but omits parameter semantics and usage context, making it too brief to be fully effective.

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 3 required params, no output schema, and no annotations, the description should provide more context. It fails to explain the return value, the meaning of 'sessionToken' (partially covered in schema), or the expected result format. Incomplete for a tool of moderate complexity.

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 33% (sessionToken has description). The description adds no meaning for 'result' (minLength 10 but no format) or 'assignmentId'. It vaguely references 'what the script asked for' but doesn't specify the expected format or constraints.

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 clearly states the action is 'post back what the script asked for' for an assigned exercise, and mentions the result lands in a connection. It distinguishes from siblings like 'complete_session' by focusing on assignments, but could be sharper on what exactly is posted.

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 guidance on when to use vs alternatives like 'complete_session'. No prerequisites or context for usage. The description implies it's for after an assigned exercise, but no explicit limitations or when-not to use.

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 provided; description adds behavioral context: PRO earns credit and quality record grows. Does not mention irreversibility or auth, but details are useful.

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 key usage directive. No wasted words.

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?

No output schema or annotations, but description explains purpose and outcome. With only two simple parameters, it is fairly complete, though could mention expected response.

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% and description does not describe parameters. No additional meaning beyond schema, so baseline 3.

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?

Clearly states the tool marks a session completed, with the purpose of earning credits and building quality records. Distinct from siblings like book_session and cancel_booking.

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?

Explicitly says 'Call after a session actually happened,' providing clear context. No exclusions or alternatives mentioned, but sufficient for this 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?

Describes that script contains instructions for client's agent and that public artifacts join the shared library. But without annotations, it doesn't fully disclose behavioral traits such as creation side effects, authentication requirements (implied by sessionToken), or if overwriting is possible.

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 efficient sentences with clear front-loading of purpose. However, could benefit from a brief note on what the tool returns or prerequisites.

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 creation tool with 5 parameters and no output schema, the description lacks details on success/error outcomes, duplication handling, permissions, or typical usage flow. Given the complexity, more context is needed.

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 80%, and description adds meaningful context for two parameters: script (explains it's facilitator instructions) and isPublic (public artifacts join library). Other parameters rely on schema descriptions. This adds value beyond 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 'design an interactive exercise ONCE' with specific examples, clearly distinguishing from assign_artifact (assigning vs creating). However, it doesn't explicitly differentiate from artifact_library (viewing) or coaching_playbook (patterns).

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 guidance on when to use this tool vs siblings. It mentions 'see coaching_playbook topic artifact_patterns' but doesn't clarify when to use this vs assign_artifact or other related tools.

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?

Discloses key behaviors: money is refunded on success, forfeited on failure, and a $500 active stake cap is enforced. With no annotations provided, the description carries the full burden and does so reasonably well, though it could mention idempotency or side effects on user balance.

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 three sentences plus a tip, with no wasted words. The core action is front-loaded in the first sentence, making it easy to parse.

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?

Covers the stake mechanism, cap, and output hint. Lacks explanation of the `details` and `witnessConnectionId` parameters, but these are described in the schema. For a tool with 6 parameters and no output schema, the description provides sufficient context for an agent using the tool.

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 covers 67% of parameters with descriptions. The textual description adds value by advising on concrete titles and noting the result reports headroom. This supplements the schema guidance effectively.

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 clearly states the core function: 'The user stakes real money on doing a specific thing by a deadline.' It distinguishes the tool from siblings by focusing on creating a new commitment with a monetary penalty, unlike view or resolve tools.

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 provides actionable guidance: 'Make the title concrete and checkable' and 'Follow up with the user before the deadline.' It also mentions the $500 cap. However, it does not explicitly state when not to use this tool versus alternatives.

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 fully disclose behavior. It mentions it's a private, anonymous write operation that returns today's candidates as working material. However, it does not clarify if this is a creation vs update, whether existing briefs are overwritten, or what happens to the data. It also lacks details on the return format or any side effects (e.g., whether it triggers notifications).

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 well-structured with clear sections: purpose, behavior, instructions, and next steps. It is slightly verbose but each sentence adds value (e.g., 'Never paste or read the draft back to the user' is critical). Could be trimmed without losing meaning, but overall effective.

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?

Given no output schema and minimal annotations, the description covers key aspects: purpose, usage steps, and what is returned (candidates). However, it lacks details on the exact structure of candidates, how to interpret them, and whether the brief can be modified later. For a simple tool, it is mostly complete but leaves some gaps in behavioral expectations.

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 description adds significant meaning to the 'need' parameter (not described in schema) by specifying it should include situation, target person, and desired cadence. The 'sessionToken' parameter is already described in schema, but the description reinforces privacy by saying 'never show it to the user'. For a 50% schema coverage, this compensates well.

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 clearly states the tool is for filing a brief (a demand-side document), contrasting it with a search and specifying it should be private and anonymous. It distinguishes from siblings like 'my_briefs' (checking previous briefs) and 'show_people' (selecting candidates). The verb 'file' and resource 'brief' are specific and 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 provides clear instructions on when to use (to file a demand brief), what to do (write real sentences, not paste/read draft), and next steps (select up to three candidates and call show_people; check my_briefs later). It implies alternatives (e.g., open_briefs for existing briefs) but doesn't explicitly state when not to use it.

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 full burden. It discloses core behavior (exchange secrets, return token) and warns about not exposing secrets. However, it lacks details on error handling, rate limits, or auth requirements.

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?

Description is two sentences with no filler. The first sentence front-loads the action and inputs; the second adds state explanation and a critical security warning.

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 auth handoff with 2 parameters and no output schema, the description adequately covers the flow, states, and output (sessionToken). It lacks error or edge case info but is sufficient for basic use.

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 has 0% description coverage, so description must add meaning. It notes that requestId and pollSecret come from begin_sign_in, but does not explain their roles or format beyond what the schema already provides.

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?

Description clearly states the tool's purpose: exchanging private requestId and pollSecret from begin_sign_in to finish sign-in and return a sessionToken. Verb+resource is specific and distinguishable from sibling begin_sign_in.

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?

Description specifies when to use ('After the user chooses 'I've signed in'') and explains state meanings ('Pending' vs 'complete'). However, it does not explicitly state when not to use or list alternatives.

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 full burden. It discloses that results are limited to open, future slots sorted soonest first, but does not describe the structure of a slot (e.g., time, duration) or any other behaviors like pagination or authorization needs.

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, well-structured sentence that front-loads the key information (open slots) and includes a sorting qualifier. No unnecessary words.

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 core purpose but lacks details on return value structure, potential date ranges, or any constraints. For a simple tool with one parameter and no output schema, it is adequate but not thorough.

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 description only says 'for a person,' which implies the profileId parameter identifies the person. It adds minimal meaning beyond the schema, leaving the format and purpose of profileId unclear.

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 clearly states the tool retrieves 'Open (unbooked, future) slots for a person, soonest first.' It specifies the resource (availability slots), the action (get/list), and a sorting order, distinguishing it from sibling tools like 'add_availability' or 'book_session'.

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 implies the tool is for checking availability before booking, but it does not explicitly state when to use it versus alternatives such as 'my_bookings' or 'become_available'. No exclusions or context are provided.

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?

Discloses return scope (story + corpus) but lacks information on read-only nature, authentication, rate limits, or side effects; no annotations provide support.

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?

Single sentence with no unnecessary words, efficiently communicates the core purpose.

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?

Missing details on output format, error handling, and prerequisites; for a simple tool it is sparse but not insufficient for basic use.

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?

Only parameter 'profileId' is a string; description adds minimal clarity beyond schema, just stating it's an ID, without format or origin guidance.

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?

Clearly states the tool fetches a full profile (story + corpus) for one person by profile id, distinguishing it from list or search tools.

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 guidance on when to use versus alternatives like 'list_people' or 'my_profile'; missing context for when not to use.

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 provided, so description carries full burden. It describes the panel behavior (no action buttons) and agent action (present paths), but does not disclose side effects, idempotency, or state changes.

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 concise sentences; front-loaded with purpose and usage; no wasted words.

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?

Adequate for a simple onboarding tool with no parameters or output schema. Covers purpose, usage, and agent action; could benefit from mentioning if it affects user state.

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?

No parameters; schema coverage is 100% trivially. Baseline for 0 params is 4. Description adds context about when to call but no param info needed.

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?

Clearly states it is for orienting a first-time user, called FIRST when user is new or unsure. Distinguishes from sibling tools by its onboarding role.

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?

Explicitly states when to call ('FIRST when a user has just connected or is unsure') and provides instruction to not repeat panel information, but does not mention when not to use or alternative tools.

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 cover behavioral traits. It states that the tool NEVER renders to the user and reads silently, but does not disclose potential side effects, permissions, or data access implications. Adequate but not thorough.

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 overly verbose and includes imperative instructions that could be streamlined. It contains multiple sentences that could be condensed without losing meaning, reducing clarity.

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 fails to specify what the tool returns (e.g., list of people IDs or profiles). It implies the output is used to call show_people but does not clarify format or edge cases, leaving gaps for an AI agent.

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 100% with good descriptions for each parameter. The description adds usage context (e.g., deciding which constraints follow) but does not enhance understanding of individual parameter meaning beyond 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?

The description clearly states the tool is for private discovery and never renders to the user. It distinguishes from show_people by specifying it is a silent read-only step. However, the statement is somewhat convoluted with workflow instructions, making it less direct.

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 explicitly instructs to select 1-3 people and call show_people with the same filters, providing context on how to use the results. It also tells what not to do (never narrate). Lacks explicit mention of when not to use this tool, but gives clear 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?

No annotations are provided, so the description carries the full burden. It clearly states that the token is invalidated and re-login is required, which is sufficient behavioral disclosure for a simple tool. Could be slightly more explicit about irreversibility, but 'no longer works' implies it.

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, no fluff. The first sentence front-loads the purpose, and the second explains the consequence. Every word earns its place.

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 tool with one parameter and no output schema, the description covers the main effect and provides context. It does not mention error cases (e.g., invalid token), but that is acceptable for a straightforward operation.

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 100%, and the schema description of 'sessionToken' is very detailed (origin, reuse, privacy warning). The description adds minimal extra meaning ('Invalidate a sessionToken'), so it meets the baseline but does not significantly enhance beyond 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?

The description clearly states the action: invalidate a sessionToken. It provides a specific use case (shared device) and distinguishes itself from other tools; no sibling tool has a similar purpose.

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 the effect (token no longer works, must login again) and gives an example context (shared device). It implies when to use, but does not explicitly mention when not to use or alternatives; however, given the single logout tool, this is adequate.

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?

Discloses that it's private, never renders a panel, returns only three candidates, and instructs to read silently without narration, compensating for missing 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 concise sentences, front-loaded with key purpose and usage, no superfluous 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?

Given sibling tools list_people and show_people, and no output schema, the description fully covers when and how to use this pre-ranker, including the follow-up action.

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%; description adds context for limit (max three candidates) but does not elaborate on need beyond schema. Baseline 3 is appropriate.

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?

Clearly states it's a private fallback pre-ranker for when list_people is too large, returns at most three candidates, and distinguishes from show_people and list_people.

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?

Explicitly says when to use (when list_people too large), what to do after (call show_people with selected IDs), and what not to do (do not narrate ranking or results).

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 but only mentions the inclusion of adoption counts. It does not disclose whether the operation is read-only, the scope of data returned, or any side effects, leaving significant ambiguity.

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 extremely short at six words, which is efficient but borderline terse. It conveys the core purpose without unnecessary detail, though a full sentence would improve readability.

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?

Given the tool's simplicity (one parameter, no output schema), the description provides minimal context. It hints at output structure (adoption counts) but does not clarify what an 'artifact' is or what other fields might be returned, leaving some incompleteness.

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 100% for the single parameter, and the schema itself provides thorough documentation for 'sessionToken'. The tool description adds no additional parameter information, so standard baseline 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 'Artifacts this pro designed, with adoption counts' clearly states the tool retrieves artifacts created by the current user, including adoption metrics. It implicitly distinguishes from sibling tools like 'artifact_library' (all artifacts) and 'create_artifact'.

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 guidance is provided on when to use this tool versus alternatives such as 'artifact_library' or 'my_assignments'. The description lacks context about appropriate use cases or prerequisites beyond the session token.

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 are absent, so description carries full burden. It describes a read-only operation ('Client-side: pending exercises') with no hints of destructive behavior. Mentions conversational execution but lacks details on permissions or side effects, though acceptable for a list 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?

Two sentences, no filler. First sentence frames the tool's purpose, second provides actionable guidance. Every part earns its place.

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, description implies return of 'scripts' or 'exercises' but doesn't detail structure. However, the purpose is simple and the follow-on tool (complete_assignment) suggests each item has an identifier. Adequate for the agent's needs.

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 100% with one parameter. Description adds significant meaning beyond schema: explains origin of sessionToken, reusability, and security caution ('never show it to the user'), surpassing the schema's basic minLength constraint.

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?

Description clearly states the tool retrieves 'pending exercises assigned by the user's people,' with a specific verb and resource. The title 'Exercises waiting for the user' reinforces this. It distinguishes from sibling tools like 'complete_assignment' by indicating the subsequent action.

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?

Explicitly instructs to 'Run each script conversationally... then complete_assignment,' providing clear context for when to use this tool and what to do after. No explicit when-not-to-use given, but context is sufficient.

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?

Without annotations, the description carries full burden. It only reveals ordering ('soonest first') but does not disclose whether it's read-only, authentication beyond sessionToken, or response format. Insufficient for a safe autonomous agent.

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?

Single sentence, no filler, all words serve a purpose. Efficiently conveys core behavior.

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?

Missing output schema, no pagination or filtering details. Does not explain what fields a booking includes. Inadequate for a tool that lists data, especially given the absence of annotations.

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 100% with sessionToken description. The tool description adds no additional meaning to the parameter, but baseline 3 is appropriate since no gap exists.

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 clearly states that the tool returns bookings where the user is both client and pro, ordered soonest first. It distinguishes from sibling tools like book_now and cancel_booking by focusing on listing.

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 guidance on when to use this tool over alternatives. The description implies it's for viewing existing bookings, but does not mention when not to use it or provide context relative to 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 implies a read operation but does not explicitly state side effects, permissions, or that it is safe to call. It adds some context about the data returned but lacks a clear behavioral disclosure.

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: the first states the core functionality, the second gives usage advice. No wasted words, front-loaded with key information. Excellent structure.

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 list tool with one parameter and no output schema, the description covers the essential return content and when to use it. It could optionally mention that no output schema means the agent should expect a list of briefs, but the description is sufficient given the tool's simplicity.

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 input schema fully describes the sole parameter (sessionToken), with 100% coverage. The description does not add any new information about the parameter's meaning or usage beyond what the schema already provides, so baseline score is appropriate.

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 clearly states the tool returns 'All briefs with matching re-run against today's marketplace plus any intros received,' specifying the exact resource and scope. It distinguishes from siblings like open_briefs by mentioning the re-run and intros aspects.

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 advises 'Call when your user returns — new people may have joined since the brief was filed,' providing clear timing context. It does not explicitly exclude alternative scenarios or compare to siblings, but the advice is actionable.

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 states the tool returns debriefs in reverse chronological order, implying a read-only, non-destructive operation. It does not disclose behavior if empty or error cases, but the purpose is clear and no contradictory hints are given.

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 three sentences: first defines the content and order, second advises usage, third adds motivational context. No redundant words, and core information is front-loaded.

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 one simple parameter and no output schema, the description covers what the tool returns (AI debriefs, newest first), its purpose (private improvement record), and usage timing (before next session). It lacks explicit mention of output format but is sufficient for an agent 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?

Schema coverage is 100% with a single parameter described in the schema. The description adds no extra meaning beyond the schema's explanation of sessionToken. Baseline 3 is appropriate as the schema does the heavy lifting.

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 clearly states it provides 'AI debriefs from sessions the user ran as the pro, newest first,' which is a specific verb-resource combination. It distinguishes from sibling tools like session_debrief (which likely returns a single debrief) and my_bookings (which lists bookings) by emphasizing the coaching improvement record and private nature.

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 explicitly advises to 'Read it before their next session and coach them on the recurring growth themes,' giving clear context for use. It does not explicitly exclude alternative tools, but the purpose context separates it from other tools like session_transcript or session_debrief.

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 provided, so description must carry full burden. Discloses ordering (active first) but omits authentication requirement (though sessionToken is in schema), rate limits, or response format. Minimal behavioral context beyond ordering.

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 wasted words. First sentence states function, second gives a practical use case. Efficient and front-loaded.

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 list tool with no output schema, the description covers purpose, ordering, and a use case. Minor gaps: no mention of output format or potential pagination, but acceptable for the tool's complexity.

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 100% for the single parameter (sessionToken), so the description adds no extra meaning. Baseline 3 is appropriate; the schema already documents the parameter sufficiently.

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?

Clearly identifies the resource (commitments) and action (list all with status and deadlines). The ordering 'active first' adds specificity. However, it does not explicitly distinguish from siblings like create_commitment or resolve_commitment, though the name implies listing.

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?

Suggests a use case (checking for approaching deadlines to nudge) but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, but the context is implied by sibling names.

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 provided, the description carries the full burden of disclosure. It states what data is returned (who, context brief, last message, commitments) implying a read operation, but does not explicitly confirm read-only behavior, pagination, or authentication requirements beyond the session token parameter. This is adequate but not comprehensive.

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 consists of two concise sentences that front-load the core purpose ('Every connection') and list key fields. Every word adds value; there is no redundancy or 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?

Given the tool's simplicity (1 parameter, no output schema, no nested objects), the description sufficiently covers the returned content. It does not specify the format (e.g., list structure), but the context from the title and sibling names implies a list. Minor gap: no mention of ordering or filtering, but overall complete for a straightforward retrieval tool.

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 input schema has 100% coverage for the single parameter (sessionToken), and its description is detailed. The tool description adds no additional meaning about parameters. Per the rubric, baseline 3 is appropriate since schema coverage is high.

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 title 'The user's standing relationships' and description 'Every connection: who, context brief, last message, active witnessed commitments' clearly identify the tool as a list of connections. It distinguishes from siblings like 'list_people' or 'show_people' by focusing on relationships the user is responsible for, though it does not explicitly contrast with alternatives.

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 provides no guidance on when to use this tool versus siblings such as 'list_people', 'show_people', or 'my_briefs'. It omits any context about prerequisites, filters, or scenarios where this tool is preferred.

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 full burden. It mentions that credits auto-redeem on next paid booking, but does not disclose whether the tool is read-only, alters state, or requires specific permissions.

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 concise sentences with no unnecessary words. Front-loaded with the key concept of unredeemed credits.

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 read tool with one parameter and no output schema, the description is basic but adequate. It covers what the tool returns and a behavioral note on auto-redeem, but lacks usage context.

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 100% and the schema description for sessionToken is detailed (origin and privacy instructions). The tool description adds no parameter info, but baseline 3 is appropriate given full schema coverage.

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 clearly defines the tool's purpose: retrieving unredeemed session credits. It distinguishes itself from sibling tools that deal with bookings or other actions, but does not explicitly differentiate.

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 guidance on when to use this tool versus alternatives, such as why one would check credits before booking. No prerequisites or exclusions mentioned.

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 provided; the description only states it lists pending intros. It does not disclose whether the operation is read-only (though implied), requires authentication beyond sessionToken, or has any side effects. Minimal behavioral disclosure beyond the obvious.

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 extremely concise (one sentence). While it contains no wasted words, it lacks detail that could help an agent, making it borderline under-specified. Scores 3 for being short but not optimally informative.

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?

Despite the tool's simplicity, the description omits important context: what the output contains, whether there is pagination, and how it differs from other list tools. The reference to 'respond_intro' is helpful but insufficient for complete understanding without an output schema.

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 provides full description for the only parameter 'sessionToken', achieving 100% coverage. The tool description adds no additional semantic value beyond the schema, so baseline 3 is appropriate.

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 title 'Intros waiting for the user's answer' and description 'Pending intros addressed to the user. Respond with respond_intro.' clearly indicate that this tool lists pending intros. It distinguishes from siblings by explicitly naming the follow-up action 'respond_intro', suggesting this is a read-only list tool.

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 guidance on when to use this tool versus alternatives like 'check_messages' or 'my_connections'. The only hint is 'Respond with respond_intro', which implies usage but no explicit context on prerequisites or when not to use.

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 discloses that the tool returns composite information (profile, credits, sessions, commitments). However, it does not explicitly state that the operation is read-only or idempotent, which would be helpful for behavioral transparency.

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 core purpose ('Status probe: ...'). Every sentence adds value with no waste. The second sentence reinforces usage guidance and efficiency.

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?

Given the tool has a single parameter and no output schema, the description provides sufficient overview of what the tool returns and when to use it. It is complete for its simplicity, though additional detail on the exact return structure could be beneficial.

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 100%, and the schema provides a thorough description of the sessionToken parameter. The tool description does not add additional parameter meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 clearly states it probes the user's status, including profile existence, bookability, credits, upcoming sessions, and active commitments. It uses a specific verb ('probe') and resource ('status'), and distinguishes from siblings by aggregating multiple aspects into one call.

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?

Explicitly advises calling this tool before assuming anything about the user's state, noting it's cheaper than asking. This provides clear context for when to use it, though it does not explicitly mention when not to use it or list alternatives.

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?

The description discloses that briefs are anonymous ('the need, never the person') and targets supply-side users. No annotations exist, so the description carries the burden. It does not mention authentication needs, rate limits, or any side effects, but the anonymity is a key behavioral trait noted.

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 three short sentences, front-loading the core purpose. Every sentence adds value: anonymity, use cases, and follow-up action. No wasted words.

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?

Given no parameters and no output schema, the description covers the concept of open briefs, anonymity, and target audience. It lacks specifics on output format but is sufficient for an agent to understand the tool's function.

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 input schema has zero parameters, so schema coverage is 100%. The description adds context about what the tool returns (open briefs) and its purpose, which is appropriate for a parameterless tool.

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 clearly states the tool opens 'briefs, anonymous' to show demand to supply-side pros or would-be pros. It uses a specific verb 'open' and distinguishes from sibling tools like file_brief and close_brief.

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 when to use: to show pros what demand exists or hesitant would-be pros that people are waiting. It mentions a follow-up action (send_intro) but does not explicitly state when not to use or exclude alternatives.

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 provided, the description must fully disclose behavior. It reveals that the tool is a write operation, client-side, consent-required, and replaces an intake interview. It lacks details on idempotency, error conditions, or what happens on multiple calls, but covers key behavioral traits sufficiently.

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 concise (two sentences) and front-loaded with the core purpose. It efficiently conveys scope ('Client-side only, with the user's consent') and outcome. Could be slightly more structured, but no wasted words.

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?

Given no output schema, the description should ideally mention what the tool returns or confirms. It describes the effect ('so their person starts knowing everything') but omits any return value or success indication. Parameter coverage is moderate, and the tool's simplicity somewhat compensates.

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 67% (two of three parameters have descriptions). The description adds meaningful context for 'context' (e.g., 'what is going on, history...') beyond the schema's minimal description. For 'sessionToken', it re-emphasizes reuse and privacy. 'connectionId' has no description in either, so some gap remains.

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 ('write') and resource ('the full situation into the connection'), clearly stating the tool's action and outcome. It also differentiates by claiming it 'replaces the intake interview,' which distinguishes it from sibling tools like 'file_brief' or 'write_debrief.'

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 specifies where it runs ('Client-side only') and a prerequisite ('with the user's consent'). It explains when to use ('to provide full situation, replaces intake') and hints at ongoing usage ('Update it as things evolve'). However, it does not explicitly state when NOT to use or mention specific alternatives among 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?

Discloses that the tool changes state (refund vs forfeit) and that it relies on self-reporting. Annotations are absent, so the description carries the burden, but it omits details like permissions, reversibility, or error cases.

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 concise sentences front-load the purpose and outcome, with zero wasted words.

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?

Given no output schema, no annotations, and incomplete parameter documentation, the description lacks details on return values, errors, or how to obtain commitmentId. The behavioral guidance is helpful but insufficient for full understanding.

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 low (25%, only sessionToken described). The description adds no parameter-level information, leaving commitmentId, succeeded, and note 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?

Clearly states the verb 'resolve' and the resource 'commitment', and distinguishes itself from sibling tools like create_commitment and my_commitments by specifying it acts on an active commitment with outcome-dependent consequences.

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?

Explicitly instructs the agent to self-report by asking the user directly and recording honestly, which serves as a usage guideline. However, it does not mention when not to use this tool or provide alternatives.

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?

The description discloses that accepting creates a CONNECTION where messages, sessions, artifacts, and commitments live, and advises port_context. However, it does not explain what happens on decline, any irreversible actions, or authorization requirements. No annotations are provided.

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 concise with two sentences. The first states the primary action, the second gives a specific instruction. It is front-loaded but could be slightly more structured.

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 tool has 3 required parameters, no output schema, and no annotations. The description lacks information about return values, error handling, or behavior on decline. It is not complete given the complexity.

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?

Only 33% of parameters have schema descriptions (sessionToken). The description adds no extra meaning to 'accept' (boolean) or 'introId' (string); it does not clarify that accept=true means accept and accept=false means decline. The tool needs this clarification.

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?

Title 'Accept or decline an intro' combined with description clearly states the tool's purpose: responding to an intro by accepting or declining. The description explains that accepting creates a connection. However, it does not differentiate from sibling tools like 'send_intro' or 'port_context'.

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 provides a usage hint: 'If your user is the client side, immediately port_context so their person knows exactly what is going on.' This gives contextual guidance for one scenario but does not specify when to use this tool vs alternatives or when not to use it.

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 bears full responsibility. It discloses that the cue is private to the pro's panel and invisible to the client. However, it does not mention error conditions or session state requirements, though the context is clear.

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 extremely concise—two sentences—and front-loads the most critical information. Every sentence serves a purpose without 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?

For a tool with 3 parameters and no output schema or annotations, the description covers the use case, constraints, and privacy aspect well. It lacks details on return values or error handling, but for a simple cue tool, this is adequate.

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 description adds meaning for the `text` parameter by imposing a 25-word limit and specifying content type, but the schema allows up to 400 characters, creating a potential inconsistency. It does not clarify `bookingId` or `sessionToken` beyond the schema's minimal description for `sessionToken`. Schema coverage is low (33%), and the description only partially compensates.

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 clearly states the tool's purpose: sending a private cue to a pro during a live session. It uses specific verbs ('whisper', 'appears quietly') and distinguishes itself from sibling tools like `send_message` by emphasizing pro-only and client invisibility.

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?

Explicitly states when to use the tool ('pro-only, during a live session') and provides detailed content guidelines (one short cue, max 25 words, specific, not generic advice). Also mentions 'silence is fine', indicating optional usage.

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. It discloses that emails are not exposed and that acceptance creates a connection, but does not discuss authentication, rate limits, or error states.

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 sentences with no wasted words. The key information is front-loaded, and the structure is clear.

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?

Given the tool has no output schema and no annotations, the description covers the main purpose, parameter roles, and outcome. It lacks response format and error info but is adequate for a simple intro tool.

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 description adds meaning to the undocumented briefId and profileId parameters by explaining their distinct purposes. For sessionToken and message, the schema already provides good descriptions, so the description complements effectively.

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 clearly states the tool sends a short real intro through the platform, specifying two directions (profileId and briefId). This distinguishes it from siblings like respond_intro or send_message.

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 when to use each parameter (profileId vs briefId) but does not explicitly state when not to use the tool or mention alternatives among sibling tools.

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 should disclose behavioral traits. It mentions async and bidirectionality, but fails to state side effects (e.g., delivery notification, storage), idempotency, or error cases. Insufficient for safe autonomous 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?

Two sentences with no redundancy. Front-loaded with key idea. Could be slightly expanded for clarity without losing 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 simple three-parameter tool with no output schema, the description covers the basic purpose and a use case. However, it omits prerequisites (e.g., existing connection), return behavior, and error conditions, leaving the agent with 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 coverage is 33%; only sessionToken has schema description. The tool description adds no meaning for parameters like text or connectionId. It doesn't explain expected format, length constraints beyond schema, or any usage tips.

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 clearly states it's an async relay between two people, implying message sending. It distinguishes from siblings like 'send_cue' by emphasizing bidirectionality and daily check-ins. However, it could be more explicit about the verb 'send message'.

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 guidance on when to use this tool versus alternatives (e.g., send_cue, session_debrief). The mention of 'daily two-line check-in' suggests a specific context but doesn't help the agent decide among 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 must disclose behavioral traits. It notes privacy and auth constraints but does not describe success/error responses, rate limits, or what happens if conditions are not met (e.g., session not ended).

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 sentences, front-loaded with purpose and usage. Some wording could be tighter, but it efficiently conveys key information without unnecessary verbosity.

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 tool has no output schema and minimal annotations. The description explains the tool's purpose and the content of the debrief, but does not specify return format or error conditions, leaving 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 coverage is 50% (sessionToken described, bookingId not). The description adds no additional meaning to parameters beyond the hints in the schema. For bookingId, no context is provided.

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 clearly states that the tool retrieves an AI debrief for a session that has ended, distinguishing it from siblings like write_debrief and close_brief. However, the verb 'gets' is implicit rather than explicit like 'retrieve'.

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 specifies when to use ('After a session ends') and the required role ('Pro-only: the email must be the session's pro'). It gives context for helping the user prepare. It does not explicitly exclude alternative tools or conditions.

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?

Discloses consent-gating, participant restriction, and polling behavior with sinceMs, but does not detail authorization requirements or side effects since no annotations are provided.

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 concise sentences front-loaded with purpose, no redundant information, and efficiently covers key behavioral aspects.

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?

Adequately describes behavior and usage for a simple read tool, but does not explain the 'segment' return format; lacks output schema but description compensates reasonably.

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?

Adds value beyond schema by explaining the polling usage of sinceMs and the security context for sessionToken, though bookingId lacks description in both schema and text.

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 clearly states it reads a session's transcript, specifies it is consent-gated and for participants only, and distinguishes from sibling tools like session_debrief and send_cue.

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 explicit guidance for polling during live sessions with sinceMs and suggests using it to supervise before calling send_cue, though it lacks explicit 'when not to use' statements.

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 full burden. It thoroughly discloses the 15-minute activity window, that calling the tool counts as activity, and the heartbeat mechanism. No contradictions.

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 paragraph with multiple sentences, each adding value. It is slightly dense but well-structured and front-loaded with the core purpose. Every sentence justifies its presence.

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?

Given the tool's complexity (2 parameters, no output schema, no annotations), the description is comprehensive. It covers nuances like the two-part presence, re-call requirement, and integration with booking. No gaps identified.

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 100% with clear descriptions, but the description adds significant value: explains that sessionToken is private from finish_sign_in and never to be shown, and that open parameter works with activity status. Enhances understanding beyond 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?

The description clearly states the tool's purpose: setting the pro's instant-session status (open/closed). It distinguishes from siblings like 'book_now' and 'become_available' by explaining the two-part presence system and the specific role of this tool.

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 explicit guidance: use when the pro is at their desk, re-call within 15 minutes to stay live. Explains the consequence of higher ranking and bookability via book_now. Lacks explicit 'when not to use' or alternatives, but context is sufficient.

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 full burden. It discloses the tool is user-visible, displays one person at a time, and prohibits prose comparison or duplicate profile text. However, it does not explicitly state that the tool is read-only or whether it has side effects, though the context implies it is a display-only operation.

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 dense but not bloated; every sentence adds value. It front-loads the key point ('THE ONLY user-visible shortlist') and then provides step-by-step instructions. Minor improvement would be to separate the rendering instructions more clearly.

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?

Given no annotations and no output schema, the description is fairly complete: it explains the workflow, inputs, display behavior, and what the agent should render. It lacks explicit mention of return format or error conditions, but the rendering instructions partially compensate.

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 explains that 'profileIds' are 1-3 selected IDs and 'filters' are the formal filters applied, adding meaning beyond the schema. However, it does not describe each individual filter field (e.g., availableNow, maxHourlyRateDollars), leaving some semantic gaps.

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 clearly states that this tool is 'THE ONLY user-visible shortlist' and explains its role after using list_people or match_me. It distinguishes itself from sibling tools by specifying the input (1-3 profile IDs plus filters) and the output behavior (displays one person at a time).

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 explicit usage instructions: 'After silently reading list_people or match_me, pass 1-3 selected profile IDs plus the formal filters you actually applied.' It also specifies rendering requirements ('render one Claude-native choice per person and one escape choice; no prose comparison or duplicate profile text'), providing clear when-to-use and how-to-use guidance.

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 behavioral disclosure. It only lists updatable fields but does not indicate side effects, authorization requirements, or whether the update is atomic or partial. The mutation is implied but not elaborated.

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 sentence listing the key fields. It is efficient and front-loaded, with no wasted words. However, it could include a bit more context without becoming verbose.

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?

Given 7 parameters, low schema coverage, no output schema, and no annotations, the description is insufficient. It omits important context like what happens on success/failure, whether the update is partial, and the role of sessionToken. It covers some parameters but leaves 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 coverage is only 29%, so the description adds value by naming which fields can be updated: 'display name, headline, story, rate, or listing/visibility flags.' This clarifies parameters like story, headline, isListed, offersSessions, and hourlyRateDollars. However, it does not cover sessionToken or differentiate boolean flags.

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 clearly states what the tool does: 'Update display name, headline, story, rate, or listing/visibility flags.' This is a specific action on the user's profile, and the title confirms 'Update the user's profile.' No direct sibling tool updates a profile, so purpose is well-defined.

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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites or limitations. It does not mention that a session token is required or what happens if the user is not authenticated.

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?

Without annotations, the description carries the full burden. It discloses that the debrief feeds the pro's quality record and coaching history, and guides honest, specific writing. It does not detail side effects or auth requirements beyond 'Pro-only', but is fairly transparent.

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 paragraph, concise and front-loaded with key usage info. Every sentence adds value, though it could be slightly more structured.

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?

Given 5 required params, no output schema, and siblings like session_debrief, the description covers the tool's purpose, content format, and consequences. It does not explain return values, but that is acceptable.

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 low (20%). The description provides content guidelines for the fields (strengths, growth, drill) but does not explain sessionToken or bookingId. This partially compensates for the schema gaps.

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 clearly states it is for writing the pro's post-session debrief, specifying content structure (strengths, growth, drill). However, it does not explicitly distinguish from the sibling 'session_debrief', which may be similar.

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 specifies when to use: pro-only, after a session, and after reading the full transcript. It also notes 'one debrief per session'. It does not provide explicit when-not-to-use or alternatives, but the context is clear.

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