Server Quality Checklist

Tool Scores

• login_with_promiseA
  3.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key side effects: the login replaces any prior identity, clears memberships from a different account, and establishes a long-lived refresh token so Promise is never contacted again. This is meaningful transparency, though it omits error handling or token validation details.

  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 concise and front-loaded with the main action, followed by two brief sentences covering persistence and identity replacement. There is no redundant or tangential information; every sentence earns its place.

  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 single-parameter tool with no output schema, the description covers the core behavioral aspects: the token exchange, persistence, and destructive side effects on prior identity. It does not describe the return value or error scenarios, but the main call context is well-addressed. The absence of output schema makes return details less critical.

  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 coverage is 100%—the id_token parameter already carries a clear description ('A fresh Promise-issued id_token (JWT). Single-use and short-lived — exchange it promptly.'). The tool description adds context about the audience and OIDC, but this is supplemental rather than essential. The parameter semantics are already adequately documented in the schema.

  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 the action: exchanging a Promise id_token for a persistent Oase identity, with specific details like audience and OIDC. It is unambiguous about the tool's core function, but it does not differentiate from sibling tools promise_login_start and promise_login_finish, which appear to represent an alternative multi-step flow.

  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 explicit guidance is given on when to use this tool versus the sibling promise_login_start/finish flow. The phrase 'one-time setup' implies a use case, but there is no direct statement of conditions, prerequisites, or exclusions. An agent must infer that this is for initial or replacement logins.

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

• list_oasesA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. The description implies a read-only operation by using 'show', but it does not explicitly state side effects, authentication requirements, or any error conditions. It also does not describe the format or detail of the returned data, which could be important for an agent. This is a modest disclosure for a simple read tool.

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

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the core functionality. Every word adds value, and there is no redundant information. It is efficient and memorable.

  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 simplicity of the tool (no parameters, no output schema), the description covers the essential information: what the tool does and what it returns. It does not specify details like pagination, ordering, or the exact structure of the identity object, but given the lack of an output schema, these are not strictly required. The description is complete enough for an agent to understand the tool's purpose and invoke it without ambiguity.

  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 tool has zero parameters, and the schema is an empty object. The description does not need to explain any parameters. With 100% schema coverage (trivially) and no parameters to clarify, the description adds no extra parameter semantics, which is acceptable. Baseline 4 is appropriate.

  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 clearly states the tool's function: showing the agent's Oase identity and the oases it has joined. The verb 'show' is specific and the resource is well-defined, making the purpose unambiguous. It is distinct from sibling tools like join_oase or send_message, which are clearly different operations.

  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 any conditions, prerequisites, or recommend other tools for different scenarios. The only hint is the title 'List joined Oases', which implies usage for listing memberships, but no explicit instructions are given.

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

• join_oaseA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of disclosure. It discloses the authentication requirement, that it sets the display name, and that it makes this oase the default target for send_message. These are important side effects. It does not mention failure behavior or reversibility, but for a join operation this is reasonably transparent.

  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 three concise sentences with no unnecessary words. It front-loads the core action, then lists the prerequisite, and then the side effects. Every sentence adds value and there is no fluff.

  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 is complete for a join tool: it explains the prerequisite, the side effects (setting display name and default target), and gives an example URL. It lacks details on error handling or return value, but given the absence of an output schema and the simplicity of the operation, the key information is present. It could mention what happens if the invite link is invalid, but that is minor.

  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 100%—both parameters have clear descriptions in the schema. The description adds minimal extra meaning beyond restating that it sets display name, which is already in the parameter description. It also mentions the invite link format in the description, but that's also covered in the schema. Baseline 3 is appropriate since the schema already explains the parameters well.

  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 clearly states the specific action: joining an oase via an invite link, with an explicit URL example. It also distinguishes itself from siblings by noting it is different from sending messages or other operations, and it specifies that it sets the default target for send_message, which is a unique behavior.

  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 gives a clear prerequisite: the user must be logged in as a Promise user first, referencing the specific login tools (promise_login_start/finish). This tells the agent when to use the tool (after login) and what the alternative actions are for authentication. It does not explicitly mention when not to use it, but the purpose is distinct enough from siblings.

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

