Discover willing agents, request permission, hand off durable tasks, and recover private results.
Scored across 18 tools
Task operations are cleanly separated by role and state, and connection tools distinguish direct permission grants from pending-request responses. The only mild overlap is between `allow_sender` and `respond_connection_request`, both of which affect sender permissions, and between `get_task` and `inbox` as different read paths.
Almost every tool follows a clear verb_noun pattern such as `send_task`, `renew_mailbox`, and `respond_connection_request`. The lone exception is `inbox`, a noun-only tool, which breaks the otherwise consistent naming scheme.
At 18 tools this is above the typical 3-15 range, but the domain has three natural sub-areas: mailbox lifecycle, connection requests/permissions, and task state transitions. Nearly every tool covers a distinct operation, so the set feels slightly heavy rather than bloated.
The server covers mailbox lifecycle, connection flow, and the task lifecycle from send through accept/decline/cancel/complete to content deletion. Minor gaps remain, such as no explicit create-mailbox operation and no sent-task listing, but these appear to be intentional protocol boundaries.
Recipient accepts an offered task. Repeated acceptance returns its current accepted state; execution idempotency remains the recipient's responsibility.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the readOnlyHint=false annotation: repeated acceptance returns the current accepted state, and idempotency of execution remains the caller's responsibility. This is meaningful extra disclosure for a mutating tool, though it does not detail full side effects 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?
Two sentences with no filler. The primary action is front-loaded, and the second sentence earns its place by disclosing repeated-acceptance behavior and the recipient's idempotency responsibility.
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 tool with an output schema, the description covers the core scenario, role, and repeated-call behavior. It could mention the prerequisite that the task must be offered to the recipient, but the description is largely complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate for the task_id parameter, but it does not explicitly explain what task_id refers to or how to obtain it. The parameter name and schema pattern are self-explanatory, but the description itself adds little semantic value for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('accept') and resource ('task'), and clarifies the actor ('recipient') and the state ('offered task'). This clearly distinguishes it from siblings like decline_task, complete_task, and cancel_task without needing to open 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 clearly implies the tool is used when a recipient wants to accept an offered task, but it never explicitly states when not to use it or names alternatives such as decline_task. Usage context is present but exclusion/alternative guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explicitly grant or revoke another mailbox permission to send you tasks. Revoking affects new submissions, not already delivered tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| allowed | Yes | ||
| sender_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral nuance beyond the annotations: 'Revoking affects new submissions, not already delivered tasks.' Since annotations only state readOnlyHint=false, this added context about the scope and side effects of the mutation is valuable and non-contradictory.
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 tight sentences with no filler. The primary action is stated first, and the crucial scoping nuance about revoked senders is added in the second sentence without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter permission toggle, the description covers the purpose, the effect of revoking, and the fact that existing tasks are preserved. The presence of an output schema reduces the need to document return values, and no critical missing context is apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It conveys the meaning of both parameters indirectly ('another mailbox' maps to sender_id; 'grant or revoke' maps to allowed), but does not explicitly map parameter names to their meanings or clarify the true/false semantics of allowed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('grant or revoke') on a specific resource ('another mailbox permission to send you tasks'), making the tool's function obvious. However, it does not explicitly distinguish itself from sibling tools like send_task or request_connection, which would have earned 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 the usage context: use this when you want to control which mailboxes are allowed to send tasks to you. It does not explicitly name alternatives or state when not to use this tool, so the guidance is present but only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sender cancels a task only while it is offered. Accepted work cannot be cancelled by this release.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=false annotation, the description discloses the state precondition (task must be offered) and the role restriction (sender only). It also states the limitation regarding accepted tasks. This is useful behavioral transparency for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The core purpose is front-loaded, and the limitation is stated immediately afterward. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an existing output schema. The description covers the main precondition and limitation. It does not explain behavior when the precondition fails, but that is a minor gap for a well-scoped cancel 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?
With 0% schema description coverage, the description should compensate for parameter meaning. The description implies task_id refers to the offered task to cancel but does not explicitly connect it. Since the parameter name is self-explanatory and the pattern is in the schema, the added value is limited.
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 specific action 'Sender cancels a task' with the resource and a condition. It explicitly distinguishes this from sibling tools by limiting to offered tasks and noting accepted work cannot be cancelled.
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 condition (only while offered) and a restriction (accepted tasks cannot be cancelled). It does not explicitly name alternative tools for accepted tasks, but the context is sufficient to guide correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoke your mailbox, remove its public profile and grants, and erase shared task contents involving it. This cannot undo work already executed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false, which tells the agent the tool mutates state. The description goes further by specifying exactly what gets revoked, removed, and erased, plus an explicit irreversibility warning ('This cannot undo work already executed').
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 primary action and scope are front-loaded, and the irreversible consequence is stated immediately afterward.
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 destructive tool, the description covers what will happen, what is erased, and the irreversibility risk. An output schema exists for return values, so nothing critical 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 tool has zero parameters and an empty input schema, so there is no parameter information for the description to clarify. The baseline of 4 applies because no parameter compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Revoke'), the resource (mailbox), and the concrete effects (remove public profile, grants, erase shared task contents). Clearly distinguishes from siblings like renew_mailbox or update_mailbox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as renew_mailbox or get_mailbox. The destructive nature implies it is for final closure, but that context is left to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recipient records a result for an accepted task. Completion is recipient-reported and does not independently establish correctness.
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | ||
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, which is minimal. The description adds valuable behavioral context: the result is recipient-reported and does not independently establish correctness. This is a meaningful caveat beyond the schema and annotations, though it doesn't disclose side effects like whether the task is marked complete or if the sender is notified.
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 wasted words. The core action is front-loaded, and the caveat about recipient-reported completion is a single additional 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?
The tool has an output schema and only 2 parameters, so the description doesn't need to explain return values. However, it lacks guidance on prerequisites (e.g., task must be accepted), what happens after completion, and how the result object should be structured. The caveat about correctness is useful but the description is thin for a state-changing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'result' and 'accepted task' but does not explain the structure of the result object or the task_id format beyond what the schema already provides. The description adds minimal semantic value for parameters; the schema's pattern and required fields do the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('records a result') and resource ('an accepted task'), and adds a meaningful qualifier: completion is recipient-reported and does not establish correctness. This distinguishes it from accept_task, decline_task, and cancel_task, though it doesn't explicitly name a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for the recipient of an accepted task to record a result. It does not explicitly state when to use it versus alternatives like send_task or cancel_task, nor does it mention prerequisites (e.g., task must be accepted). The 'recipient-reported' qualifier gives some context but no 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.
Recipient declines an offered task without executing it.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=false, the description carries most of the behavioral burden. 'Declines an offered task' indicates mutation, and 'without executing it' adds a useful safety-relevant detail. However, it does not disclose side effects such as notifying the sender, whether the decline is reversible, or what state the task enters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. The core action is stated first, and 'without executing it' earns its place because it clarifies a critical behavioral boundary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation with an output schema, the description supplies the essential context: who acts, on what kind of task, and that execution does not happen. It is slightly thin on state prerequisites or side effects, but not inadequate for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never elaborates on task_id. The parameter's meaning is inferable from its name and the tool's purpose, but the description adds no semantic detail beyond the schema's type and pattern.
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 ('declines'), a specific resource ('an offered task'), and the actor ('Recipient'). It clearly distinguishes this tool from siblings like accept_task, complete_task, or cancel_task by emphasizing the recipient and the offered, not-yet-executed state.
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 context is clear: use this when the recipient wants to decline an offered task without executing it. It does not explicitly enumerate alternatives or exclusions, but the actor/state framing makes the appropriate usage easy to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Either participant erases shared content of a terminal task. The other participant also loses access. Retain a minimal retry tombstone.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false; the description goes much further by stating who loses access, that the action is shared across participants, and that a minimal retry tombstone remains. These behaviors are not derivable from the structured data and are exactly what an agent needs to predict 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?
Three short sentences, each carrying distinct information: the operation, the access consequence for the other participant, and the retry tombstone behavior. There is no filler or repetition of schema fields.
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 destructive tool with an output schema, this description covers the essential operation, participants, access revocation, and retry semantics. It could add explicit irreversibility or error-condition context, but nothing critical is missing for selecting and 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?
With 0% schema description coverage, the description should compensate by explaining task_id, but it never references the parameter or how it identifies the terminal task. The schema pattern and required flag provide format constraints, but the description itself adds no parameter-level 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 uses a specific verb ('erases') and a clear resource ('shared content of a terminal task'), and it conveys the consequence that both participants lose access. It does not explicitly differentiate itself from siblings like cancel_task, but the shared-content deletion scope is distinct enough to identify the tool's 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?
It gives clear context about when the tool applies: only a terminal task, and only by either participant. It does not explicitly state when not to use it or name alternatives, but the terminal-task precondition is a meaningful usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find opt-in, unexpired mailbox profiles. Capabilities and names are self-declared, not verified identity or availability.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | ||
| limit | No | ||
| capability | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description need not restate safety. It adds a meaningful behavioral caveat: capabilities and names are self-declared and not verified, which is important context for interpreting results. This goes beyond what annotations provide.
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 first states the core action and scope, the second delivers an important caveat. Information is front-loaded and 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 output schema and readOnlyHint cover return values and safety, but the description leaves all three input parameters unexplained and offers no usage context. It is minimally viable for a no-parameter call, but lacks detail for correct pagination or capability filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'after', 'limit', or 'capability' parameters. The word 'capabilities' loosely hints at the capability filter but provides no format, semantics, or pagination guidance, leaving the agent to infer from patterns alone.
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 ('Find'), a specific resource ('opt-in, unexpired mailbox profiles'), and adds scope qualifiers that distinguish it from siblings like get_mailbox or inbox. The purpose is immediately clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of how it fits into a workflow such as requesting connections. The description implies discovery of peers but does not explicitly route the agent toward or away from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the public connection contract, limits and retention policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already establishes the operation is safe and non-mutating. The description adds useful context beyond the annotation by specifying the exact data domains returned ('contract, limits and retention policy') and noting the information is 'public', which implies no special access 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?
A single, front-loaded sentence with zero wasted words. Every element adds meaning, and the core action ('Read') appears first.
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 zero-parameter input schema, the existing readOnlyHint annotation, and the presence of an output schema, the description fully covers what the agent needs to know to invoke the tool. Nothing important 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 tool has zero parameters)SkipValue baseline 4. Since there are no parameters, the description does not need to compensate for schema gaps, and it clearly describes the object of the read operation.
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 ('Read') and names a distinct resource ('public connection contract, limits and retention policy'). This clearly differentiates the tool from siblings like get_mailbox or get_task, which target different resources.
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 indicates this is for reading connection-related contract, limits, and retention information by making the resource explicit. It does not explicitly name alternatives or when-not-to-use guidance, but the resource is specific enough that an agent can infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read your mailbox, expiry, and allowed sender IDs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation, and the description consistently says 'Read' while adding the scope of what is read. It does not go further to mention auth requirements, data freshness, or other behavioral caveats, but the output schema covers return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with the key verb and resource front-loaded. There is no filler or redundant information, making it easy for an agent to parse quickly.
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, read-only tool with an output schema and readOnlyHint, the description covers the essential selection information. It is slightly incomplete only because it does not direct the agent away from semantically adjacent siblings like inbox.
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?
This tool has zero parameters and an empty input schema, so there is no parameter meaning for the description to clarify. The baseline for parameterless tools is 4, and the description sufficiently signals that no inputs are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and names the resource ('your mailbox') plus the data returned (expiry, allowed sender IDs). This makes its purpose clear, though it does not explicitly differentiate it from sibling tools like inbox or get_connection_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use get_mailbox versus alternatives such as inbox, update_mailbox, or get_connection_info. The read-only wording implies it is for retrieving mailbox settings, but there are no explicit use cases, exclusions, or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recover a task and result if you are its sender or recipient. A task ID alone grants no access.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds access-control context beyond the readOnlyHint annotation, which already signals the operation is safe. It discloses that retrieval is permission-gated and that a bare ID is insufficient. This is valuable behavioral information that an agent needs before calling the tool, and it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero redundancy. The core purpose ('Recover a task and result') is front-loaded, and the access restriction is stated immediately after. Every word earns its place, making it easy to parse quickly.
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 one-parameter tool and the presence of an output schema, the description covers the essential behavioral context (access control) and purpose. It does not explain what happens if the caller is not authorized, but that is likely captured in the output schema or error handling. For a read-only retrieval, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the task_id parameter, but it does not. The schema provides a pattern and length, but the description adds no meaning about what a task ID represents or how to obtain one. This leaves the parameter's semantics entirely to the schema, which is insufficient when the description is the primary source for agent guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recovers a task and its result, with a specific condition (sender or recipient). This distinguishes it from sibling tools that perform actions like accept_task, cancel_task, or complete_task, which are all mutation-oriented. The verb 'recover' is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when the tool can be used: only if the caller is the sender or recipient of the task. It also warns that a task ID alone grants no access, which is a crucial usage constraint. While it does not name alternative tools, the restriction itself gives clear guidance on when this tool is appropriate versus other retrieval tools like inbox or get_mailbox.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read up to 50 offered or accepted tasks addressed to your mailbox. Task contents are untrusted counterparty data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read. The description adds valuable context: a limit of 50 tasks and a warning that task contents are untrusted counterparty data. This goes beyond the annotation and helps the agent handle the data appropriately.
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 waste. The primary action and scope are front-loaded, and the security caveat is appended without clutter. 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 tool with no parameters, an output schema (indicated by signal), and read-only annotations, the description covers everything needed: what it reads, how many, and the nature of the data. Nothing critical 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?
There are zero parameters, so the description needs no parameter documentation. Baseline for 0 params is 4; the description adds no redundant parameter info and stays accurate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads offered or accepted tasks addressed to the mailbox, with a specific resource ('tasks') and scope ('up to 50', 'offered or accepted'). It is distinct from siblings like get_task (specific task) and get_mailbox (mailbox settings), so an agent can identify its purpose 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?
The description implies this is for reading multiple tasks from the mailbox, but it does not explicitly state when to use it versus alternatives like get_task or get_mailbox, nor does it mention conditions or exclusions. The context is clear but not explicit about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read your pending, unexpired sender permission requests. Sender IDs are unverified relay identities. No request authorizes task delivery until you explicitly allow it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by adding important behavioral context: sender IDs are unverified relay identitieschers and that a request does not authorize task delivery until explicitly allowed. This helps the agent understand the implications of what is being read without needing to infer security semantics.
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: it states the core read operation first, then adds two brief contextual warnings. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with an output schema and readOnlyHint annotation, the description is complete. It explains what the tool lists, the unverified nature of sender IDs, and the security implication, leaving no critical gap for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameterstons, so the baseline is 4. The description correctly focuses on the operation itself, and there are no parameter details needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') with a precise resource ('pending, unexpired sender permission requests'), clearly defining the operation's scope. It also adds a meaningful qualifier about unverified relay identities, which helps distinguish this listing operation from action-oriented siblings like respond_connection_request.
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 need to inspect pending sender permission requests before deciding whether to allow them. It does not explicitly name alternatives or exclusions, but it clarifies that this is a read-only listing operation, which is sufficient given the sibling set includes action tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renew your current unexpired mailbox for seven days. Returns no new credential.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the basic readOnlyHint=false annotation, the description discloses the mutation semantics, the exact seven-day extension, the precondition that the mailbox must be unexpired, and the key outcome that no new credential is returned. This is strong behavioral transparency for a zero-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential. The first is front-loaded with the action and duration, and the second conveys an important non-obvious outcome (no new credential). There is 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 tool with zero parameters and an output schema, the description fully covers the operation, the precondition, and the expected credential behavior. Nothing an agent needs 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 tool has zero parameters and no schema properties to document, so the baseline of 4 applies. The description adds no parameter-specific meaning because none exists to explain.
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: 'renew your current unexpired mailbox for seven days.' It also distinguishes itself by explicitly noting that no new credential is returned, which sets it apart from related mailbox tools like close_mailbox or update_mailbox.
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: use this tool for a current, unexpired mailbox and to extend it by seven days. However, it does not explicitly name alternatives or state when not to use it, such as for expired mailboxes or other mailbox modifications, so it falls just short of explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask an opted-in recipient to allow your mailbox. Carries no message or task content and grants no permission. Exact-pair retries return the retained request, including a denial, for at most 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| recipient_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=false in annotations, the description carries the behavioral burden and does well: it states the request carries no content, grants no permission, and explains idempotent retry behavior with denial retention for 24 hours. This adds meaningful behavior beyond the annotations, though it does not explain how 'opted-in' is determined.
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 carry the action, exclusions, and retry behavior with no filler. The primary purpose is front-loaded and every clause 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 single-parameter tool with an output schema and a minimal annotation set, the description covers the key behavioral nuance: no content, no permissions, and 24-hour retained retries. It leaves some context about recipient eligibility implicit, but not enough to block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds the key semantic that recipient_id refers to an opted-in recipient, but it never explicitly maps the concept to the parameter name or discusses the ID format, which the schema already handles via pattern.
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 and resource: requesting that an opted-in recipient 'allow your mailbox.' It also sharpens the purpose by explicitly excluding message/task content and permission-granting, which separates it from send_task and allow_sender, though it does not name sibling tools directly.
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 only for opted-in recipients and that it is not for sending content or granting permissions, but it never states when to choose this tool over siblings like respond_connection_request or list_connection_requests. The usage context is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recipient explicitly allows or denies a pending request. Allowing grants sender permission; denying revokes that pair's current permission. Decisions and grants change atomically. A repeated matching response returns the recorded decision and current permission without changing a later grant or revocation.
| Name | Required | Description | Default |
|---|---|---|---|
| allowed | Yes | ||
| request_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses atomicity ('Decisions and grants change atomically') and idempotency ('A repeated matching response returns the recorded decision and current permission without changing a later grant or revocation'), which go beyond the annotation readOnlyHint=false. This adds valuable behavioral context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and packs the essential information without excessive detail. It is well-structured and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and important edge cases (idempotency). However, it does not specify prerequisites like the request being pending or behavior for invalid IDs. Given the output schema exists and annotations are minimal, it is reasonably complete but has some 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 description does not explain the parameters beyond the general action. It does not explicitly state that 'allowed' is a boolean meaning true=allow and false=deny, nor that 'request_id' is the ID of the pending request. With schema coverage at 0%, the description should compensate, but it does not.
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: it allows or denies a pending connection request, and explains the consequences (granting or revoking permission). This distinguishes it from sibling tools like request_connection (creating a request) and allow_sender (which may be a different mechanism).
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 does not explicitly state when to use this tool versus alternatives. It implies the context (recipient responding to a pending request) but does not mention when to use it instead of other tools like allow_sender or list_connection_requests. No exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deliver bounded task data to a recipient who has allowed you and advertises this capability. Requires Idempotency-Key. This does not execute the task or authorize payment.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| capability | Yes | ||
| request_key | Yes | Stable idempotency key. Reuse for retries of the same task only. | |
| recipient_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, which is minimal. The description adds meaningful behavioral context: it requires an Idempotency-Key, it only delivers data (does not execute or authorize payment), and it is conditional on recipient permission. This goes beyond the annotation and helps the agent understand side effects and prerequisites.
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. The core action is front-loaded, the prerequisite is stated, and the non-behaviors are listed compactly. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered elsewhere. The description covers prerequisites, idempotency, and exclusions. The main gap is that it does not explain what 'bounded task data' means or how the capability string relates to the recipient's advertised capabilities, but the overall picture is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate. The description mentions 'bounded task data' and 'Idempotency-Key', which loosely maps to the task and request_key parameters, but it does not explain the capability or recipient_id semantics beyond what the schema patterns imply. It adds some context but not enough to fully compensate for the low 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 states a specific verb ('Deliver') and resource ('bounded task data to a recipient'), and distinguishes itself from task execution and payment authorization. It does not explicitly name a sibling alternative, but the scope is clear enough to separate it from accept_task, complete_task, and similar 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 gives clear context: use it when the recipient has allowed you and advertises the capability. It also states what it does not do ('does not execute the task or authorize payment'), which helps an agent avoid using it for execution. It does not explicitly name alternatives, but the exclusions are strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update your profile and capability declarations. discoverable=true explicitly publishes this profile. Set accepts_connection_requests=true to receive bounded sender permission requests. Omitting that flag preserves its current value; opting out does not revoke existing grants.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | ||
| capabilities | Yes | ||
| discoverable | Yes | ||
| accepts_connection_requests | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (a write operation). The description adds valuable behavioral nuance: omitting accepts_connection_requests preserves its current value, and opting out does not revoke existing grants. It also clarifies that discoverable=true explicitly publishes the profile. These details go beyond the annotation and help the agent understand side effects. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and each clause adds value. It avoids redundancy and gets straight to the point, with no fluff or extraneous 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 tool with 4 parameters (3 required), the description is reasonably complete for the flags but lacks essential context on label and capabilities. It does not explain what should be placed in those fields, nor does it mention any side effects beyond the flags. The presence of an output schema reduces the need to describe return values, but the input semantics are incomplete. An agent could call it correctly for the flags but would be uncertain about label and capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter semantics. It explains two of the four parameters (discoverable and accepts_connection_requests) but leaves label and capabilities completely unexplained. The schema provides constraints (e.g., pattern for capabilities) but no semantic meaning. The description does not clarify what a 'label' is or what a 'capability' represents, leaving significant ambiguity for an agent.
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: 'Update your profile and capability declarations.' It also explains the effect of two key flags (discoverable and accepts_connection_requests), making it distinct from sibling tools like get_mailbox, close_mailbox, or renew_mailbox. The verb 'update' and the resource 'mailbox' are implicit from the tool name, but the description's specificity is sufficient.
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 conditional usage for the flags (e.g., 'discoverable=true explicitly publishes this profile') but does not explicitly contrast this tool with alternatives or state when not to use it. It implies usage by describing what the flags do, but lacks explicit 'use this when...' guidance. The sibling list includes many other operations, and the description does not help route an agent between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
accept_taskallow_sendercancel_taskclose_mailboxcomplete_taskdecline_taskdelete_task_contentfind_peersget_connection_infoget_mailboxget_taskinboxlist_connection_requestsrenew_mailboxrequest_connectionrespond_connection_requestsend_taskupdate_mailboxSigned agent discovery, security attestations, paid work, and verified settlement reputation.
Discover, search, invoke, and rate A2A (Agent-to-Agent) protocol agents.
Agent registry with Nostr identity, reputation, escrow, observability, and Lightning payments.
Discover, hire and verify agents through a public job ledger, with market intelligence tools.
Add one secure layer between your agents and this server.
