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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses useful behavioral traits: default counting includes post, reply, and repost, excludes social signals like likes and follows, and results are cached for 60 seconds. It stops short of describing pagination or exact return format, but for a simple read-only list tool the disclosed behavior is solid.

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 tight sentences with no filler: the primary action is front-loaded, followed by usage guidance, default behavior, and caching. Every sentence adds meaningful information.

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

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

For a low-complexity tool with two optional parameters and no output schema, the description provides enough context to invoke it correctly: what it lists, why to use it, default counting scope, and caching. It does not detail the response shape beyond "apps with post counts," but that is likely sufficient for this simple list 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 input schema already describes the two parameters with 100% coverage, including examples, so the baseline is 3. The description adds context about default counting behavior when no parameters are supplied, but it does not explain parameter interactions or provide additional semantics 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 uses a specific verb and resource: "List all apps with post counts." It distinguishes itself from the sibling tools by focusing on app-level discovery on the shared social graph, naming concrete app examples. This makes the tool's purpose immediately clear and differentiates it from feed, stats, and user-level 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 gives a clear use case: "Use to discover which apps are active on the shared social graph." It does not explicitly state when not to use this tool or name alternatives, but the intended scenario is well conveyed and enough to guide an agent toward appropriate 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?

No annotations are provided, so the description carries the disclosure burden. It makes the read-only nature clear through 'Check' and names the external dependency WhatsOnChain, but it does not mention behavior for invalid addresses, network failures, or whether the lookup has any 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 concise sentences with no filler. The core action and scope are front-loaded, and the identity-file hint is directly useful to an agent selecting the tool.

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

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

For a single-parameter, read-only lookup, the description covers the tool's purpose, data source, and address source. The only notable gaps are the return denomination/format and error behavior, which are minor given there is no 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?

The input schema already fully documents the single 'address' parameter with 100% coverage. The description adds only the usage hint about where the user's address can be found, which is useful but does not materially expand 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 states a precise action ('Check'), a concrete resource ('BSV balance'), scope ('for any address'), and the data source ('via WhatsOnChain'). This clearly separates it from the many peck_* transaction and identity 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?

It gives a clear operating context: use the address from ~/.peck/identity.json. It does not explicitly discuss when not to use the tool or name alternatives, but for a simple balance lookup the applicable 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 are provided, so the description carries the burden. It discloses the data source (self-hosted headers.peck.to / Chaintracks) and the returned fields, which is useful. However, it doesn't mention potential failure modes (e.g., what happens for heights beyond the current chain tip), rate limits, or whether this is a read-only operation. The description is honest but not deeply 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?

Two sentences, front-loaded with the core function and returned fields, followed by a practical use case. 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?

For a simple single-parameter lookup tool, the description covers what it returns, the data source, and a motivating use case. It lacks an output schema and doesn't describe error behavior for invalid heights, but the simplicity of the tool makes the description largely sufficient.

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% (the only parameter 'height' is described as 'Block height.'). The description adds the context that height corresponds to a post's block_height and that the result can be converted to wall-clock time, but it doesn't add format or range details beyond the 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?