• read_mediaA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does well: it discloses that attachments are decrypted, images are returned inline, and all attachments are saved to a local file with the path returned. This goes beyond the basic 'read' action, explaining side effects and output format. It does not mention potential errors or permission requirements, but the disclosed behavior is adequate for most use cases.

  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 concise and well-structured, leading with the primary purpose, then the usage pattern, then the output behavior and suggestions. Each sentence adds substantive value without redundancy or excessive length. It is front-loaded and easy to parse.

  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 tool's complexity (3 params, no output schema, no annotations), the description covers all necessary operational details: how to identify an attachment, what happens with images (inline) and other types (saved locally with path), and how to leverage the content. It does not mention error conditions or format limitations, but these are not critical for an agent to invoke the tool correctly. Overall, it provides sufficient context for successful use.

  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 100%, with all three parameters clearly documented (message_id required, oase_id defaults to last joined, media_index is the <n> in the attachment list and defaults to 0). The description adds no new parameter-level meaning; it merely reiterates the attachment index concept in prose. Since the schema already handles parameter semantics, a baseline of 3 is appropriate.

  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 clearly states the tool downloads and decrypts attachments from chat messages, listing specific types (images, voice messages, videos, documents). It explains the mechanism for identifying which attachment via message id and index, distinguishing it from sibling tools like read_messages which focus on message content rather than attachments.

  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 provides explicit guidance on how to use the tool: it explains that attachments are listed as [attachment <n>: <type> "name"] and instructs to pass the message id and index. It also offers post-processing guidance (transcribe audio, open documents) and mentions using content in responses, giving clear context. It does not explicitly state when not to use it or name alternatives, but no direct alternative exists among siblings.

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

• set_nameA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description alone must convey behavioral traits. It discloses a key side effect: 'Also updates the default name for future joins.' This goes beyond the basic write operation implied by 'Change'. However, it does not mention any constraints, error conditions, or return behavior. Given the simplicity of the tool, the disclosure of the side effect is valuable but not exhaustive, making a mid-range score appropriate.

  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 extremely concise, with three short sentences that immediately convey the purpose, the optional parameter behavior, and the side effect. Every sentence carries essential information with no wasted words or redundant phrasing. The structure front-loads the primary function and then adds critical specifics, 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 simple tool with two parameters and no output schema, the description covers the essential aspects: the primary action, the optional parameter semantics, and a notable side effect. It does not mention prerequisites (e.g., being logged in) but given the sibling tools for login/join, that may be implicit. The absence of return-value details is acceptable without an output schema. Overall, it is sufficiently complete for correct invocation in most scenarios.

  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 describes both parameters with basic descriptions ('Target oase id' and 'New display name'), achieving 100% coverage. The description adds crucial semantic meaning for oase_id: 'Omit oase_id to use the default oase.' This clarifies that the parameter is optional and defines the default behavior, which is not evident from the schema alone. This addition elevates the score above the baseline of 3.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: changing the display name of the agent in an oase. It specifies the verb 'Change' and the resource 'display name in an oase', and mentions the agent's own name ('this agent'), which distinguishes it from any sibling actions. No sibling tool appears to involve name changes, so it stands out clearly.

  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 gives specific usage guidance by explaining the optional parameter behavior: 'Omit oase_id to use the default oase.' This tells the agent when to omit the parameter and what the default behavior is. While it doesn't explicitly compare to alternatives (none are obvious among the siblings), it provides clear context on how to correctly invoke the tool in different scenarios.

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

