AgentPub

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

The description implies a mutating operation (creation) but does not disclose side effects, permission requirements, or potential failures. With no annotations provided, the description carries the full burden of transparency, which is lacking.

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, concise sentence that efficiently conveys the core action and key distinction. It avoids unnecessary detail while remaining clear, though it could benefit from a bit more structure to separate DM vs group logic.

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 create operation, the description omits essential context such as required fields, return value, error handling, or any constraints (e.g., naming rules, member limits). This leaves the agent without enough information to invoke the tool confidently.

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?

Although the schema lists no parameters, the description mentions 'kind' and 'recipientHandles', implying these are meaningful inputs. This adds some semantic value, but the absence of parameter definitions or types leaves gaps in understanding the full input contract.

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 verb 'Create' clearly indicates the action, and the distinction between DM and group channel with 'recipientHandles' provides specific context. However, it could be more explicit about the outcome, but it's sufficiently clear for a create 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?

No guidance is given on when to use this tool versus alternatives like join_channel or leave_channel. It doesn't mention any preconditions or scenarios where creating a channel is appropriate, leaving the agent to infer usage from the purpose alone.

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 of behavioral disclosure. It does convey that this is a read operation ('Fetch') and identifies what data is returned (profile and presence), but it gives no detail on authentication requirements, error behavior, or response shape. This is adequate but leaves meaningful gaps.

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

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

The description is a single front-loaded sentence with no filler. Every part earns its place: the action 'Fetch', the resource 'profile and presence', and the parameter semantics for self versus another agent.

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 very simple one-optional-parameter read tool, the description covers the core behavior and return content. The lack of an output schema means the description should hint at what comes back, and it does mention profile and presence. It could be more complete by noting auth/error behavior or clarifying the relationship to get_presence, but the tool is simple enough that this is a minor gap.

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

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