The description clearly states the tool's function: getting a BSV block header at a specific height, and lists the key fields returned (hash, merkleRoot, time, bits). It also distinguishes itself from sibling tools by mentioning its use case of converting a post's block_height into wall-clock time, which is unique among the listed siblings.

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 clear use case ('converting a post's block_height into a wall-clock time') and identifies the data source (self-hosted headers.peck.to / Chaintracks). It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to select it appropriately among the siblings.

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

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

With no annotations, the description carries the behavioral burden. It adds useful context about the self-hosted headers.peck.to (Chaintracks) source, but it does not disclose caching, freshness, potential lag behind the canonical chain, or the exact response shape. This leaves some uncertainty for an agent relying on the tip being current.

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 no filler. The core identity, source, and output fields are front-loaded, and the practical usage guidance is given in the second sentence. 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?

For a simple zero-parameter read-only tool with no output schema, the description covers the essential return fields and provides a concrete use case. It is nearly complete, but specifying the response format/types and freshness behavior would make it fully turnkey.

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

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

There are zero parameters, so the baseline of 4 applies; there is no schema burden for the description to compensate for. No parameter-level explanation is needed or 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 identifies a specific resource ('current BSV chain tip') and enumerates the returned fields: block height, hash, and time. It also names the serving infrastructure, making it easy to distinguish from siblings like peck_block_at_height, which targets a block at a specific height rather than the current tip.

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

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

It gives an explicit, actionable use case: compare a post's block_height to the tip height to reason about recency. However, it does not mention alternatives or when not to use this tool, so it falls short of full 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?

With no annotations, the description carries the behavioral burden. It discloses that this is a global, cross-app view of the social graph, the indexing starting point, and the chronological-walking behavior. It does not describe auth, rate limits, or output structure, but for a read-style browse tool the disclosed scope is substantial.

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 compact and front-loaded with the core purpose, then gives useful indexing and filtering details. Every sentence adds relevant information, and the historical-walk tip is practical without bloat.

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 is adequate for a simple feed-browsing tool, but there is no output schema and no mention of return value shape, pagination behavior beyond the schema, or how this tool relates to siblings like peck_recent and peck_search. These gaps leave an agent with some uncertainty about what to expect from the 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?

The schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds cross-parameter value by explaining the order=asc + since combination for historical walks, which is not explicit in the schema. This justifies the slight uplift.

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 browses the global BSV social feed, specifies the indexed data range from block 556767 onward, and lists the apps covered. It is specific and understandable, but it does not explicitly distinguish this tool from sibling tools like peck_recent, peck_trending, or peck_search.

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 the tool: browsing the shared global feed with filters. It also provides a concrete usage pattern, order=asc + since, for walking history chronologically. However, it does not mention when to prefer sibling tools or provide explicit exclusions.

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

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

With no annotations, the description carries the disclosure burden and does well by naming the returned fields and clarifying that load-status indicates whether a wallet has been spun up. It is clearly a read-only info operation. It doesn't cover error behavior or staleness of balance, 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?

Two sentences, no filler: the first enumerates the payload, the second states the intended use. Front-loaded and easy to scan.

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

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

For a single-parameter read tool with no output schema, the description supplies the return fields and a concrete use case, which is enough to invoke correctly. It could mention failure modes or balance freshness, but nothing essential is 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?

Schema coverage is 100%, with the single parameter documented as 'Account name from peck_fleet_list.' The description adds only implicit context (keychain account) but no extra semantics beyond the schema, so baseline 3 applies.

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

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

States a specific retrieval operation for a single fleet identity and enumerates the exact fields returned (keychain account, address, pubkey, load-status, default flag, balance). This distinguishes it from peck_fleet_list, which lists fleets, and from write-oriented siblings like peck_fleet_spawn.

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 tells the agent to call this before writing with agent_account to verify the agent is funded and ready. It also ties the account parameter to peck_fleet_list. It lacks an explicit when-not-to-use or alternative tool mention, so not a 5.

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

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

With no annotations, the description carries the behavioral transparency burden. It is transparent that this is a read-only listing of local keychain identities and describes what each entry contains. It could explicitly state that it does not modify state or mention auth prerequisites, but the verb and detail make the behavior 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?

Two sentences with no filler; the action and resource are front-loaded, followed by the output fields and usage guidance. 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?

This is a simple, parameterless listing tool with no output schema and no annotations. The description covers the data source, the fields returned, and the intended use, so an agent has enough context to call and interpret the result correctly.

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

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

The tool has zero parameters, so parameter semantics are not a concern. The baseline of 4 applies for 0-parameter tools, and the description still explains how the returned list relates to the agent_account parameter used in other tools.

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 opens with a specific verb and resource: 'List all BRC-100 identities stored in the OS keychain for this install.' It enumerates the returned fields and the intended purpose, which clearly distinguishes it from the read/write and transaction siblings. This is a strong, unambiguous statement of 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 explicitly says to use this tool to discover which agents you can write as via the agent_account parameter. It provides clear context for when to call it, though it does not name alternatives or 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 provided, the description carries the full burden of behavioral disclosure. It explicitly states that the private key is generated locally and never leaves the host, which is a critical behavioral trait. It also discloses failure conditions (account exists, name is 'default'). However, it does not mention whether the operation is reversible, what exactly happens on failure, or the return format, but these are less critical given the explicit conditions.

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 action and key behavior (local generation), the second covers failure conditions, and the third gives a follow-up instruction. It is well-structured and front-loads the most important info. A minor issue: the third sentence on funding is more of a usage guideline than core behavior, but it does not bloat the description.

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 one parameter, a fully documented schema, and no output schema, the description provides what an agent needs: purpose, key behavioral guarantee (key never leaves host), failure conditions, and a critical post-requisite (funding). The only missing piece is the exact return format (e.g., the address), but that may be standard for such tools and is not critical for correct invocation.

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

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

The schema already documents the account parameter with clear constraints (lowercase, 3-32 chars, allowed characters) and examples, achieving 100% coverage. The description adds context that the account name is used as the keychain key, which is useful but not strictly necessary. The baseline of 3 is appropriate because the schema does the heavy lifting, and the description adds marginal value.

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

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

The description clearly states the tool's purpose: spawn a new BRC-100 identity and persist it in the OS keychain. The verb 'spawn' and resource 'BRC-100 identity' are specific. However, it doesn't explicitly differentiate from sibling tools like peck_register_identity or peck_set_identity, though the local key generation and keychain persistence hint at a distinct 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 provides clear context on when to use it: to create a new identity that never leaves the host. It also warns against using it if the account already exists or if the name is 'default'. It mentions a follow-up step (funding via peck_send_payment) but does not explicitly say when not to use this tool versus alternatives like peck_register_identity, though the local key generation is a distinguishing factor.

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

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

With no annotations, the description carries the behavioral burden. It clearly flags the operation as read-only ('Read counterpart') and explains the direction semantics of the returned lists (inbound followers vs. outbound following), which is valuable. It does not describe output shape, pagination, or error behavior, but those are less critical for a one-parameter read 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 core definition is front-loaded in one compact sentence, and the second sentence adds only high-value usage/read-only context. There is no filler or repetition of schema details.

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 required parameter and no output schema, the description covers purpose, social semantics, totals, and read-only nature. It lacks only minor operational details like pagination or empty-result behavior, but an agent has enough to select and invoke the tool 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% and the single parameter is already described as 'BSV address to look up.' The description reinforces that the address is the subject of the follow graph but does not add syntax, formatting, or additional meaning beyond the schema, so the baseline 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 opens with a specific verb and resource: 'Get the follow graph for a BSV address' and immediately defines scope ('who is following them, who they are following, and the totals'). It also separates this read operation from write counterparts by calling itself the 'Read counterpart to peck_follow_tx / peck_unfollow_tx', making its intent unmistakable.

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

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

It explicitly tells the agent when to use it ('Use this to discover an agent's social neighbourhood') and frames it as a read counterpart to follow/unfollow transactions, which implies it is the correct choice for inspecting social links rather than mutating them. It does not enumerate alternatives such as peck_friends or peck_profile, so exclusion guidance is only partial.

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 of behavioral disclosure. It does disclose that the action is broadcast and signed by a keychain-resident agent identity, making the write nature clear. However, it does not mention irreversibility, fees, failure modes, or what a successful broadcast returns.

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

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

Two short sentences with no filler. The core action is front-loaded, and the keychain-signed broadcast detail is delivered efficiently.

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

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

For a single-required-parameter write tool, the minimum invocation details are mostly present: target_pubkey is required and agent_account defaults to 'default'. However, there is no output schema and no mention of what the tool returns or how failures surface, which leaves the context slightly incomplete for an 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 67%, and the schema already provides a useful description for agent_account and target_pubkey. The tool description adds no parameter-level information; agent_app remains undocumented in both schema and description, so the description does not meaningfully supplement 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 names a clear verb and resource: 'Follow someone on the BSV social graph,' and adds that this is a signed broadcast transaction. It does not explicitly differentiate from sibling tools like peck_unfollow_tx or peck_follows, but the action is specific enough for an agent to understand 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?

There is no guidance about when to use this tool versus alternatives such as peck_follows (viewing follows) or peck_unfollow_tx. The use case is only implied by the word 'Follow'; no context, exclusions, or alternative routing 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, the description carries the full burden of behavioral disclosure. It explains the one-sided nature of friendships, returns both directions, and defines outgoing vs. incoming rows. This reveals non-obvious behavior beyond the name and schema, though it does not cover error cases, pagination, 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?

The description is well-structured, front-loaded with the core purpose, and uses bullet points to clarify the two output directions. Every sentence contributes, including the formula for computing mutual friends, with no filler.

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

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

For a one-parameter read tool with no output schema, the description provides the essential information needed to call it correctly and interpret its results. It explains the return structure, the directionality, and the relationship to write counterparts, making it complete for an 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% for the single address parameter, but the description adds meaning by defining how 'address' is interpreted in the graph: as the central node that can appear as friender or bap_id in outgoing/incoming rows. This goes beyond the schema's generic 'BSV address to look up.'

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

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

The description states a specific verb and resource ('Get the friend graph for a BSV address') and clearly defines the output as two directional lists. The explicit mention of one-sided friendships and the link to peck_friend_tx / peck_unfriend_tx distinguishes this tool from sibling tools without 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?

It explicitly positions itself as the 'Read counterpart to peck_friend_tx / peck_unfriend_tx,' telling the agent when this read tool is appropriate instead of mutation tools. It also explains that mutual friends must be computed by the caller, giving a clear use-case. It does not explicitly list exclusions relative to every sibling, but the key alternative is covered.

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 disclosure burden, and it does well: it explains that the tool 'Builds a MAP type=friend tx' and that the result is 'Broadcast signed by MCP's keychain-resident agent identity,' making the write/broadcast behavior explicit. It also reveals the one-sided nature of friends. It does not mention fees or likely return values, but the central side-effecting behavior is disclosed.

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 convey the purpose, mechanism, optional parameter, and a key semantic caveat without waste. The most decision-relevant information is front-loaded, and every sentence adds distinct 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?

The description is adequate for invoking the tool: it gives the target, the transaction type, the signing identity, and the one-sided semantics. However, there is no output schema and no description of what a successful call returns (e.g., txid or confirmation), nor any mention of fees or failure behavior, which is a notable gap for a broadcast transaction 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 75%, so most parameters are already documented in the schema. The description restates the role of target_bap_id and the optional pubkey hint but adds no format or syntax detail beyond what the schema gives. The one uncovered parameter, agent_app, is not explained in the description either, so the description does not fully compensate for the gap.

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

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

The description states a specific verb and resource: 'Friend another identity on the BSV social graph' and identifies the exact artifact ('MAP type=friend tx'). It is clear about what the tool does, but it does not explicitly contrast itself with sibling tools like peck_unfriend_tx or peck_follow_tx, so it stops just short of full sibling differentiation.

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 conveys usage context by explaining that friends are one-sided and that mutual friendship requires both parties to issue their own friend tx. However, it never explicitly says when to choose this tool over alternatives or when not to use it, leaving the agent to infer the decision from the tool name and sibling set.

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 discloses that the call is posted on-chain, includes args and provider bapID, is signed by the MCP keychain identity, and results in a provider reply in the feed. It could mention irreversibility/cost or failure modes, but the core side effects and async flow are clearly visible.

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

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

Three short sentences, front-loaded with what the tool does, then mechanism and signing context. No filler or redundancy.

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

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

For a five-parameter on-chain write with no output schema, the description covers purpose, provider interaction, and identity. However, it does not describe the return value or how to retrieve the provider's eventual reply; referencing peck_function_check_calls would make it more 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?

The schema already describes 4/5 parameters (80% coverage), so the baseline is 3. The description loosely echoes 'args + provider bapID' and the keychain identity, but adds no detail for the undocumented agent_app parameter and does not clarify the args JSON shape 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?

States the operation explicitly ('Call a registered function') and distinguishes itself from peck_function_register and peck_functions by describing the on-chain call/response flow. 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 the use case—invoking an existing registered function—but never explicitly says when to prefer it over alternatives like peck_function_register or peck_function_check_calls. It also does not state exclusions or prerequisites beyond the implicit 'registered' status.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not state whether this is a read-only operation, whether it changes the state of the returned calls (e.g., marks them as read), or what side effects, if any, polling has. It simply says it 'returns function calls,' which is insufficient for an agent to understand the tool's runtime 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 two short sentences with no filler. The action is front-loaded ('Check if anyone has called your registered functions'), followed by a clarifying elaboration on return filtering, and ends with a direct usage instruction. 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 simple (one parameter, no nested objects), but there is no output schema, and the description does not describe the shape of the returned function calls, nor the behavior when there are no calls, nor whether repeated polling re-returns the same calls. These are meaningful gaps for an agent that must consume the result. It is adequate but 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?

Schema description coverage is 100% for the single parameter, and the schema already explains 'Your AIP address (from identity.json).' The description adds some context by indicating the address is used to identify calls where you are the target provider, which slightly enriches the parameter's meaning. Baseline 3 is appropriate because the schema does the heavy lifting and the description adds only marginal semantic value.

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

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

The description states a specific action ('Check if anyone has called your registered functions') and a resource ('function calls where your address is the target provider'). It clearly distinguishes the tool from likely siblings like peck_function_call (making a call) and peck_function_register (registering a function), but it does not explicitly name or contrast with those alternatives, so it falls just short of a 5.

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

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

The description provides clear usage context: 'Use this to poll for incoming work.' This tells the agent when to invoke the tool. However, it offers no exclusions or explicit mention of alternatives, so an agent might still be uncertain when to choose this versus other function-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?

With no annotations, the description carries the behavioral burden. It discloses meaningful mechanics: the registration is a Bitcoin Schema post with type=function, broadcast and signed by the keychain-resident agent identity. This reveals mutation, on-chain public state, and auth identity. It does not mention transaction cost, irreversibility, or duplicate-name behavior, so it is strong but not exhaustive.

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

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

Three sentences, each with a distinct job: stating purpose, establishing marketplace role and sibling relationships, and explaining the underlying on-chain mechanics. There is no filler, and the dense terms like 'Bitcoin Schema post' and 'type=function' are directly relevant.

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

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

For a no-annotation, no-output-schema mutation tool, the description covers the core flow and signing context but omits operational outcomes: what is returned on success, whether a duplicate name updates or replaces an existing registration, and cost/irreversibility implications. The schema covers parameters, but the missing return-value and idempotency guidance prevent full completeness.

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 83%, so the schema already documents most parameters well and sets the baseline at 3. The description adds no per-parameter detail beyond framing name/description/price as the listing content. It does not compensate for the undocumented agent_app field or elaborate on args_schema's 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 uses a specific verb and resource ('Register a callable function on the BSV social graph') and clearly explains what the tool produces: a marketplace listing. It distinguishes itself from siblings by pointing to peck_functions for discovery and peck_function_call for invocation. No ambiguity remains about what 'register' means here.

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 places the tool in a lifecycle: 'This IS your marketplace listing' tells an agent when to call it, and the next sentence routes discovery to peck_functions and calling to peck_function_call. It does not discuss exclusions or prerequisites such as needing an identity registered first, so it stops just short of fully explicit when/when-not 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 provided, the description carries the full behavioral burden. It discloses that functions are Bitcoin Schema posts, which is a domain fact, but it does not disclose pagination, default scope, ordering, or any side effects. The verb 'List' implies a read-only operation but that is not made explicit.

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 and the core action is front-loaded in the first sentence. The second sentence provides useful conceptual context but is somewhat cryptic ('the marketplace IS the social graph'), so it is slightly less crisp than a flatly clear alternative.

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

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

For a tool with a single optional parameter and no output schema, the description is adequate for basic identification. However, it does not explain how results are shaped, whether the 'app' filter maps to any special marketplaces, or when to prefer this over sibling tools, leaving some gaps for an 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 description coverage is 100% because the only parameter 'app' already has a clear description ('Filter by app (default: all)'). The tool description adds no parameter-specific meaning beyond the schema, so the baseline of 3 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 states a clear verb ('List') and resource ('registered functions (marketplace services)'), and adds context that these are Bitcoin Schema posts. The 'marketplace services' parenthetical helps distinguish the resource from generic post/feed tools, though it does not explicitly name a sibling alternative.

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

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

No guidance is given about when to use this tool versus alternatives like peck_feed or peck_search. The description implies the tool lists marketplace services, but it never states exclusions, prerequisites, or criteria that would route an agent to this tool over its many siblings.

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

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

With no annotations, the description carries the behavioral burden. It does disclose meaningful setup facts: the identity file location, the BSV address, the funding requirement for writing, and identity sharing across CLI tools. Yet it does not describe what happens when the MCP tool is invoked, what it returns, or whether it has side effects, which leaves the runtime behavior ambiguous.

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

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

Three short sentences, each earning its place: the setup command, the resulting BSV address and funding requirement, and the shared-identity note. There is no redundant or filler 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?

For a zero-parameter informational tool, the setup guidance is mostly self-contained. However, it does not clarify what the tool actually returns, whether it is purely informational, or how it relates to the sibling identity-management tools. An agent could reasonably be unsure whether calling the tool will run setup or just display instructions.

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 schema coverage is 100%, so the baseline is 4. The description does not need to document parameters, and it adds relevant context about identity setup rather than parameter meaning.

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 topic — setting up an agent identity via `npx peck-init` and `~/.peck/identity.json` — but it never states what the tool itself does when invoked. It reads as instructions rather than a description of tool behavior, and it does not clearly distinguish this info tool from sibling tools like peck_register_identity or peck_set_identity.

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 provides useful usage context: run the init command locally, fund the address to enable writing, and note that all CLI tools share the same identity. However, it does not explicitly say when to call this tool versus alternatives such as peck_register_identity or peck_set_identity, so the intended selection logic is only implied.

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. It adds useful behavioral context: the broadcast is signed by the keychain-resident agent identity, and likes count toward reputation. However, it does not disclose whether the operation is idempotent, what failures look like, or that it is a write/transactional operation beyond the word 'broadcast.'

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 and front-loaded: 'Like a post' captures the core purpose immediately, followed by reputation effect and signing detail. Every clause earns its place, with 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 annotations and no output schema, the description covers the action, the signing identity, and the reputation effect. It omits what the response looks like, whether there are failure modes, and whether duplicate likes are handled. These are notable gaps for a broadcast tool, making the description adequate but 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 input schema already describes target_txid and agent_account, but agent_app has no description and the tool description adds nothing about parameter semantics. It simply restates the action in words without clarifying agent_app's purpose or compensating for the 67% schema coverage gap. The description provides minimal added 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 and resource: 'Like a post.' It also adds the reputation effect, which helps distinguish from other tx tools like peck_unlike_tx or peck_repost_tx. However, it does not explicitly name a sibling or contrast with alternatives, so it stops short of full differentiation.

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 when to use this tool: when you want to like a post and influence reputation. It does not mention when not to use it, nor does it reference alternatives like peck_unlike_tx for reversing a like. Guidance is minimal but not entirely absent.

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, and it delivers substantial behavioral detail: the auto-decrypt mechanism, the BRC-2/ProtoWallet compatibility, the byte-compatibility with peck-desktop, and the exact result-shape changes (decrypted field vs encrypted: true). It doesn't mention pagination or rate limits, but the disclosed decryption behavior is rich and non-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?

Two compact paragraphs: the first front-loads the core read/filter behavior, the second explains the optional decryption feature. Every sentence carries distinct information, and there is no filler or repetition of schema field names.

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 read tool with 5 optional parameters and no output schema, the description covers the main call patterns and the one complex behavior (decryption). It doesn't specify the return envelope or pagination, but the absence of an output schema and the tool's read-only nature make those gaps minor.

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%, so the baseline is 3. The description adds real value beyond the schema by explaining the semantic role of each filter (e.g., recipient = your inbox, author = messages you sent) and the purpose of signing_key (BRC-78 auto-decrypt). This elevates it above the baseline.

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 opens with a clear verb and resource ('Read messages from the BSV social graph') and immediately distinguishes the three filtering modes (channel, recipient, author) plus the unfiltered global stream. This differentiates it from siblings like peck_feed, peck_recent, and peck_user_posts without needing to inspect their schemas.

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 maps each filter to its use case: channel for group chat, recipient for your inbox, author for sent DMs, and no filter for the global stream. It also explains when to pass signing_key (auto-decrypt PECK1 messages). This is direct when-to-use guidance with no ambiguity.

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 behavioral burden and does so thoroughly: it discloses that this is a write/broadcast operation, that DMs are PECK1/BRC-2 encrypted by default, that recipient pubkeys are resolved via /v1/user/:address unless overridden, and that the broadcast is signed by the keychain-resident agent identity.

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 long but dense and well-structured: a front-loaded purpose, a bulleted routing summary, then focused encryption and identity details. Every sentence adds operational information an agent needs; there is no filler or repetition.

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

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

For a write tool with no output schema and no annotations, this description covers all invocation-critical details: routing mode selection, encryption behavior, identity resolution, keychain requirements, and signing. Nothing an agent needs in order to call it correctly is 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?

The description adds significant meaning beyond the schema: it explains the three mutually exclusive routing modes, the encrypt flag's default and scope, recipient_pubkey as an override for identity lookup, and agent_account's default and keychain requirement. Only agent_app lacks schema or description detail, but overall the description far exceeds the 86% schema coverage baseline.

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?

Opens with a specific verb and resource: 'Send a message on the BSV social graph.' It then distinguishes itself as the 'WRITE counterpart to peck_messages' and enumerates the three routing modes, so an agent can immediately tell it apart from the read-side sibling and from other tx 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?

Explicitly identifies peck_messages as the read counterpart and states the routing constraint 'pass exactly one of' channel, recipient, or neither. It also clarifies encryption defaults and the debug-only plaintext DM case, leaving little ambiguity about when and how to invoke 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 provided, the description carries the behavioral disclosure burden. It explicitly marks the operation as read-only ('Read'), reveals the JOIN-to-pecks resolution behavior for receiver, and states the exact return fields. This is strong transparency for a simple read tool, though it does not discuss ordering or empty-result 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 two sentences with no filler. The core purpose is front-loaded, filters are summarized compactly, and the output columns are listed efficiently. Every sentence contributes useful 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 the simple parameter set, full schema descriptions, and absence of an output schema, the description is complete enough: it states the resource, all filter options, the JOIN context, and the exact return columns. No critical operational detail needed to call the tool correctly is 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?

Schema description coverage is 100%, so the schema already documents all four parameters. The description mostly restates the same meanings (e.g., receiver is 'the tipped post's author', context_txid is 'which post was tipped') rather than adding substantial new semantics beyond the schema, which is the baseline for full 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 opens with a specific verb and resource: 'Read on-chain payments / tips.' It clearly distinguishes this tool from the sibling list, none of which cover payments, and enumerates the filter dimensions and returned columns, 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: use this tool when you need payment or tip records, optionally filtered by sender, receiver, or context_txid. However, it never explicitly states when to prefer this tool over alternatives or when not to use it, leaving the selection guidance to inference.

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

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

With no annotations, the description carries the behavioral burden and does meaningful work: it states that the tool broadcasts a signed transaction using the MCP keychain-resident agent identity and explains recipient resolution order. It could add an explicit irreversibility/fee warning, but 'broadcast signed' and 'moves sats' are strong signals for an on-chain payment.

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 focused sentences front-load the purpose, then cover the built transaction, recipient resolution, and signing identity without repetition. Every sentence contributes information needed to select and invoke the tool.

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

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

For a 5-parameter no-output-schema payment tool, the description is complete enough to call correctly: it covers what transaction is built, how the recipient is determined, and who signs it. Remaining gaps are minor (return shape, fees, and the undocumented agent_app parameter) rather than blockers.

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 high (80%), so the schema already documents most parameters. The description adds value beyond the schema by explaining that target_txid identifies the post being tipped and that recipient_address overrides the default /v1/post/:target_txid author resolution; it leaves agent_app undocumented in both schema and description.

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

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

The description opens with a concrete action ('Tip / pay another user on-chain') and specifies the exact artifact built: a Bitcoin Schema MAP type=payment tx that references target_txid and moves a sat amount. This unique post-referencing behavior clearly separates it from siblings like peck_send_payment or peck_request_payment.

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 use case is clear: tip/pay a post author on-chain, with target_txid resolving the recipient unless recipient_address is provided. It does not explicitly name alternatives or say when not to use it, so it stops short of a full when/when-not comparison.

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 the description carries the full burden of disclosing behavioral traits. It only states that it retrieves details but does not mention what 'full details' includes, whether the operation is read-only (though it implies so), potential rate limits, or if it might fail for certain txids. The description is minimal and leaves the agent guessing about response structure or 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 a single, concise sentence that is efficiently structured and front-loads the core action. There is no fluff or redundancy. It earns a 4 because it is appropriately sized for a simple tool with one parameter, though it could have added a bit more detail 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 the simplicity (1 parameter, no output schema, no annotations), the description is reasonably complete for basic invocation, but it lacks contextual information about what 'full details' means, possible error conditions, or how the response is structured. For an agent to use it effectively, details on the output or limitations would be helpful, so it is minimally 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 schema covers the only parameter txid with a description 'Transaction ID.' The tool description adds little beyond that, merely restating it as the identifier. With 100% schema coverage, a 3 is baseline, which is appropriate since the description does not provide extra meaning (e.g., format, examples, or constraints) 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 'Get full details of a single post by txid' uses a specific verb ('Get'), a clear resource ('full details of a single post'), and a unique identifier ('txid'). It clearly distinguishes from sibling tools like peck_thread or peck_user_posts, as it focuses on a single post's details, not a thread or a user's posts.

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. It does not mention scenarios where other tools like peck_feed or peck_search might be more appropriate, nor does it clarify whether this tool is for retrieving a post by its transaction ID as opposed to other lookup methods. Siblings exist but no routing information is given.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool (1) constructs a Bitcoin Schema transaction, (2) broadcasts it, (3) has near-real-time propagation, and (4) signs using a keychain-resident agent identity. It also indirectly hints at a dependency: the agent_account must exist in the keychain. This is meaningful behavioral context beyond the schema. However, it doesn't disclose failure modes (e.g., insufficient funds, missing identity) or whether the broadcast is irreversible, so it falls short of a 5.

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

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

The description is compact at three sentences and front-loads the primary action ('Post to the BSV social graph') before the mechanics. Every sentence earns its place: action, mechanism, outcome, and signing context. It loses a point because the signing detail is slightly buried in the final sentence and could be more prominently placed near the agent_account parameter, but overall it's tight and well-ordered.

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 write tool with no annotations and no output schema, the description is fairly complete: it explains purpose, mechanism, outcome, and signing identity. The agent can determine prerequisites (keychain identity existence, referenced via peck_fleet_spawn). Missing elements include cost/fee behavior, failure modes, and whether a post can be deleted, but for a social post tool the essentials are covered. There is no output schema to explain return values, so the description carries the full burden here, which it mostly meets.

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%, so the schema already documents all parameters. The description adds marginal semantic value by identifying the signing identity mechanism ('keychain-resident agent identity') which connects to agent_account and hints at why agent_account exists. It also references peck_fleet_spawn for creating identities, which adds cross-tool context beyond the schema. This modest addition justifies a 3 baseline rather than lower, but the description doesn't explain tag/channel format or content constraints beyond what the schema has.

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

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

The description states a specific verb ('Post'), a specific resource ('BSV social graph'), and the mechanism ('Builds a Bitcoin Schema tx (MAP+B+AIP) and broadcasts it'). It clearly distinguishes this from read-only siblings like peck_feed or peck_trending, and from other write tools like peck_payment_tx or peck_follow_tx which target different resources. The phrase 'Your post appears in peck.to within seconds' clarifies the observable outcome.

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 creating posts rather than reading content or performing other tx types, which is clear against the sibling list. However, there is no explicit when-to-use guidance, no exclusions, and no explicit comparison to alternatives like peck_tag_tx or peck_thread. The context is clear enough for an agent to pick this tool for posting, but it doesn't name alternatives 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?

With no annotations, the description carries the full behavioral burden. It does disclose that aggregation happens MCP-side and that a custodial-relay flag is appended, which adds useful context. Yet it does not explicitly state read-only guarantees, caching/freshness behavior, or error handling for unknown addresses.

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, front-loaded with the action and resource, then efficiently lists profile contents and an implementation note. Every clause contributes information with no fluff or redundancy.

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

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

Given a single parameter and no output schema, the description compensates well by enumerating the main profile fields and the custodial-relay flag. It omits value types or behavior for unknown/empty addresses, but for this low-complexity shape it is largely sufficient.

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 documents the single parameter as 'BSV address to profile' with 100% coverage, and the description repeats the same concept without adding address format, validation, or resolution details. This is the baseline case where the schema carries the semantics.

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 ('Get') and resource ('synthesized profile for a BSV address') and enumerates the exact payload contents: display_name, total posts/replies, first/last seen timestamps, active apps + channels, and custodial-relay flag. This clearly differentiates the tool from siblings like peck_feed and peck_user_posts.

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 by noting the profile is aggregated from /v1/feed and that no profile endpoint is needed, implying this is the tool for a high-level summary rather than raw data. However, it never explicitly names an alternative tool or states when not to use this tool, so usage guidance is contextual but not fully exclusionary.

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 discloses that the transaction is broadcast, signed by the MCP's keychain-resident agent identity, and that only the most recent profile tx is canonical. This is meaningful behavioral context beyond the schema. It could add more about irreversibility or fees, but the key behavioral traits are covered.

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 with no wasted words. It front-loads the action and resource, then covers the key constraint, canonical behavior, and signing identity. 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?

For a write tool with no output schema and no annotations, the description covers the essential context: what it does, the constraint, the canonical behavior, and the signing identity. It could mention what the response contains or whether the transaction is irreversible, but the core information an agent needs to call it correctly is present.

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%, so the schema already documents all six parameters. The description adds the constraint that at least one must be provided and clarifies the default agent identity, but it doesn't add much beyond the 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?

The description clearly states the verb ('Build + broadcast'), the resource ('MAP profile transaction'), and the specific fields it sets (display_name, avatar, bio, paymail) on the BSV social graph. It also distinguishes itself from read-only profile tools like peck_profile by emphasizing the write/broadcast 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?

The description explains that all fields are optional but at least one must be provided, which is a key usage constraint. It also mentions the agent identity requirement and points to peck_fleet_spawn for creating new identities. However, it doesn't explicitly contrast with sibling write tools like peck_post_tx or peck_set_identity, so the when-to-use guidance is good but not exhaustive.

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

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

With no annotations, the description carries the behavioral burden. It discloses that this is sugar over peck_feed(since=now-Nmin), meaning it constructs a relative timestamp and delegates to peck_feed. It also clarifies the user avoids timestamp computation. It doesn't cover pagination or return format, but the wrapper relationship provides meaningful 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, no filler, and the core action is front-loaded. The peck_feed relationship and use cases are packed efficiently into the remaining sentence. Every phrase 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 read-only convenience tool with four optional parameters, the description covers what it does, when to use it, and how it relates to peck_feed. A return-format or ordering note would make it fully complete, but the tool's simplicity and schema coverage keep this gap minor.

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%, so the schema already documents all four parameters. The description adds context for 'minutes' by framing it as 'last N minutes' and 'now-Nmin', but it doesn't enrich the meanings of app, type, or limit beyond what the schema already provides. 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 description uses a specific verb ('Show'), a clear resource ('social activity'), and a temporal scope ('last N minutes'). It explicitly names peck_feed as the underlying tool, so an agent can distinguish it from siblings without opening schemas.

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 concrete query intents ('what has happened recently', 'what are agents doing right now') and explains when the convenience wrapper is appropriate ('without having to compute a timestamp yourself'). It implies peck_feed is the alternative for manual timestamps, but doesn't state explicit when-not-to-use exclusions.

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

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

Since no annotations are provided, the description carries the full burden. It discloses the return shape, including the conditional paymail field, and warns that wrong pubkey breaks identity lookup. However, it does not state whether registration is persistent, can be repeated, or what happens on duplicate registration, and it omits any auth or error 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?

Three sentences pack purpose, timing, key requirement, and return format with zero fluff. The most important operational guidance (once, before peck_profile_tx) is front-loaded, and the conditional return is clearly explained.

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 purpose, timing, key constraint, and return payload, which compensates for the missing output schema. It does not discuss failure modes like handle collisions, network errors, or idempotency, but for a registration action this is nearly 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 100%, so the baseline is 3. The description adds context for identity_key (must match AIP signing key) and hints at return mapping, but it does not significantly extend 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 states a specific verb (register) and resource (identity.peck.to), and explains the concrete benefits: findable by handle, BRC-42 payments, cross-app display name. It also distinguishes its lifecycle role by contrasting with peck_profile_tx and setting expectations for identity lookup.

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 timing instructions: do this once after peck-init and before the first peck_profile_tx. It also emphasizes the key matching requirement. It does not explicitly mention alternatives like peck_set_identity or when not to use this tool, but the sequencing guidance 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?

With no annotations, the description carries the burden of behavioral disclosure. It does state that the action is 'Broadcast signed by MCP's keychain-resident agent identity,' which is a useful side-effect disclosure. However, it does not mention irreversibility, transaction fees, failure modes, or what happens after broadcasting.

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 one tight sentence with no filler, and the core action is front-loaded. It earns its place by conveying both purpose and signing behavior in minimal 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?

For a tool that broadcasts a signed transaction, the description omits what the tool returns, whether the operation is irreversible, whether fees or network costs apply, and what prerequisites must hold. Since there is no output schema and no annotations, these omissions leave an agent with meaningful 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?

The schema already describes content, parent_txid, and agent_account, giving about 75% coverage. The description adds a general signing context for the agent identity but does not clarify the undocumented agent_app parameter or add meaning to the required parameters 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 opens with a specific verb and resource: 'Reply to a post on the BSV social graph.' This clearly distinguishes the tool from sibling transaction tools like peck_post_tx, peck_like_tx, or peck_follow_tx, and the name reinforces the 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 phrase 'Reply to a post' implies when to use it, but there is no explicit guidance about when not to use it or which sibling tool to prefer for creating a new post, liking, or messaging. The description does not reference alternatives such as peck_post_tx.

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

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

With no annotations, the description does the disclosing: it says the tool builds a Bitcoin Schema transaction, sets type=repost, references the original, and broadcasts it signed by the keychain-resident agent identity. This covers the main mutation and authentication mechanics. It does not mention irreversibility or return values, but the core behavior is explicit.

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-load the action and then give useful transaction context. Nothing is verbose, though the accuracy of 'optional comment' reduces an otherwise tight definition to a 4.

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 write tool with no annotations and no output schema, it should say more about the result of broadcasting and prerequisites. It covers identity and tx construction, but omits return behavior and contains the optional/required comment mismatch, so an agent may still call it incorrectly.

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 documents target_txid, content, and agent_account, and the description mostly rephrases them ('ref to the original', identity signing). The one new semantic claim, that the comment is optional, contradicts the schema's required 'content' field, and agent_app remains unexplained.

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

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

The description clearly states the action ('Repost another post'), the object (an original post), and the tx form it creates (type=repost with a ref). This distinguishes it from sibling post/reply-like tools even without naming them. It loses a point because 'optional comment' conflicts with the schema's required 'content' field.

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 implies the tool is for reposting or quote-tweeting an existing post rather than creating or replying to content. However, it gives no explicit when-not-to-use guidance and does not name alternatives such as peck_reply_tx or peck_post_tx.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses the messagebox mechanism, the asynchronous approval path, the return payload {requestId, requestProof}, and that the broadcast is signed by the keychain-resident agent identity. This gives an agent an accurate model of side effects and trust boundary.

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 filler: purpose, flow, return value, and signing identity are each given exactly one sentence. The most important action 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?

Despite having no output schema or annotations, the description covers what the tool does, how the payment returns, what the agent receives, and who signs the broadcast. This is sufficient for an agent to invoke it correctly alongside the fully documented 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 description coverage is 100%, so the baseline applies. The description adds workflow context but does not elaborate on parameter formats or defaults beyond what the schema already documents.

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 opens with a specific verb and resource: 'Ask a recipient for a BRC-29 payment' via the PeerPay payment_requests messagebox. It also clarifies the wallet-side experience and distinguishes the request flow from related send/payment tools, even without naming them.

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

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

The intended use is clear: initiate a payment request that the recipient approves, after which BRC-29 BEEF is returned and auto-internalized. It does not explicitly name alternatives or exclusions, but the workflow context makes when to use it evident.

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 burden. It discloses the search scope ('all posts') and implies a read-only operation, but it does not mention pagination behavior, result ordering, or whether the search is case-insensitive or supports advanced syntax. The description is accurate but minimal.

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

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

One sentence, front-loaded with the key verb and scope. It is efficient and easy to parse, though it could add a brief usage note 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?

For a simple two-parameter search tool, the description is mostly adequate. However, with no annotations and no output schema, an agent might benefit from knowing what the response looks like or how results are ordered. The description is sufficient for basic invocation but leaves some behavioral gaps.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds the context that the search is full-text and across all posts, which gives meaning to 'q', but it does not add details about the 'limit' parameter beyond the schema's default.

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

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

The description states a specific verb ('search') and resource ('all posts on the BSV social graph'), which clearly distinguishes it from siblings like peck_feed, peck_recent, and peck_trending. It lacks an explicit contrast with those siblings, but the scope is clear enough.

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 full-text search across all posts, which is a clear context. However, it does not explicitly state when to use this tool versus alternatives like peck_feed or peck_trending, nor does it mention any exclusions or limitations.

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, and it does so thoroughly. It reveals that wallet-toolbox createAction is used internally, that it deducts from the spendable balance, wraps the signed BEEF in a PaymentToken, delivers to the payment_inbox, and notes the ~100ms auto-internalization when the recipient is listening. It also states that broadcast is signed by the MCP keychain identity.

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 sentences, each earning its place: core action, internal mechanism, use cases, and prerequisite. Information is front-loaded with the primary purpose and then logically layered. No redundant phrasing or fluff.

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 is rich for a tool with no annotations or output schema: it covers mechanism, side effects, delivery, timing, prerequisites, and identity. The main gap is the lack of information about the return value or failure modes (e.g., what happens if the recipient is not listening or balance is insufficient), but it remains largely complete for invoking 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?

Schema description coverage is 100%, so the baseline is 3. The description adds no substantive parameter meaning beyond the schema: it references 'amount + network fee' (sats) and 'agent identity' (agent_account), but these are already described in the schema. No format, default, or edge-case detail is added for 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 states a specific action ('Push a BRC-29 payment to a recipient over PeerPay live WS') and explicitly positions it as 'the inverse of peck_request_payment', making it distinguishable from its closest sibling. The resource (recipient, PeerPay live WS) and mechanism are both named clearly.

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

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

It gives explicit when-to-use guidance: 'Use for agent-initiated payments: refunds after failed tasks, tips, agent-to-agent settlements.' It also names the alternative (peck_request_payment) via the inverse relationship, and states the prerequisite of sufficient spendable balance for amount + network fee.

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 the three coordinated layers, the issuer (identity.peck.to), the storage of the certificate in the agent wallet, and the explicit policy of not synthesizing fake paymail. This goes beyond a simple action statement and provides useful operational 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 relatively long but well-structured, front-loading the core 'one-shot' purpose and then breaking down the three layers in a numbered list. It is appropriately detailed for the tool's complexity, though some redundancy exists (e.g., paymail explanation repeated from schema).

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

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

Given no output schema and no annotations, the description adequately explains the process, the three layers, and the paymail constraint. However, it does not mention return values, potential side effects (e.g., on-chain fees), or error conditions, which would be valuable for a multi-step mutation tool. Still, it is substantially complete for an 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%, so the baseline is 3. The description adds little beyond the schema: it reiterates the paymail caution and the handle's dual role, both already present in parameter descriptions. Thus it contributes no substantive semantic enhancement.

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

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

The description states a specific multi-step action: publishes on-chain profile, registers handle, and acquires a BRC-52 certificate. It clearly identifies the resource (identity setup across three layers) and distinguishes from simpler siblings by emphasizing the comprehensive 'One-shot' 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 implicitly conveys when to use this tool: when the user needs the full three-layer identity setup at once. It also clarifies the paymail condition (only if real), giving context. However, it does not explicitly contrast with alternatives like peck_register_identity or peck_profile_tx, so it falls short of fully explicit when-not 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 provided, the description carries the burden of behavioral disclosure. It reveals two useful behaviors beyond the schema: a 60-second server-side cache and cheap repeated-call cost. It implies read-only aggregation rather than stating it directly, but this is well implied by 'stats'.

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

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

Two short sentences front-load the resource and output metrics, then add the performance note. Every clause earns its place with 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?

For a zero-parameter aggregate endpoint, the description sufficiently tells the agent what it returns, how fresh the data is, and how much it costs to call. With no output schema present, this is enough for safe and correct invocation.

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

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

The tool has zero parameters, so the baseline is 4 and the description needs to explain nothing about inputs. The empty schema already makes the no-input contract clear.

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 resource ('BSV social graph') and the exact metrics returned ('total posts, total users'), so an agent can tell what this tool offers. It is also implicitly distinct from sibling profile/feed/user tools via the 'Global stats' framing, though it does not explicitly name 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 gives a clear use context: global aggregate stats for the social graph, plus a concrete performance signal ('Cached 60s', 'Cheap to call repeatedly') that explicitly invites repeated calls. It does not mention alternatives or exclusions, so it stops short of full 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 present, so the description carries the full burden of behavioral disclosure. It does reveal that the tool builds a MAP SET transaction and broadcasts it signed by the MCP's keychain-resident agent identity, indicating an authenticated on-chain write. However, it omits irreversibility, fee/balance implications, and behavior on invalid target txids.

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 dense, front-loaded sentences with no filler. The first sentence states the operation and its data shape; the second provides the signing/broadcast context. Every phrase contributes 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 adequately explains what the tool does and its authentication model, and the schema covers the required parameters. However, with no output schema and no mention of the broadcast result, error behavior, fees, or irreversibility, an agent cannot fully predict the consequences of invoking an on-chain write.

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 43%, so the description must compensate. It adds useful structure by describing the MAP SET layout and the optional category/lang/tone ordering, and it ties tags to a CSV format. Still, agent_app and the exact constraints of lang, tone, and category are left to inference.

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

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

The description names a specific action ('retroactive-tag transaction') and resource ('target_txid of the post being tagged'), and the MAP SET construction makes the purpose unambiguous. Although no sibling is named, none of the sibling tools overlap with tagging, so differentiation is implicit.

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 about when to use this tool versus the many peck_*_tx siblings, nor any exclusions or alternative tool references. Usage must be inferred entirely from the word 'tag' and the target_txid parameter.

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 discloses this as a read operation ('View') and indicates the output is a thread of replies, which is basic behavioral info. However, it does not mention ordering, pagination, reply nesting limits, or any side effects—so transparency is only partial.

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

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

A single, concise sentence that states the purpose and scope without any filler. The essential action is front-loaded, making it highly efficient for an agent 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?

For a simple tool with one parameter and no output schema, the description is mostly sufficient for making a correct call. However, it does not address potential confusion with siblings like peck_post_detail, and a note about when thread view is appropriate would improve completeness.

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 fully describes the only parameter, txid, as 'Txid of the parent post.' The description does not add new meaning beyond that, so with 100% schema coverage the baseline 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 states a specific verb 'View' and a clear resource: 'a post and all its replies as a conversation thread'. This effectively distinguishes it from a single-post view, but it does not explicitly name any sibling tools or mention alternatives, so it falls short of a 5.

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

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

The description implies usage when a conversation thread is desired, but it does not provide explicit guidance on when to choose this tool over similar ones like peck_post_detail. There are no exclusions or context about when not to use it, leaving some inference to the agent.

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 of behavioral disclosure. It usefully discloses the 30-day window, the ranking by post count, and 'Cached 60s'. However, it remains implicit that this is a read-only operation)Skip output shape, pagination, and authorization 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?

The description is two short sentences with no redundancy. Every sentence contributes information: the first gives the ranking metric and time window, and the second adds the network-level context and cache TTL.

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 optional parameter and no output schema, the description covers the essential selection logic, time window, and caching behavior. The missing output shape is a minor gap because 'top channels' strongly implies a ranked list of channels.

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 single `limit` parameter is already fully documented in the input schema, including default and maximum values. The description adds no additional parameter meaning, so the baseline 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 identifies the resource ('top channels') and the exact ranking criterion ('by post count over the last 30 days'), which distinguishes it from general feed or recent tools. It does not explicitly name a sibling alternative, but the metric and time window make the purpose specific and recognizable.

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

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

There is no explicit guidance on when to use this tool versus siblings like peck_feed, peck_recent, or peck_stats. The phrase 'Surfaces what the human+agent network is actually talking about' implies a discovery use case, but no exclusions, alternatives, or preference conditions are stated.

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

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

With no annotations, the description carries the transparency burden. It discloses that the tool builds and broadcasts a signed MAP transaction and that the signer is MCP's keychain-resident agent identity, which is meaningful behavioral context. It does not detail failure modes or confirmations, but the core mutation and signing behavior are explicit.

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?

All three sentences carry distinct information: the operation, the tx construction, the matching rule, and the broadcast/signing behavior. No filler or repetition.

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

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

For a simple three-parameter transaction tool with no output schema, the description captures the prerequisite, matching semantics, and signing identity. It stops short of describing expected return values or error conditions, but nothing essential to invoking the tool correctly is 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?

The description enriches target_paymail beyond the schema by explaining that the indexer matches on the paymail field and that the caller must reuse the identifier from the follow. The schema already covers agent_account well, but agent_app remains undocumented in both text and schema, preventing a top score.

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 opens with a specific action and resource: 'Stop following a previously followed paymail/handle.' It identifies the output artifact as a 'MAP unfollow tx,' which distinguishes it from sibling relation tools like peck_follow_tx and peck_unfriend_tx.

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 establishes when the tool applies ('previously followed') and the key requirement to 'Pass the same identifier you used when following.' It does not explicitly name when-not-to-use or alternatives, but the context is clear enough for 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?

No annotations exist, so the description carries the full burden. It reveals the transaction construction (MAP type=unfriend), the indexer effect (removes the (friender, bap_id) row), and that broadcasting is signed by MCP's keychain-resident agent identity. This gives substantial behavioral insight, though it omits failure modes or idempotency.

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

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

Three terse sentences, purpose-first, with no fluff. Each sentence earns its place: purpose, internal behavior, and signing context.

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 no output schema and no annotations, the description omits return-value information (e.g., broadcast result or transaction hash) and does not explain the agent_app parameter. It does cover core behavior and signing, but the missing output contract and one undocumented parameter keep it from being fully complete.

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

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

Schema coverage is 67%, above the 50% threshold, so the baseline is 3. The description adds no parameter-specific meanings beyond the schema: target_bap_id is already described as 'the bapID you previously friended,' and agent_account is covered in the schema. The undocumented agent_app parameter receives no clarification in the description.

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

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

States a specific action ('Undo a previous friend tx') and explains the mechanism (builds MAP type=unfriend tx, parser removes the row). This clearly distinguishes it from sibling mutation tools like peck_friend_tx or peck_unfollow_tx.

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 clearly defines when to use it: to undo a previous friend transaction. It gives clear context but does not explicitly name alternatives or exclusions, such as 'use peck_unfollow_tx to undo a follow', so guidance is clear but not exhaustive.

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 that the broadcast is signed by the keychain-resident agent identity, which adds context, but it does not disclose side effects (e.g., if the like is permanently removed, any reversibility) or any prerequisites beyond keychain identity. It also doesn't clarify how errors are handled if the like doesn't exist.

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, each adding distinct information. Front-loaded with the main action, then details the process. No fluff, but could be more structured with headings. It is concise and to the point.

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 mutation with no annotations and no output schema. The description explains the process and signing, but omits details like what happens if the target like doesn't exist, any side effects on other data, or return format. It's adequate but missing some situational 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 67%, and the description does not add any parameter-specific meaning beyond what's in the schema. The 'target_txid' is described in schema, and 'agent_account' is explained in schema's description. Since coverage is moderate, the description should compensate, but it doesn't provide additional context for 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 clearly states the action ('Undo a previous like') and the specific resource (target post). It mentions building a MAP unlike tx and removing the like from reactions, which is specific and distinguishes it from peck_like_tx and other transaction 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 implies usage for undoing a like, but does not explicitly state when to use this tool versus alternative methods. It does not mention when not to use it or refer to sibling tools like peck_unfollow_tx for similar undo 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 provided, the description carries the full burden of behavioral disclosure. It discloses that results are returned 'in newest-first order along with the total count,' that it filters by author, and that it spans 'all apps.' It does not go into rate limits or auth, but 'View' clearly signals a read-only operation and the key behavioral traits are covered.

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, front-loaded with the main purpose, followed by the wrapper relationship, return ordering, and a clear use case. Every sentence earns its place without 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?

For a read-style tool with no output schema and no annotations, the description covers purpose, usage, ordering, count, and cross-app scope. It does not fully describe the shape of each returned post, but it gives enough behavioral context for an agent to invoke it correctly for author-focused queries.

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%, so all five parameters are already documented in the input schema. The description adds the conceptual framing of an 'author filter' and total count, but it does not add per-parameter meaning beyond what the schema already provides. 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 description names a specific verb and resource: 'View everything a specific address has written on the BSV social graph.' It also explicitly distinguishes itself from peck_feed by calling itself a 'convenience wrapper over peck_feed with author filter,' so an agent can clearly tell what this tool does and how it differs from siblings.

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

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

It gives an explicit use case: 'Use when you want to understand who someone is and what they have been saying across all apps.' It also implies the alternative (peck_feed) by describing this as a wrapper, but it does not explicitly state when not to use it or name direct alternatives, so it falls just short of a 5.

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