• send_messageA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description discloses key behaviors: default oase selection, thread-post semantics (one level deep, root resolution, auto-resolution of reply ids). It does not describe return values or potential errors, but these are not strictly expected for a send operation and the threading details are thorough.

  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 five sentences, front-loaded with the core purpose, then detailed threading rules. It is efficient without redundant phrasing; each sentence contributes to operational clarity.

  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 3-parameter tool with no output schema, the description covers default oase behavior, threading constraints, and explicit use-case guidance. Missing details like message length limits are minor and not essential for correct invocation; markdown support is mentioned.

  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?

  Schema covers all 3 parameters with descriptions, providing a baseline of 3. The description adds meaningful context beyond the schema: the default behavior for oase_id, the validation that thread_id must be a main-chat message, and auto-resolution logic — all of which clarify usage conditions not evident from the schema alone.

  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 clearly states the action ('Send a markdown chat message into an oase') with a specific verb and resource, and implicitly distinguishes from siblings like send_post (which sends posts, not chat messages). The mention of threading further separates it from read_messages and react_to_message.

  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?

  It provides explicit guidance on when to use thread_id (to reply to a specific message or continue a conversation) and explains the default behavior when oase_id is omitted. It does not explicitly name alternative tools for comparisons, but the channel-specific language ('oase', 'chat message') is sufficient to infer posting vs. messaging contexts.

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

• delete_messageA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses soft delete behavior, default oase selection, and permission requirements. It also mentions the backend rejection scenario, which is a helpful behavioral detail. It doesn't cover all possible side effects, but it's more than adequate for this tool.

  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 three concise sentences, front-loaded with the main action and soft-delete note, followed by parameter sourcing and permission guidance. No fluff or redundancy; every sentence provides essential information.

  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 2 parameters (1 required) and no output schema, the description covers the key aspects: how to get the message, the default oase behavior, and permission constraints. It doesn't mention the response format, but that's not critical given the simplicity. It's reasonably complete for an agent to call it correctly.

  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?

  Schema coverage is 100%, so parameters are documented. The description adds value beyond the schema by explaining where message_id comes from and that omitting oase_id defaults to the last joined oase, which is not in the schema. This enriches the parameter understanding.

  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 clearly states the action ('Delete a chat message') and the specific behavior (soft delete). It distinguishes from sibling tools like update_message and delete_post by indicating it's for messages, and it specifies the resource type. The verb and resource are specific and unambiguous.

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

  Usage Guidelines4/5

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

  Provides explicit context on how to obtain the message_id ('from send_message or read_messages output') and explains the default behavior of oase_id. It also gives clear conditions for successful execution (own messages vs. requiring admin/owner). It doesn't explicitly mention alternatives, but the context is sufficient for correct usage.

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

• promise_login_finishA
  4.4/5.0
  Behavior4/5

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

  With no annotations present, the description carries the full behavioral burden and delivers: it discloses that the tool blocks ('waits for the browser redirect'), mutates durable state ('exchanges it for a persistent Oase identity'), and has a side effect ('shuts down the callback server'). These traits would otherwise be invisible to the agent, so this is substantive disclosure.

  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 well-structured sentence that front-loads purpose ('Complete the login started by promise_login_start'), then enumerates the sequential behaviors with colons and commas. Every clause earns its place; there is zero filler.

  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 an empty schema, no annotations, and no output schema, the description adequately covers the operation's core semantics and workflow context. It does not mention error/failure behavior or prerequisites beyond the start-step pairing, but for a zero-parameter completion step the essentials are present.

  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 is empty (0 parameters), so per calibration the baseline is 4. The description adds no parameter detail, but there are no parameters to document — nothing is missing.

  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?

  States a specific verb and resource ('Complete the login') and names its dual-step sibling (promise_login_start) directly in the opening clause. The three concrete behaviors — wait for redirect token, exchange for persistent identity, shut down callback server — leave no ambiguity about what this tool does or how it differs from promise_login_start.

  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 'started by promise_login_start' clearly places it as the second half of a two-step flow, so an agent knows it must call promise_login_start first. It does not explicitly exclude alternatives like login_with_promise or state when-not-to-use conditions, but the workflow pairing is strongly implied and sufficiently directional.

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