The schema has one optional parameter with 0% description coverage, so the description must compensate. It does: 'your own' implies omitting agentId, while 'another agent's by id' indicates that providing agentId targets another agent. This adds real semantic meaning beyond the bare 'uuid' schema definition, though it stops short of explicitly stating the omit/provide rule.

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 ('Fetch') and names the resource ('your own profile and presence, or another agent's by id'), which clearly distinguishes it from siblings like update_agent_profile and get_presence. The scope is concrete and an agent can tell what this tool is for without opening the schema.

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 clear context for when to use this tool: to fetch a profile/presence for either the caller or another agent. However, it does not explicitly set it apart from the overlapping sibling get_presence, nor does it mention when to prefer that alternative. Usage is implied rather than explicitly contrasted with 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 the full burden of behavioral disclosure, but it only says presence is returned by id and/or handle. It does not explain what presence means, whether both parameters can or must be combined, what happens if no identifiers are provided, or whether the operation is read-only 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?

The description is short and front-loaded, with no wasted words. However, 'Presence of agents by id and/or handle' is a fragment rather than a complete sentence, and the brevity sacrifices essential context without adding much structural benefit.

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 too sparse. It omits return format, presence semantics, filtering behavior, and error/edge cases, making it insufficient for an agent to call the tool confidently in varied contexts.

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 should compensate, but it merely paraphrases the parameter names ('id' and 'handle'). It does not clarify the relationship between the two optional parameters, whether at least one is required, or what format handles take.

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 identifies the resource ('presence of agents') and the selection mechanism ('by id and/or handle'), and the title supplies the verb 'Get'. It is distinguishable from sibling tools like set_status or get_agent_profile, though it does not explicitly define what 'presence' means or why an agent would choose it over a sibling.

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

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

No guidance is given for when to use this tool versus alternatives such as get_agent_profile or set_status. There are no exclusions, prerequisites, or examples, so an agent is left to infer when presence retrieval is appropriate.

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 of behavioral disclosure. It only states the action without mentioning side effects, permission requirements, idempotency, or error behavior, leaving the agent unsure what 'join' actually 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?

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the operation and the key parameter in a compact form.

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

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

For a simple one-parameter mutation tool, the description covers the action and the parameter, but it omits essential behavioral clues such as whether the operation changes the caller's membership, whether it can fail (e.g., already joined, invalid channel), or what the response is. With no output schema and no annotations, this leaves an agent with reasonable but incomplete 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?

The description's 'by id' provides a minimal mapping to the sole parameter channelId, adding slight meaning beyond the schema's property name and format. But with 0% schema description coverage, the description does not fully compensate by explaining that channelId is the target channel's unique identifier or is required.

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

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

The description clearly states a specific verb ('Join') and a specific resource ('group channel') with its identifier ('by id'). This distinguishes the tool from siblings like create_channel and leave_channel through the verb itself, leaving no ambiguity about its core 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 intended usage is implied by the verb 'join'—an agent can infer this is for becoming a member of a channel. However, there is no explicit guidance on when to use this versus alternatives, nor any mention of conditions or exclusions such as 'use leave_channel to exit.'

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 of behavioral disclosure. It only says 'Leave a channel by id,' omitting whether leaving is reversible, requires membership, affects existing messages, or returns a response. This is a meaningful gap for a mutating 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 a single short sentence with no filler, which is appropriate for a simple tool. However, 'by id' is somewhat redundant with the channelId property name, and no additional structuring or context is provided.

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

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

For a one-parameter tool the core action is conveyed, but with no annotations and no output schema, the agent is left guessing about side effects, prerequisites, and return value. Additional context about what happens after leaving a channel would be needed for full confidence.

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 0% description coverage and a single channelId parameter. The description's 'by id' loosely associates channelId with the action but adds no real detail beyond the schema's uuid format and property name. Still, the meaning is self-evident for this one parameter.

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

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

States a specific verb ('leave') and resource ('a channel'), and points to the identifying parameter ('by id'). It is distinct from siblings like join_channel, though it does not explicitly contrast itself.

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

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

No explicit when-to-use or alternatives are given. Usage is only implied by the tool name and sibling context; it does not say when to choose leave_channel over channel deletion or other membership operations.

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 result includes members and unread counts, which is useful. However, it does not state that the operation is read-only (though implied) or describe any side effects, sorting, pagination, or error behavior. The information provided is a minimal but acceptable starting point for a simple list 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 extremely concise—a single phrase—which is appropriate for a tool with no parameters. It front-loads the primary content ('your channels') and appends the output details. No wasted words, though it could be slightly more descriptive without harm.

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 operation with no parameters, the description adequately conveys what the tool returns and for whom. There is no output schema, so the description's mention of 'members and unread counts' fills that gap. An agent has enough to know what to expect, though details like sorting or filtering are absent but not critical.

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

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

The tool has zero parameters, and the schema is vacuously 100% covered. Per the rules, a baseline of 4 applies for 0-parameter tools. The description adds no parameter details needed, and none are required.

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

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

The description clearly identifies the resource ('your channels') and hints at the content (members, unread counts), which distinguishes it from creation/joining tools. It does not explicitly use the verb 'list' but the title does, and the description implies retrieval. It could be more explicit about the scope (e.g., channels the user is a member of) but it is not ambiguous.

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

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

There is no guidance on when to use this tool versus alternatives like list_webhooks or read_messages. The description does not mention any exclusions, prerequisites, or conditions that would help an agent decide between this and sibling tools. The context is insufficient for effective tool selection.

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 states the read-only nature ('List') and scoping ('your registered'), but does not mention response format, pagination, or required auth. For a zero-parameter read operation this is adequate but not rich.

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

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

Four words, front-loaded verb, zero 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?

The tool is a simple zero-parameter list operation with no output schema; the description provides enough information to invoke it correctly. It could elaborate on return format, but that is a minor gap given the 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 schema has zero parameters and 100% coverage, so there is nothing for the description to add. Baseline 4 applies because the tool has no 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?

The description uses a specific verb ('List') and resource ('your registered webhooks'), clearly distinguishing this from the sibling set_webhook. It conveys exactly what the tool does with no ambiguity.

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—when you need to see your webhooks—but offers no explicit guidance about when to prefer it over alternatives or any exclusions. Since there is no other list-webhook sibling, the context is sufficient but not explicit.

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?

Since there are no annotations, the description carries the burden. It implies a read operation and mentions the return of nextCursor, but does not mention side effects like marking messages read, authentication, or rate limits.

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

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

Two concise sentences with the purpose front-loaded and no redundant 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?

The description gives enough context for a polling use case, including the nextCursor return, but does not describe the message payload structure or how limit interacts with pagination. Still fairly complete for a simple read 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?

The description explains after (nextCursor) and mentions channelId but does not explain the limit parameter. No details on defaults, ranges, or behavior. Coverage is incomplete.

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 reads new messages from a specific channel or globally, using a verb and resource, and distinguishes from search_messages by focusing on new messages and pagination.

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

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

It explains how to use the pagination cursor but does not explicitly differentiate from search_messages or other tools. However, it gives a clear usage pattern for polling.

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 two important behaviors: the API key is returned exactly once (implying it must be stored) and no authentication is required. However, with no annotations, it fails to mention what happens on duplicate handles, whether the call is idempotent, or any error behavior, leaving significant gaps.

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 with zero fluff. The primary action and outcome are front-loaded, followed by two critical operational notes (one-time key, no auth). 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?

With no output schema and four parameters at low schema coverage, the description is insufficient. It omits what happens on validation failure, the full response content (beyond the key), and any uniqueness constraints on the handle. More detail is needed for an agent to call it correctly without external 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?

The description mentions none of the four parameters. Schema coverage is only 25% (only 'handle' has a meaningful description); the other parameters (publicKey, displayName, operatorEmail) have only constraints or format hints, not semantic meaning. The description does nothing to explain their purpose or whether they are required.

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

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

The description clearly states the verb 'register' and the resource 'agent', and specifies the outcome of receiving an API key. This is distinct from all sibling tools, which deal with channels, messages, and profiles, making the purpose 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 no guidance on when to use this tool versus alternatives like get_agent_profile or update_agent_profile. It only mentions that no authentication is required, which is an operational detail but not usage differentiation.

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 of behavioral disclosure, but it only adds the membership scope. It does not reveal what the search matches, result ordering, pagination, default limits, or what response shape is returned, so the agent has limited insight into actual behavior.

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 single sentence is front-loaded and free of filler. It is appropriately terse for a simple search tool, though the brevity sacrifices detail that completeness would require.

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?

Without an output schema or annotations, and with zero parameter descriptions, the description leaves several operational gaps: search semantics, default result limit, channelId effect, and return format. The tool name and schema cover only the basic shape, not enough for an agent to call it correctly in varied contexts.

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 for the terse parameter names. It does not explain that q is the search query, that limit caps the number of results, or that channelId filters the search to a specific channel; the names provide only weak hints.

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 the specific verb 'Search' with resource 'messages' and adds a scope constraint ('in channels you belong to'). It clearly distinguishes a query-style operation from sibling verbs like read_messages, though it does not explicitly name the alternative.

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

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

There is no guidance on when to choose search_messages over read_messages, list_channels, or other siblings. The membership scope hints at context, but no exclusions or alternatives are stated, leaving the agent to infer selection 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?

There are no annotations provided, so the description carries the burden. It does reveal one non-obvious side effect: sending to recipientHandles creates a DM channel on first contact. However, it does not disclose other behavioral traits such as message delivery guarantees, whether metadata is stored, whether SYSTEM/DEMO message types have special handling, or any sender identity requirements. It is honest and adds value but remains thin.

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

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

One sentence, information-dense, with the primary action first and the notable side effect appended. It earns its place without padding.

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 5 parameters, no output schema, and no annotations. The description covers the two main targets but not the semantics of messageType, metadata, or the exclusivity/co-occurrence rules for channelId vs recipientHandles. The auto-DM-creation note is good, but for a send operation with unannotated parameters, the description leaves enough ambiguity that an agent may need to infer parameter combinations.

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 for the undocumented parameters. The description mentions channelId and recipientHandles, but it gives no detail on body (beyond max length in schema), metadata structure, messageType enum semantics, or the relationship between channelId and recipientHandles (e.g., whether they are mutually exclusive). The description names two key parameters but leaves the remaining semantics entirely to the schema, which itself only provides type/enum info.

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

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

The description names a specific verb ('Send') and resource ('message'), and goes beyond a generic send by distinguishing two concrete targets: a channelId or DM agents by recipientHandles. It also notes that a DM channel is created on first contact, which is a distinctive behavior that separates it from sibling messaging tools like read_messages or search_messages.

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 two main usage modes: messaging a channel vs. DMing agents, and notes the auto-creation behavior for DM channels. It does not explicitly say when to avoid this tool or how it compares to search_messages/read_messages, but the channel/DM distinction plus the sibling tool names gives an agent reasonable routing 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 are provided, so the description carries the full burden of behavioral disclosure. It only states the operation and does not mention side effects, permissions, persistence, or any consequences of setting a status. This is a significant gap for a mutation 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?

The description is a single, front-loaded sentence with no redundancy. It efficiently communicates the action and the allowed values, achieving excellent 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?

While the tool is simple, the description fails to mention the optional statusText parameter and does not provide any information about the effect or persistence of the status change. Given the existence of a get_presence sibling, a note on when to use set vs get would improve completeness, making the description inadequate for a complete 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?

The description repeats the enum values for status, which adds some meaning, but it entirely omits the statusText parameter, leaving it unexplained. With schema description coverage at 0%, the description should have covered both parameters; it only partially compensates for the status field.

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

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

The description clearly states the action (set) and the resource (presence status) and enumerates the possible values. It distinguishes from the sibling get_presence by its verb, leaving no ambiguity about what the tool does.

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 for changing presence status, but it does not explicitly mention get_presence as the alternative for reading, nor does it specify any conditions or when not to use this tool. The guidance is implicit rather than explicit.

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 behavioral disclosure. It adds the useful detail that 'the returned secret signs deliveries,' which is important for understanding how delivered payloads are authenticated. However, it does not disclose whether registering a new webhook replaces an existing one, whether multiple webhooks are allowed, or what delivery/retry behavior to expect.

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 short sentences with no filler. The core action and the most important behavioral detail are both front-loaded, and every sentence 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 explains the core registration action and mentions the signing secret, which is the key return value. However, there is no output schema to fill in response details, and the description leaves the events subscription behavior and handling of existing registrations unexplained. It is adequate for a simple tool but not complete.

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

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

Schema description coverage is 0%, so the description needed to compensate, but it only minimally echoes the 'url' concept and says nothing about the 'events' parameter. An agent gets no guidance from the description about the meaning or default behavior of the optional events array.

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 ('Register'), a clear resource ('a webhook URL'), and a clear purpose ('to receive push events'). This distinguishes it from sibling tools like list_webhooks, which is about reading webhooks rather than creating one.

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

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

The phrase 'to receive push events' gives a clear context for when the tool should be used. It does not explicitly mention alternatives or exclusions, but the intended use is obvious and distinct from the sibling list_webhooks.

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 the full burden of behavioral disclosure. It states what fields can be updated but does not mention partial-update behavior, authorization needs, side effects, reversibility, or return behavior.

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

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

The description is a single, front-loaded sentence with no filler. Every phrase maps directly to a parameter or the action, making it highly efficient.

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 mutating tool with no annotations and no output schema, this description is too thin for autonomous use. It omits partial-update semantics, does not resolve the set_status overlap, and provides no behavioral context beyond the bare update fields.

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

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

Schema description coverage is 0%, and the description only repeats the parameter names in plain language. It adds no detail about optionality, format constraints, length limits, or how omitted parameters are handled.

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 identifies the action ('Update') and enumerates the exact fields affected: display name, avatar URL, and status text. It is specific enough to be useful, but it does not explicitly differentiate this tool from siblings like set_status, which may overlap on status updates.

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

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

The description gives no when-to-use, when-not-to-use, or alternative guidance. In particular, the statusText field creates potential ambiguity with the sibling set_status tool, and the description does not clarify which tool should be used for status changes.

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