Server Quality Checklist

Tool Scores

• relay_get_contact_cardC
  2.6/5.0
  Behavior2/5

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

  Annotations already cover read-only, idempotent, non-destructive behavior, so the description only adds the 'authenticated Agent's' scope. It does not disclose how the optional handle changes behavior, whether it can retrieve another agent's card, or what the returned contact card contains. This is a meaningful transparency gap for a getter with an optional parameter.

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

  Conciseness4/5

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

  The description is a single, clean, front-loaded sentence with no filler or repetition beyond the title. It is concise, though the brevity comes at the cost of omitting useful parameter and usage context.

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

  Completeness2/5

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

  Despite the simple schema and supportive annotations, the description is incomplete for a tool with an optional parameter and no output schema. It fails to clarify the meaning of 'handle', the return shape, or how this fits with sibling contact-card operations, making it insufficient for confident tool selection and invocation.

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

  Parameters1/5

  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 'handle' parameter at all. Since the description must compensate for the undocumented schema and does not, an agent cannot determine what value to pass or whether passing a handle is appropriate.

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

  Purpose4/5

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

  The description uses a specific verb ('Retrieve') and identifies the resource ('Relay Contact Card') with an ownership qualifier ('authenticated Agent's'), which separates it from mutating siblings like relay_set_contact_card and relay_update_contact_card. It loses a point because the optional 'handle' parameter is not mentioned, making the exact scope slightly ambiguous.

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

  Usage Guidelines2/5

  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 related contact-card tools, such as relay_set_contact_card, relay_update_contact_card, or relay_share_contact_card. The annotations imply a safe read operation, but the description itself provides no context for choosing this tool or excluding alternatives.

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

• relay_list_messagesC
  2.7/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description adds no behavioral context beyond stating the list operation. It does not disclose ordering, pagination, or that the open-world hint implies messages may change between calls. No contradiction exists, but the description carries minimal behavioral value beyond the annotations.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no filler or redundancy beyond echoing the title. It is compact, but it may be too sparse because important usage and parameter details are absent; however, that gap is more appropriately penalized under other dimensions.

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

  Completeness2/5

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

  There is no output schema, so the description should indicate what the return value looks like, but it does not. It also fails to explain how limit and cursor control pagination, which is essential for reliably listing all messages in a chat. The annotations cover safety, not completeness of invocation semantics.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description should compensate by explaining chat_id, limit, and cursor. It only clarifies that messages are scoped to one chat, which maps to chat_id, but says nothing about cursor-based pagination or the meaning of limit. The schema's names and constraints provide some information, but the description adds little semantic value.

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

  Purpose4/5

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

  Description uses a specific verb and resource: 'List Messages in one Relay Chat,' which clearly identifies the operation and scope. It also distinguishes from siblings like relay_list_chats (lists chats, not messages) and relay_get_message (gets a single message), though it could more explicitly contrast these alternatives.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives such as relay_get_message or relay_list_chats. It also omits practical context like pagination behavior and whether this is the default way to browse chat history. The description must be inferred from the name and input schema.

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

• relay_create_contact_requestC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate this is a mutating, non-idempotent operation. The description adds that the action is a request directed at a Relay user and involves the authenticated Agent, but it does not disclose side effects, notification behavior, or failure semantics. No contradiction 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.

  Conciseness4/5

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

  The description is a single sentence with no filler. However, the term 'premium-handle Agent' introduces unexplained jargon that reduces clarity.

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

  Completeness2/5

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

  For a one-parameter write tool with no output schema, the description should clarify what 'handle' refers to and what happens after the request is made. It only provides high-level intent, leaving the agent without enough operational detail to invoke the tool confidently.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description never mentions the 'handle' parameter, what it represents, or how to format it. Since the schema only provides a pattern and length constraints, the agent must infer whether the handle is the recipient, the sender, or something else entirely.

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

  Purpose4/5

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

  The description clearly identifies the action ('Ask a Relay user to add...') and the resource (the authenticated premium-handle Agent). It is distinguishable from sibling tools like relay_send_message or relay_set_contact_card, though the term 'premium-handle Agent' is somewhat opaque.

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

  Usage Guidelines3/5

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

  The description implies the tool is used when the agent wants to initiate a contact relationship with a Relay user. However, it gives no explicit guidance on when to prefer this over related tools, nor does it mention prerequisites or exclusions.

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

• relay_list_chatsC
  2.9/5.0
  Behavior3/5

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

  Annotations already signal readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds a small but useful behavioral detail: results are limited to chats visible to the authenticated Relay Agent. However, it does not disclose pagination behavior or response characteristics beyond that.

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

  Conciseness4/5

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

  The description is a single short sentence with no filler or redundant content. It is front-loaded and easy to parse. It is appropriately concise, though it sacrifices informational richness for brevity.

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

  Completeness2/5

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

  With no output schema, no parameter descriptions, and no explanation of pagination, the description is incomplete for an agent trying to use limit and cursor effectively. The basic no-argument invocation is clear, but advanced or correct paginated usage is not supported. Annotations help with safety but do not fill the informational gap.

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

  Parameters2/5

  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 'limit' or 'cursor' parameters. The property names and constraints imply pagination, but the description adds no meaning beyond the schema. Since the description does not compensate for the low coverage, this is a notable gap.

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

  Purpose4/5

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

  The description states a specific verb ('List') and resource ('Chats') with a useful scope qualifier ('visible to the authenticated Relay Agent'). It clearly identifies this as a list operation, distinguishing it from relay_get_chat and relay_list_messages at a basic level. It does not explicitly differentiate itself from siblings, but the resource and operation are unambiguous.

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

  Usage Guidelines2/5

  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 relay_get_chat or relay_list_messages. The description only says what it does, not when it should be preferred. No exclusions or alternative conditions are provided.

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

• relay_set_contact_cardC
  2.9/5.0
  Behavior3/5

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

  Annotations already mark this as a write (readOnlyHint=false) and non-idempotent. The description adds the useful context that the operation can replace the authenticated agent's existing contact card, implying overwrite behavior. It does not describe what happens to unspecified fields or external side effects, but 'create or replace' conveys the key behavior.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no filler; 'Create or replace' immediately conveys the core action. It is concise, though arguably too terse to carry the missing usage and parameter guidance.

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

  Completeness2/5

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

  For a mutation tool with no output schema, no parameter descriptions, and an adjacent relay_update_contact_card sibling, this definition is incomplete. It lacks guidance on full-replacement semantics, required-field implications, and when to prefer this over the update sibling.

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

  Parameters2/5

  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 any of the four parameters. The term 'Contact Card' gives some context for fields like first_name, last_name, and image_url, and the handle's schema pattern is visible, but the description adds no real meaning beyond the property names and constraints.

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

  Purpose4/5

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

  The description states a specific verb/resource: it creates or replaces the authenticated Agent's Contact Card. This distinguishes it from reads and contact-request operations, but it does not explicitly explain how 'set/replace' differs from the sibling relay_update_contact_card, leaving some ambiguity.

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

  Usage Guidelines2/5

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

  No usage guidance is provided: the description does not say when to use this tool instead of relay_update_contact_card, whether it is intended for full replacement while update is for partial changes, or any prerequisites. The agent must infer the choice from the tool name alone.

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

• relay_update_contact_cardC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate this is a mutating, non-idempotent operation, so the description does not need to restate that. It adds modest behavioral context by specifying 'selected fields' and scoping to the authenticated agent, but it does not disclose whether unspecified fields are preserved, how image_url null is handled, or what side effects occur.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no filler or repetition. It is concise, though it sacrifices useful detail for brevity.

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

  Completeness2/5

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

  For a mutating tool with no output schema and zero schema description coverage, the description is too sparse. It omits key context such as parameter roles, partial-update semantics beyond the phrase 'selected fields', and how this relates to the contact card sibling tools.

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

  Parameters1/5

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

  The input schema has no descriptions for any of the four parameters, so the description must compensate by explaining or enumerating them. It does not mention handle, image_url, first_name, or last_name at all, leaving the agent to rely only on parameter names and constraints.

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

  Purpose4/5

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

  The description clearly states a specific action ('Update') and resource ('authenticated Agent's Contact Card'), and the phrase 'selected fields' implies a partial update. However, it does not explicitly differentiate this from the sibling relay_set_contact_card, so an agent must infer the distinction.

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

  Usage Guidelines3/5

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

  The description implies this tool is for partial updates to the authenticating agent's own contact card, which is a useful usage signal. It does not explicitly state when to prefer this over relay_set_contact_card or other siblings, nor does it mention any exclusions or alternatives.

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

• relay_get_message_threadB
  3/5.0
  Behavior3/5

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

  Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false), so the description carries little burden for side effects. It adds no behavioral context beyond the literal statement, such as whether the root message is included in results, how order and cursor behave, or what the open-world hint implies for live threads. This is adequate but adds no value beyond what the annotations already provide.

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

  Conciseness5/5

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

  A single eight-word sentence with the action verb front-loaded and zero filler. It is appropriately sized for the information it aims to convey.

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

  Completeness2/5

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

  With no output schema, 0% parameter coverage, and no explanation of thread membership or pagination behavior, the one-sentence description leaves significant gaps. The rich annotations cover safety but not the operational details an agent needs to invoke this correctly versus relay_list_messages or relay_get_message.

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

  Parameters2/5

  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, but it only clarifies the role of message_id as the root anchor. The semantics of limit, order, and cursor are undocumented in both the schema and the description, leaving an agent to guess pagination and ordering defaults.

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

  Purpose4/5

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

  The description uses a specific verb ('List') and a defined resource ('the thread rooted at one Relay Message'), making the core operation identifiable. It is not a tautology and conveys that the tool retrieves a threaded conversation anchored to a message_id. However, it does not explicitly differentiate from siblings like relay_list_messages or relay_get_message, which serve adjacent lookups.

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

  Usage Guidelines2/5

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

  The description offers no guidance on when to use this tool versus the 15 siblings, particularly the closely related relay_list_messages and relay_get_message. There is no when-to-use, when-not-to-use, or mention of alternatives, so an agent must infer the distinction from the title and naming alone.

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

• relay_mark_chat_readB
  3/5.0
  Behavior3/5

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

  Annotations already convey that the call is a mutation (readOnlyHint=false), idempotent (idempotentHint=true), and non-destructive. The description adds that read state is scoped to the Agent and to the visible chat, which is useful context beyond the schema. It does not describe side effects like unread-count updates, but the annotation set lowers the bar.

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

  Conciseness4/5

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

  One sentence, front-loaded with the action and object, and no filler. The phrase 'by the Agent' is mostly redundant with the tool title but not harmful. It earns a strong conciseness score despite semantic vagueness.

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

  Completeness3/5

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

  For a one-parameter, idempotent, non-destructive tool, the core operation is simple and annotations carry safety. However, the missing link between the described 'visible chat' and the required chat_id, plus the lack of any usage trigger, keeps it from being fully complete. It is minimally adequate rather than thorough.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description should explain the chat_id parameter, but it never mentions chat_id or how the 'visible Relay Chat' maps to it. The single uuid parameter is self-naming, so an agent can guess, but the description adds no semantic value. This is a clear gap.

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

  Purpose4/5

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

  Names a specific action (mark as read), a resource (Relay Chat), and an owner/scope (by the Agent), which distinguishes it from sibling tools like relay_list_chats or relay_send_message. The qualifier 'visible' is not defined, so it does not fully specify which chat beyond the required chat_id. Still clearly more than a tautology.

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

  Usage Guidelines2/5

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

  Description provides no explicit when-to-use or when-not-to-use guidance, nor does it name an alternative or mention prerequisites such as the chat being open/visible. The need to mark read after viewing is only implied by the verb phrase. This leaves the agent to infer the trigger condition.

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

• relay_react_to_messageA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate this is a mutating, non-idempotent, and destructive operation. The description adds useful scope context by saying the reaction applies to a message 'part' and supports both add and remove. It does not disclose behaviors like replacing an existing reaction or what happens when removing a non-existent reaction, but the annotations carry much of the safety burden.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no redundant wording. It clearly names the action and target, which is appropriately concise for a tool whose schema already defines the enumerations and required fields.

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

  Completeness2/5

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

  Given five parameters, zero parameter descriptions in the schema, and no output schema, the tool description is under-specified. It lacks guidance on when 'part_index' should be used, how custom emojis are handled, and what the result of the operation is. The annotations cover safety, but not the operational details needed to call the tool correctly.

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

  Parameters2/5

  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 parameters, but it only clarifies the operation concept. It does not explain the relationship between 'type', 'custom_emoji', or 'part_index', nor specify that 'custom' likely requires a custom_emoji value.

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

  Purpose5/5

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

  The description states a specific action ('add or remove a reaction') and a specific resource ('Relay Message part'), making the tool's purpose immediately clear. It also differentiates this from sibling tools like send or get by focusing on reactions rather than message content.

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

  Usage Guidelines3/5

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

  The intended usage is implied by the action: use this tool when a reaction needs to be added or removed. However, the description gives no explicit guidance about when not to use it or how it compares with alternatives such as sending a message or modifying a chat.

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

• relay_send_message_to_chatA
  3.5/5.0
  Behavior4/5

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

  Annotations already provide idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds a meaningful behavioral rule—'Reuse the idempotency key only for the same logical send'—and qualifies the chat as 'known', implying the chat must already exist. This adds context beyond the annotations without contradicting them.

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

  Conciseness5/5

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

  Two short sentences with the primary action front-loaded and the key idempotency caveat in the second sentence. There is no filler or redundant restatement of the schema.

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

  Completeness3/5

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

  For a 3-parameter mutation with annotations and no output schema, the description covers the core operation and idempotency rule. However, it does not explain how to identify a 'known' chat or how this tool differs from the similarly named sibling relay_send_message, which is a notable gap given the dense sibling list.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must carry parameter meaning. It implies text is the message content, chat_id refers to the known chat, and it clarifies idempotency_key semantics. However, it never explicitly maps parameters or explains text formatting or how to obtain chat_id.

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

  Purpose4/5

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

  The description names a specific action, 'Send a text Message', and a specific target, 'a known Relay Chat', so an agent can identify the core operation clearly. It does not explicitly contrast this with the similarly named sibling relay_send_message, which slightly weakens differentiation.

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

  Usage Guidelines2/5

  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; it never mentions relay_send_message, relay_list_chats, or any selection condition. The idempotency-key sentence is an operational instruction, not usage-selection guidance.

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

• relay_share_contact_cardA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate a non-read-only, non-idempotent side effect, and the description adds useful context that the shared card is the authenticated agent's configured contact card rather than an arbitrary card. However, it does not disclose whether this creates a visible chat message, what happens on success, or any failure conditions. This is minimal additional behavioral context.

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

  Conciseness5/5

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

  The description is a single concise sentence with no filler. The core action and target are front-loaded, and every word contributes to the tool's purpose.

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

  Completeness3/5

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

  For a one-parameter, low-complexity tool, the essentials of what is shared and where are present. However, with no output schema and no mention of return behavior, prerequisites like an existing chat, or whether the action produces a visible message, an agent is left to infer the outcome. It is minimally adequate but not fully complete.

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

  Parameters3/5

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

  The schema has 0% description coverage, but the single parameter chat_id is largely self-explanatory from its name and UUID format. The description's phrase 'into a Chat' clarifies that chat_id identifies the target chat, adding some semantics beyond the schema. Still, the description does not explicitly document the parameter or edge cases, so it only partially compensates for the lack of schema descriptions.

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

  Purpose5/5

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

  The description uses a specific verb ('Share'), a specific resource ('the authenticated Agent's configured Contact Card'), and a target ('a Chat'), making the tool's function immediately clear. It differentiates itself from sibling contact-card management tools like relay_get_contact_card and relay_set_contact_card, and from generic messaging tools like relay_send_message.

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

  Usage Guidelines2/5

  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 prerequisites, exclusions, or refer to sibling tools such as relay_get_contact_card for configuration or relay_send_message for normal messages. There is effectively no usage guidance beyond the stated action.

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

• relay_start_typingA
  3.6/5.0
  Behavior3/5

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

  Annotations already convey that this is a non-read-only, non-destructive, idempotent action. The description adds the useful 'refresh' behavior, but it does not disclose how long the indicator lasts, whether it expires, or whether the agent must later call relay_stop_typing; this is acceptable for a simple action but not thorough.

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

  Conciseness5/5

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

  A single sentence with no filler; every word contributes the action, the refresh nuance, and the target context. It is appropriately front-loaded and easy to scan.

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

  Completeness4/5

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

  For a one-parameter, no-output-schema tool whose safety profile is already in annotations, the description is essentially complete. The only missing nuance is lifecycle guidance about stopping or expiry, which is not critical to making a correct call.

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

  Parameters3/5

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

  With schema description coverage at 0%, the description should compensate for parameter documentation, but it never mentions chat_id. The parameter name and UUID schema are self-explanatory and the description's 'in a Chat' reinforces that chat_id identifies the target, so the gap is minor.

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

  Purpose4/5

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

  The description states a specific action ('Start or refresh') and a concrete resource ('Agent typing indicator in a Chat'), so an agent understands the tool's function. It does not explicitly name or differentiate from the sibling relay_stop_typing, though the verb choice makes the contrast reasonably clear.

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

  Usage Guidelines3/5

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

  The tool implies its use case: call it when the agent is composing or continuing to type in a chat. It gives no explicit conditions, exclusions, or pointer to relay_stop_typing for ending the indicator, so usage guidance is only implied.

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

• relay_stop_typingA
  3.7/5.0
  Behavior3/5

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

  Annotations already establish that this is a mutating, idempotent, non-destructive operation. The description adds the specific side effect: it stops the agent's typing indicator in a chat. It does not describe edge cases like calling when no indicator is active, but idempotence mitigates that concern.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the action and its scope, 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.

  Completeness4/5

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

  For a tool with one required parameter and no output schema, the description is adequately complete: annotations cover idempotence and safety, the schema defines chat_id format, and the description defines the action. A bit more parameter context would help, but it is not required for correct invocation.

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

  Parameters2/5

  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 only says 'in a Chat,' which adds minimal meaning to chat_id; it does not explain how to obtain the chat_id or any behavior tied to it. The description does little beyond restating the parameter's obvious role.

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

  Purpose5/5

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

  The description uses a specific verb ('Stop') with a precise object ('Agent typing indicator') and a scope ('in a Chat'). This clearly differentiates it from the sibling relay_start_typing and leaves 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.

  Usage Guidelines3/5

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

  Usage is implied by the operation's meaning and the antonymous sibling relay_start_typing, but the description does not explicitly state when to call this tool, when not to, or mention any alternative. There are no prerequisites or exclusions provided.

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

• relay_get_chatA
  4/5.0
  Behavior3/5

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

  The description aligns with the readOnlyHint, idempotentHint, and destructiveHint annotations but does not add behavioral context beyond them, such as auth requirements, not-found behavior, or side effects. It is consistent with annotations and not contradictory, but it contributes no additional transparency beyond the structured data.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that conveys the operation and target with zero filler. Every word contributes meaning, and it does not repeat schema or annotation content unnecessarily.

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

  Completeness4/5

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

  For a simple read-only lookup with one required, schema-validated ID parameter and safety annotations, the description plus schema is nearly complete. The only minor gap is lack of explicit return-shape or not-found behavior, though 'Retrieve one Relay Chat' implies the returned chat object.

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

  Parameters4/5

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

  The input schema has no descriptive text for chat_id (0% coverage), so the description's 'by ID' is the only prose tying the parameter to the resource. It effectively communicates that chat_id identifies the target chat, and combined with the schema's type/format/pattern, this is sufficient for the single parameter.

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

  Purpose5/5

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

  The description uses the specific verb 'Retrieve' with the resource 'one Relay Chat' and the access method 'by ID'. The word 'one' clearly distinguishes it from relay_list_chats and other relay_* getters, so an agent can tell exactly what this tool does.

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

  Usage Guidelines3/5

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

  The description implies use when you already have a chat_id and want a single chat entity, but it gives no explicit when-not or alternative guidance. It does not name relay_list_chats as the alternative for browsing multiple chats. The usage context is implied rather than spelled out.

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

• relay_get_messageA
  4/5.0
  Behavior3/5

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

  The annotation block already declares readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description does not add meaningful behavioral context beyond that, such as how missing/invalid IDs are handled or what fields the response includes, but the bar is lower given the rich annotations.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence with no filler or repetition. Every word carries meaning and the core action, object, and lookup key are all present.

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

  Completeness4/5

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

  Given the simple one-parameter read-only operation and strong annotations, the description is nearly complete. It does not explicitly describe the return value or error behavior, but 'Retrieve' clearly implies the message is returned, and the annotations cover safety semantics.

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

  Parameters3/5

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

  The input schema has 0% description coverage, so the description must compensate. It does link message_id to the retrieval action ('by ID'), but it does not explain the semantics of the ID beyond what the property name and UUID format already imply. For a single obvious parameter, this is adequate though minimal.

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

  Purpose5/5

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

  The description uses a specific verb ('Retrieve') and resource ('one Relay Message') plus the mechanism ('by ID'). This clearly distinguishes it from sibling tools like relay_list_messages, which list messages, and relay_get_message_thread, which retrieves a different resource.

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

  Usage Guidelines4/5

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

  The description makes the usage context clear: use this when you need a single Relay Message identified by its ID. It does not explicitly mention alternatives or when-not-to-use conditions, but the 'one ... by ID' wording implies it is not for listing, sending, or thread retrieval.

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

• relay_send_messageA
  4.2/5.0
  Behavior4/5

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

  Annotations already show readOnlyHint=false, idempotentHint=true, and destructiveHint=false, but the description adds meaningful behavioral nuance: it may create a Chat as a side effect, and it warns that the idempotency key must be reused only for the same logical send. This goes beyond the annotations and helps an agent avoid incorrect key reuse.

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

  Conciseness5/5

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

  Two succinct sentences with no filler. The primary action is front-loaded, and the critical idempotency caution is placed second. Every sentence adds value.

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

  Completeness4/5

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

  The description covers the core behavior, the Chat-resolution side effect, and the idempotency caveat—enough for an agent to invoke the tool with appropriate caution. It does not describe the return value or failure behavior, but with no output schema and straightforward parameters, this is a minor gap rather than a critical one.

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

  Parameters3/5

  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 clarifies recipients as Relay Handles and gives an important idempotency-key reuse rule. However, it does not elaborate on recipient formatting, text constraints, or idempotency key semantics beyond the reuse warning, leaving the schema to carry most parameter-level detail.

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

  Purpose5/5

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

  The description states a specific action—resolve or create a Chat and send a text Message—and clearly identifies the target as Relay Handles. This distinguishes it from sibling relay_send_message_to_chat, which presumably targets an existing chat by ID. The verb and resource are concrete and unambiguous.

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

  Usage Guidelines4/5

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

  The phrase 'to Relay Handles' gives clear context for when this tool should be used: when recipients are handles rather than chat IDs. It does not explicitly name relay_send_message_to_chat as the alternative, nor state exclusion conditions, but the handle-based targeting is a sufficiently clear usage signal.

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