• react_to_messageA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the one-reaction-per-message-per-participant constraint and the 'already reacted' failure, which are non-obvious behaviors. It implies a mutation via 'add'. However, it does not mention other side effects like authorization or reversibility, leaving a small gap.

  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 sentences deliver the action, the source for the key parameter, and the critical constraint—all front-loaded with zero waste. The structure is compact and information-dense.

  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 mutation with no annotations, the description covers the key behavioral nuance (duplicate failure) and parameter sourcing. It does not describe the success output, but without an output schema that's not strictly required. Minor omissions like permissions are acceptable given the tool's simplicity.

  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?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly directing the agent to read_messages for message_id, which is a practical hint. It does not augment the reaction parameter, but the schema already explains emoji/short text, so the extra guidance justifies a 4.

  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 clearly identifies the action (add an emoji reaction), the target (a message in an oase), and the context. It distinguishes itself from siblings like send_message (creating a message) and update_message (editing a message) by specifying the reaction operation.

  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?

  It tells the agent to obtain message_id from read_messages output, providing a clear usage context. It doesn't explicitly list alternatives, but the action's specificity makes when-to-use unambiguous. A brief statement about not being for editing or deleting could push to 5, but the guidance is adequate.

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

• delete_postA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the permission requirement (own post or admin/owner, else backend rejects) and the default oase_id behavior. It does not mention irreversible deletion or cascading effects, but these are generally implied by 'delete'. The disclosed rejection condition is valuable and goes beyond the schema.

  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 three sentences, front-loaded with the primary action, and includes necessary details (post_id source, oase_id default, permission constraint) without any fluff. Every sentence adds value.

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

  Completeness5/5

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

  For a simple delete tool with 2 parameters, no output schema, and no annotations, the description covers all necessary aspects: what it does, how to identify the target, default oase behavior, and permission constraints. An agent has everything needed to call it correctly.

  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?

  Schema coverage is 100% for both parameters, but the description adds extra meaning: how to obtain post_id (from send_post/read_posts) and the default behavior for oase_id. This enhances the agent's understanding beyond the schema's basic 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 states a specific verb ('Delete'), the resource ('a post (opslag)'), and the context ('from an oase's feed'). It also names the source of the post_id (send_post or read_posts output), which immediately distinguishes it from sibling tools like delete_message (messages vs posts) and update_post (modification vs deletion). Nothing is vague or tautological.

  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?

  It provides clear context on when to use the tool: when you have a post_id (from send_post/read_posts) and you either own the post or are an oase admin/owner, otherwise the backend rejects it. It also explains the default behavior for oase_id. It does not explicitly name alternatives, but the conditions for deletion are unambiguous, and the purpose is distinct from siblings like update_post.

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

• read_messagesA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description fully bears the burden of behavioral disclosure. It reveals that messages are decrypted, how they are ordered, the tagging scheme for the agent's own messages, the display of reactions and attachments, and explicitly warns that reactions are real answers (not just UI clutter). It also explains that attachments require read_media, providing essential behavioral context for correct handling.

  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 longer than typical, but every sentence contributes actionable information. It starts with the core purpose, then moves to output format, then to usage instructions for replying, threading, reactions, and attachments. There is no filler or redundancy; the structure is logical and front-loaded with the most essential facts.

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

  Completeness5/5

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

  Given that there is no output schema, the description must (and does) explain the return format in enough detail for an agent to interpret results correctly: each line includes an id, tags, reactions, and attachment markers, plus how to use each piece with other tools. It also covers edge cases like thread replies and attachment handling, making the tool fully usable without further probing.

  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 already documents both parameters, including their defaults (limit defaults to 20, oase_id defaults to last joined oase). The description does not add additional semantic meaning beyond what the schema provides. With schema coverage at 100%, a baseline of 3 is appropriate.

  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 clearly states the verb (read) and resource (recent chat messages in an oase), adds meaningful detail like 'decrypted' and 'oldest first', and distinguishes from sibling tools like read_posts (posts vs messages) and send_message (write vs read). The purpose is unambiguous and specific.

  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 gives explicit context for when to use this tool (reads recent messages) and provides clear instructions on how to act on the output: replying uses send_message with thread_id, continuing threads uses the root id, and any id works for react_to_message. However, it does not explicitly name alternatives for reading posts or state when not to use this tool, so it stops short of a 5.

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

• update_messageA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description must fully disclose behavior, and it does. It states that only text changes (attachments kept), that edits to others' messages are rejected by the backend, that the message must be in recent history, and the default oase behavior. These are non-obvious behavioral traits that go beyond the schema, providing clear expectations 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.

  Conciseness5/5

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

  The description is a concise set of sentences, each adding value without redundancy. It front-loads the main action and then details the necessary constraints and defaults, making it easy to parse quickly. No fluff or irrelevant details.

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

  Completeness5/5

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

  For a relatively simple edit tool, the description covers all essential aspects: how to identify the target message, default behavior, restrictions (own messages, recent history), and side effects (only text changes). Without an output schema, it doesn't need to describe return values. The description is complete for correct invocation.

  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 already provides 100% coverage for all three parameters (message, oase_id, message_id). The description adds helpful context, such as where to obtain message_id and the default behavior for oase_id, which enhances understanding but is not strictly necessary given the schema. This aligns with the baseline 3 for high schema coverage.

  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 clearly states the action: 'Edit the text of a chat message this agent sent earlier', specifying the verb (edit) and resource (chat message) with a precise scope (own messages only). It distinguishes from siblings like send_message or delete_message by focusing on modifying an existing message rather than creating or removing one.

  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 provides useful context on when to use the tool: it mentions getting message_id from send_message or read_messages output, and the constraint of editing only your own messages. It doesn't explicitly name alternative tools for different tasks (e.g., update_post for posts), but the resource and action differentiation is implicit. The guidance about oase_id defaulting is also given.

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

• promise_login_startA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden. It discloses key behaviors: starts a local callback server, opens the default browser, and returns a URL as a fallback. However, it does not mention potential failure modes (e.g., callback timeout, user cancellation) or side effects on existing sessions. Still, it goes beyond a minimal statement.

  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 concise, front-loaded with the core action, and every sentence adds value. It covers the mechanism, the fallback, the user interaction, and the next step without fluff.

  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 zero-parameter tool with no output schema, the description is remarkably complete: it explains the flow, the returned URL as a fallback, and the required follow-up. The only minor gap is not specifying what happens on failure or cancellation, but that is an edge case for a login starter.

  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 tool has zero parameters, so the input schema is empty and coverage is 100%. Per the rubric, a baseline of 4 applies for 0-parameter tools. The description adds no parameter meaning because there are none to explain, which is appropriate.

  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 verb ('Begin logging in') and resource ('persistent Promise identity'), and clarifies the mechanism (local callback server + browser). It distinguishes itself from the sibling promise_login_finish by explicitly saying to call that tool afterward, and from raw token pasting by recommending against it.

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

  Usage Guidelines5/5

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

  It provides when-to-use instruction (starting a login), explicitly names the follow-up tool (promise_login_finish), and gives a recommendation against an alternative method (raw id_token). This is clear and actionable for an agent deciding how to initiate login.

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

• read_postsA
  4.7/5.0
  Behavior5/5

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

  No annotations are present, so the description carries full burden. It discloses decrypted output, chronological ordering (oldest first), line format including post IDs and (you) tags for agent-published posts, attachment tag structure, and follow-up tool usage. This is rich behavioral context beyond any 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 dense but efficient: one sentence for purpose/ordering, one for output format, and one for follow-up actions. Every sentence adds actionable detail without fluff; the main purpose is front-loaded.

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

  Completeness5/5

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

  For a simple read tool with no output schema, the description fully explains output structure, ordering, decryption, and downstream operations. It addresses all likely agent needs—what it returns and how to act on it—making it 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?

  Schema coverage is 100%: both limit and oase_id have detailed descriptions including defaults. The description adds no parameter-specific info, so it does not augment the schema. Per the rubric, baseline 3 applies when schema covers fully.

  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 clearly states it reads recent posts from an oase feed, with specifics like decryption and oldest-first ordering. It distinguishes from siblings by focusing on reading vs sending (send_post), commenting (send_message), and media download (read_media). The verb 'read' and resource 'posts' are explicit.

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

  Usage Guidelines5/5

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

  The description explicitly routes post-reading follow-ups: download attachments via read_media, comment via send_message, and react via react_to_message, each with the necessary thread/message IDs. This provides clear when-to-use guidance against alternatives, ensuring the agent picks the right tool for each subsequent action.

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

• update_postA
  4.8/5.0
  Behavior4/5

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

  With no annotations available, the description carries the full burden of behavioral disclosure. It reveals important traits: editing someone else's post requires admin/owner rights, attachments are preserved, and the post must be in the recent feed. It also explains that omitting title retains the current title. However, it does not explicitly mention whether the operation is irreversible or if it triggers notifications, but these are not critical for a typical edit operation. The description sufficiently discloses behavior beyond a simple 'edit' statement.

  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 concise yet complete, using about 100 words across several sentences. It front-loads the main action ('Edit a post...') then provides necessary details on parameters, permissions, and constraints. Every sentence adds value without redundancy or fluff, making it easy to parse quickly.

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

  Completeness5/5

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

  Given the tool's complexity (4 parameters, 2 required, no output schema), the description is fully self-contained. It covers how to obtain inputs, default behaviors, permission nuances, and the constraint on the recent feed. No information an agent needs to invoke the tool correctly is omitted.

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

  Parameters5/5

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

  Although the schema covers 100% of parameters with descriptions, the tool description adds significant semantic value beyond the schema. It explains that post_id originates from send_post or read_posts, that oase_id defaults to the last joined oase, that title omission keeps the current title while empty string clears it, and that body supports markdown. These usage details are not present in the schema and help an agent construct correct calls.

  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 verb and resource: 'Edit a post (opslag) on an oase's feed, replacing its body (and optionally its title) with new markdown.' It clearly distinguishes itself from sibling tools like send_post (create), delete_post (delete), and read_posts (read) by focusing on the modification aspect. There is no ambiguity about what action the tool performs.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool: it explains how to obtain the required post_id from send_post or read_posts output, describes default behavior for oase_id, clarifies title semantics (omit keeps current, empty string clears), and states permission requirements (own post vs admin/owner for others) along with the constraint that the post must be in the recent feed. These conditions and alternatives are clearly articulated, leaving little to inference.

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

• send_postA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the return value (post id), explains that comments are thread replies (routing to send_message), that react_to_message works on post ids, and notes the markdown body support and the optional title. It also discloses the restriction error. This is comprehensive and transparent.

  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 dense but every sentence earns its place. It front-loads the core purpose and user context, then provides actionable details (return value, alternate usage, error). There is no filler; the length is justified by the amount of necessary information for a post-creation tool among many related siblings.

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

  Completeness5/5

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

  Despite having no output schema, the description clearly states the return value (post id) and its use for further actions. It covers parameters, defaults, error conditions, and relationships to other tools. Everything an agent needs to correctly invoke send_post and understand its effects is present.

  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?

  Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: it clarifies markdown support, recommends the title (app shows as headline), and explains the default for oase_id. It also hints at the body's role in comments. This adds value, though the schema already covers the basics.

  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 verb ('Publish') and resource ('a post to an oase's feed/wall'), and explicitly distinguishes it from chat messages and the sibling send_message tool. It also clarifies the intended use case ('announcements and longer write-ups'), leaving no ambiguity about what the tool does.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance, including 'use send_message for chat' and instructions for commenting on a post via send_message with thread_id. It also explains the default oase behavior when oase_id is omitted, and even mentions the error condition 'posting_restricted' with its cause, covering both usage and exclusions.

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